Hi all,

I have been looking for a problem where my production units use more power than the prototypes. The production units have a BGX13S with flow control enabled and use several more µA than the prototype.

The RTS and CTS pins of the BGX are connected to pins of an EFM8SB2 MCU. I am using flow control to force the BGX13 to wake and sleep. This does not work perfectly.

The RTS pin of the BGX13S is held high when the BGX13S is asleep.  This seems to cause power leakage of about 5 µA during sleep. I have tried using a pull-up resistor, connected to the main supply, but this made no difference. The I have found that a pull-up resistor connected to a slightly higher voltage than the supply (3.4 volts vs. 3.3 volts)  will cause the BGX13S to sleep and consume current in accordance with the manual.

Is this a recognised behaviour of the BGX13S or a bug?

Thanks in advanced,

Rob

I make sure it is disconnected using con_active before forcing it to sleep.

I can force it to sleep using the sleep_select pin. I can't force it to wake using the sleep_select pin. The sleep_select function is described in the Command Reference for the gfu command as "Active low input that forces the module into sleep mode when asserted and wakes the module from sleep when deasserted." This does not work.

I can make it wake by cycling the CTS pin. I would rather not have to use two pins where your documentation says that I only need one.

I have been trying to determine the sleep/wake state by enabling flow control. When the device has flow control enabled and comes out of sleep, I would expect it to assert its RTS pin. It does not.

Even though the RST pin is not asserted, the device still receives and responds to commands via the UART.

These are important issues and are making my job difficult. Should I put in an official support request?

Further to this, I have found some more odd behavior.

I have a LED connected to RTS assuming that RTS is open drain. It is drawing less than 1 mA. If the device is awake and I send "uartu" the LED lights up. I send the device to sleep, either by typing "sleep" or by raising the sleep_select pin. The device goes to sleep.

If I wake the device up, which I can do reliably by raising the sleep_select pin and cycling the CTS pin, the device wakes and responds to signals on the UART but the LED does not light up. Presumably CTS pin is not asserted. If I send "uartu" the CTS pin asserts and the LED lights up.

I have tried this with two different devices. The both behave the same. This seems pretty odd. Is there an explanation for it?

Rob

Hi all,

I am trying to use the sleep_select function of the BGX13 devices to allow the MCU to send a device to sleep and wake it. The firmware version of the device is 1.2.2376.1.

The sleep_select function is described as Active low input that forces the module into sleep mode when asserted and wakes the module from sleep when deasserted. I have assigned the function to GPIO pin 7 using the command gfu 7 sleep_select.

In accordance with the documentation, the device goes to sleep when I drive the pin low. However, when I raise the pin to VCC, with or without a pullup resistor, it does not wake up. Is this normal?

Also, I have implemented flow control in order to tell when the device is awake. I assume that the RTS is an open drain output. It seems to work most of the time.

I tried using Wake on CTS. I have the speed set above 9600 baud. That seems to work. However, it seems to have disabled flow control and the RTS is no longer asserted when the device is awake. Are the Wake on CTS and flow control functions mutually exclusive?

Is there any way, using the RTS/CTS and GPIO pins, to reliably determine the sleep/wake status of the device and reliably force it to sleep and wake as required?

Thanks in advance,

Rob

Hi All,

I am developing a product that uses Si7051 sensors. I am identifying the devices using the Electronic Serial Number described in Section 5.3 of the datasheet. I am able to retrieve the 8 bytes as described, but the serial numbers of some of my devices are not unique.

A typical value I am getting is 013126D4 33FF33FF. The last 4 bytes are always the same, which I suppose is expected. However, I would have expected the first 4 bytes to be different between devices. Two devices I tested just now both have the first four bytes as 01311542.

Do these sensors have a unique ID at all? If not then my job is made more difficult.

Is there a possibility I have some counterfeit sensors? I have run across that before with sensors from another manufacturer.

Thanks in advance,

Rob

Hi All,

I am working with Simplicity Studio 4 with the Keil compiler to develop for an EFM8SB2. I have been using Timer 2 with no trouble. I can't get Timer 3 to be recognized.

I have set up Timer 3 to run, with the low byte disabled to fire every 10 milliseconds, and with the interrupt enabled at low priority. When I try to write the code for the interrupt, I get the message "Symbol 'TMR3CN0_TF3H' could not be resolved. See below.

I have checked that all of the entries relevant to Timer 3 are present in SI_EFM8SB2_Register_Enums.h.

I have checked the .hwconfig file and initdevice.c to confirm that the code is present and matches my chosen configurations.

Can anyone please shed some light on why things like TMR3CN0_TF3H are not accessible.

Thanks in advance,

Rob

hi Rikieth,

Please see the explanation here.
https://docs.silabs.com/gecko-os/1/bgx/latest/ble-advertising#ble-advertising-format-examples

When advertising with the 1M PHY, the maximum length of the name field in the BGX advertising packet is 8 characters. If the name of an advertising BGX (sy d n) exceeds 8 characters in length, it will be shortened in the advertising packet to its first 8 characters.

I was aware of that documentation.

There is an piece of behavior when an iPhone attempts to connect. After that, even if the connection is not successful and pairing is not completed, the device appears as with its whole 16 character name in the list of devices in any BLE scanner app. That behavior is too unreliable to use the 16 characters in lieu of the MAC address, which is not available to IOS devices.

My question was: Is the 8 truncation to 8 characters an arbitrary limitation of the BGX13 devices? If so is there any plan to lift that limitation?

I have developed a work-around to the problem anyway. It will be OK unless we sell more than 24 million devices, by which time we will probably not be using the BGX13 modules.