Why data in NVM is erased after firmware upgrade?

[Anonymous]

I can use bleprofile_WriteNVRAM(UINT8 vsID, UINT8 itemLength, UINT8 *payload) to write bytes into NVM storage memory and the vsID is 0x70 which is the same with hello_sensor application.

But after firmware upgrade through HCI uart port, the data what I write in NVM is erased.

So how can I sustain my application data even if firmware upgrade?

boont maxsong

[MichaelF_56]

I believe that when implementing an upgrade over the HCI port, everything will get erased and that you will most likely need to use OTA if want data to be preserved.

victorz

boont

maxsong

[Anonymous · Accepted solution]

Firmware download over HCI is implemented by following command looks like:

Tools\ChipLoad\Win32\ChipLoad.exe -BLUETOOLMODE -PORT COM25 -BAUDRATE 115200 -MINIDRIVER Platforms/BCM920737TAG_Q32/uart_DISABLE_EEPROM_WP_PIN1.hex -BTP Platforms/BCM920737TAG_Q32/20737_EEPROM.btp -CONFIG build/hello_sensor-BCM920737TAG_Q32-rom-ram-Wiced-release/hello_sensor-BCM920737TAG_Q32-rom-ram-Wiced-release.hex -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251 > build/hello_sensor-BCM920737TAG_Q32-rom-ram-Wiced-release/download.log 2>&1

Check download log file download.log in directory build/hello_sensor-BCM920737TAG_Q32-rom-ram-Wiced-release, we will find "Chip erase" between minidriver download and DATAs download.

That's why NVRAM(VS section) is erased.

But OTA upgrading will keep NVRAM(VS section). Refer to following discussion for details.

WICED Smart BCM92073X EEPROM and SFLASH Layout

WICED Smart BCM92073X OTA Firmware Upgrade (1)

[Anonymous]

Do you have a method that keep the content in VS section when upgrade firmware through HCI port? Or skip “Chip Erase” phase?

Best Regards,

Ren Kai

[Anonymous]

Try adding -NOERASE in the command line:

c:\WICED\WICED Smart 2.0\SDK\WICED-Smart-SDK-2.0.1\WICED-Smart-SDK>Tools\ChipLoad\Win32\ChipLoad.exe -BLUETOOLMODE -PORT COM25 -BAUDRATE 115200 -MINIDRIVER Plat

forms/BCM920737TAG_Q32/uart_DISABLE_EEPROM_WP_PIN1.hex -BTP Platforms/BCM920737TAG_Q32/20737_EEPROM.btp -CONFIG build/hello_sensor-BCM920737TAG_Q32-rom-ram-Wice

d-release/hello_sensor-BCM920737TAG_Q32-rom-ram-Wiced-release.hex -CHECKCRC -NOVERIFY -NOERASE -DLMINIDRIVERCHUNKSIZE 251 > build/hello_sensor-BCM920737TAG_Q32-

rom-ram-Wiced-release/download3.log 2>&1

Just type "c:\WICED\WICED Smart 2.0\SDK\WICED-Smart-SDK-2.0.1\WICED-Smart-SDK>Tools\ChipLoad\Win32\ChipLoad.exe" for the help on usage of ChipLoad.exe.

[Anonymous]

It's helpful, thanks.

[Anonymous]

Can I use –NOERASE in wiced smart sdk v1.1.0?

Best Regards,

Ren Kai

[Anonymous]

Yes. It works. If it fails at your side, please share more details for debug.

c:\WICED\SMART1.1\SDK\WICED-Smart-SDK-1.1.0\WICED-Smart-SDK>Tools\ChipLoad\Win32\chipload.exe -BLUETOOLMODE -PORT COM44 -NOERASE -BAUDRATE 115200 -MINIDRIVER Pl

atforms/BCM920732TAG_Q32/uart_64bytes_DISABLE_EEPROM_WP_PIN1.hex -BTP Platforms/BCM920732TAG_Q32/20732_EEPROM.btp -CONFIG build/hello_sensor-BCM920732TAG_Q32-ro

