It was a combination of problems. The worst was a tiny whisker of solder on the socket I was plugging the prototype board into. It was invisible (to me) and very hard to detect with a multimeter. That is why multiple prototype boards all behaved the same. I wired up a new socket and things started working properly.

I am ordering another revision of the prototype boards, with a few changes and a different accelerometer, the ST LIS2DE12. The whole board is 11 x 13 mm, so there is no room for rework, and I wanted to make sure there was no elusive weird fault before placing the order. I need better test equipment.

Thanks again,

Rob

This is the breakout. It works fine with this.

Thanks everyone. I will try some things.

To clarify, I have three platforms: The development board, a breakout, pictured below, and a small crowded prototype board. The code runs without a problem on the first two, with the processor sleeping between operations. It runs on the prototype board but does not sleep. I assume it does not sleep because it is using almost 2 mA at all times. I therefore conclude that there is a problem with the hardware.

Initially the code would not sleep at all so I made sure everything was shut down before attempting to sleep. That worked. I have to experiment with capacitors  (the small board only has 1 μF and 0.1 μF capacitors) and floating pins.

Regards,

Rob

Hi All,

I have written some code for the EFM8SB2 that wakes at regular intervals, takes sensor readings (2 x I2C and 1 x analog using IREF) and going back to sleep. This works fine on the development board. with sleep current for all devices being a few μA as expected. It also works on a lash-up of breakout with the same components. However, it does not work on the prototype board we have. The MCU won't sleep. It just stays running all the time with the consumption around 2 mA.

I have been though the schematic many times and I can't find what might be preventing the MCU from going to sleep. The only difference is a different RTC crystal. Both crystals have the same specifications. 

Are there any common conditions that would stop an EFM8SB2 from going to sleep?

Thanks in advance,

Rob

Thanks Ruibin,

I was able to buy another one. I was wasting too much time on it.

I am still using the non-working board with the energy profiler, which is useful.

Rob

Hi Robert,

Have you tried other projects and have you tried running the project in debug mode? Are you able to erase the device? If the device is bricked somehow(i.e. stuck in low energy mode), then there is not really a way to unbrick it since the device recover feature in Simplicity Commander does not support EFM8 devices. In general with EFM8 devices you want to implement a device trap function at the beginning of your main application as shown in this knowledge based article: https://www.silabs.com/community/mcu/8-bit/knowledge-base.entry.html/2015/08/20/_bricking_an_8-bit-54nh. Another knowledge based article that might be helpful is: https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2014/05/14/recover_efm32_orefm-BNRV

Sincerely

Ruibin Ni

The board is the EFM8SB2-SLSTK2011A.

It is drawing a constant 2 mA with the switch on AEM. If I switch it to BAT it shows noise < 100 nA.

When I try to start a project, it gets stuck at a dialog box "Copying C:\......hex to J-Link Silicon Labs(nnn)

Than a J-Link error message appears "Communication timed out: Requested 4 bytes, received 0 bytes!

When I click OK another message appears "Multiple problems have occurred." There are two lines Launching.... and Uploading. Clicking on either of these gives the message "Unknown error code."

Hi All,

I seem to have either destroyed or bricked the MCU on the EFM8SB2 development board. It is identified when I plug it in but I can't upload code to it.

The energy profiler still works and the debugger seems to respond. Is it possible that the MCU is just bricked and it could be revived? If so, how would I do that?

These dev boards are out of stock at DigiKey.

Thanks in advance,

Rob

Hi,

I was not aware the BGX13 had that level of control.

I have resolved the problem anyway. However, I need to implement hardware flow control so I can monitor the CTS level of the BGX113. That means a redesign of my board.

Regards,

Rob

Hi All,

I am building a device using the BGX13S. It is working well except that sometimes I find it awake when it should be asleep. The only way I can tell if it is awake is to send a character to it. If it responds I know it is awake.

My device is battery powered and I do not want the BGX13 to be awake when not needed. It seems to be waking up sometimes in response to connection requests from random BLE devices. The connection fails so the con_active pin is not asserted, therefore the MCU stays asleep. I have the MCU waking up regularly as a rough work-around but that is affecting battery life as well.

It would be really useful to have a pin asserted when the BGX13 is awake. Is this possible?

Thanks in advance,

Rob