- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Solved! Go to Solution.
- Labels:
-
FlashEEPROM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's helpful, thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can I use –NOERASE in wiced smart sdk v1.1.0?
Best Regards,
Ren Kai
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi ehoffman,
Yes, that was the end of the log. I will try without the CHECKCRC.
Thanks,
Javier
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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