m-ram-Wiced-release/hello_sensor-BCM920732TAG_Q32-rom-ram-Wiced-release.hex > build/hello_sensor-BCM920732TAG_Q32-rom-ram-Wiced-release/download2.log 2>&1

[Anonymous]

Hi maxsongb,

This does not work for us on our 20236S-based board, SDK 2.1.  All works fine without NOERASE, but when adding that parameter results in the following error:

Download config error trying to write 40 bytes to address 0xFF000000 (SOURCE:  CONFIG  Configuration data  build/foobar-BCM920736TAG_Q32-rom-ram-Wiced-release/foobar-BCM920736TAG_Q32-rom-ram-Wiced-release.hex)

Download minidriver successfully had written 251 bytes to address 0x00201000

Download minidriver successfully had written 251 bytes to address 0x002010FB

(...)

Download minidriver successfully had written 8 bytes to address 0x002043FC

Launch minidriver at 0x00201000 succeeded

Downloaded 0 code bytes ( 0.0%) and 0 data bytes ( 0.0%). Verified 0 code bytes ( 0.0%) and 0 data bytes ( 0.0%).  Current state: Terminated with error

The way we modified the makefile is shown below:

diff --git a/Makefile b/Makefile
index 8e97585..5e654a2 100644
--- a/Makefile
+++ b/Makefile
@@ -155,7 +155,7 @@ download_using_chipload:
    $(QUIET)$(ECHO_BLANK_LINE)
    $(QUIET)$(eval UART:=$(shell $(CAT) < com_port.txt))
    $(QUIET)$(if $(UART), \
-               $(ECHO) Downloading application... && $(call CONV_SLASHES,$(CHIPLOAD_FULL_NAME)) -BLUETOOLMODE -PORT $(UART) -BAUDRATE $(PLATFORM_BAUDRATE) -MINIDRIVER $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_MINIDRIVER) -BTP $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_BOOTP) -CONFIG build/$(OUTPUT_NAME)/$(OUTPUT_NAME).hex -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251 > build/$(OUTPUT_NAME)/download.log 2>&1 \
+               $(ECHO) Downloading application... && $(call CONV_SLASHES,$(CHIPLOAD_FULL_NAME)) -BLUETOOLMODE -PORT $(UART) -BAUDRATE $(PLATFORM_BAUDRATE) -MINIDRIVER $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_MINIDRIVER) -BTP $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_BOOTP) -CONFIG build/$(OUTPUT_NAME)/$(OUTPUT_NAME).hex -CHECKCRC -NOVERIFY -NOERASE -DLMINIDRIVERCHUNKSIZE 251 > build/$(OUTPUT_NAME)/download.log 2>&1 \
                    && $(ECHO) Download complete && $(ECHO_BLANK_LINE) && $(ECHO) $(QUOTES_FOR_ECHO)Application running$(QUOTES_FOR_ECHO) \
                    || $(ECHO) $(QUOTES_FOR_ECHO)****Download failed - Press the reset button on the device and retry ****$(QUOTES_FOR_ECHO), \
                $(ECHO) Download failed. This version of the SDK only supports download to BCM20736A1 and BCM20737A1 devices)

Cheers,

Javier

[Anonymous]

Was "Terminated with Error" the last thing in the download.log file?  or was there more detail on what the error is?  I'm wondering if the CHECKCRC gave a CRC error due to the presence of your un-erased data in memory.  If so there would be something at the end of the log (might have to scroll right to see it) that says the CRC check failed.  Removing the -CHECKCRC switch is one way to get around a CRC error.

[Anonymous]

Hi ehoffman,

Yes, that was the end of the log.  I will try without the CHECKCRC.

Thanks,

Javier

[Anonymous]

Hi jcardona,

We tried this on a BCM20736S board but didn't reproduce this issue. You could share more info if the issue is still open. 

[Anonymous]

Hi maxsong,

We have not re-tested, but I don't really see why we should:  we have not introduced any change that could have fixed the problem: same SDK, same HW.

Cheers,

Javier