cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Smart Bluetooth

Anonymous
Not applicable

We have have BCM20737 units that fail to boot on reset. The micro reads a small amount of data from EEPROM and does not continue to read out the entire application.

From analyzing the static sections(SS1 and SS2) of these units I observe the first byte of SS1 is set to 0x00 while the first byte of SS2 is set to 0xFF. In working units atleast one of the static section has the first byte set to 0x01. Could this prevent the micro from reading in the active partition from EEPROM? The units are running the 2.2.1 SDK.

Thanks for the help.

0 Likes
1 Solution
JacobT_81
Employee

From analyzing the static sections(SS1 and SS2) of these units I observe the first byte of SS1 is set to 0x00 while the first byte of SS2 is set to 0xFF. In working units atleast one of the static section has the first byte set to 0x01. Could this prevent the micro from reading in the active partition from EEPROM? The units are running the 2.2.1 SDK.

The first 11 bytes of the SS are check-summed on boot. If the checksum fails, the board will increment through certain locations in memory until it finds a valid SS to use. If it doesn't find one, it will only boot from ROM..

The first three bytes of the SS you are using should always be 0x01 0x00 0x08. Whichever SS your working boards are using should contain this sequence. As you noted, your bricked boards do not contain this sequence. Corruption of this area is likely the cause of your boot failure.

Can you confirm that you're performing OTA updates to these boards? It sounds like a failure is occurring in that process. 

Since reproducing this error is difficult, for the time being I recommend that you move to SDK 2.2.3. This latest SDK addresses issues of NVRAM corruption like you're seeing.

To utilize these fixes, please use 2.2.3 and add to your makefile:

     APP_PATCHES_AND_LIBS += config_nvram_fixes.a

Jacob

View solution in original post

9 Replies