Could you please provide following information.
->Which application are you trying to compile?
->Which android app are you using?
->Are you using MTB2.0?
Just for the confirmation, your query is, "you are able to compile the application, but it doesn't create a .bin file compatible for OTA. Why?"
Please let me know if my understanding is wrong.
Corey was asking on my behalf. First your answers:
A quick follow-up. I did find some differences in the build settings and now at least the file creation portion appears similar. I still get the same results when I try to perform the OTA upgrade. I just found another difference in the settings but won't be able to resolve it until Monday.
EDIT: Using the Dimmer project to figure out how to create the .bin file was a good idea. Copying all the build settings - not so much. The Dimmer project uses the CYBT-213043-MESH platform (which HAS an external SFLASH) whereas I am using the CYBT-213043-EVAL platform (which does NOT). That accounts for all of the errors during the writes and reads. I removed the defines for OTA_FW_UPGRADE_SFLASH_COPY and ENABLE_SFLASH_UPGRADE and have made some progress.
I still don't quite have something right. I've set DS_LOCATION=0x501400 and DS2=0x53E000. When I try to do an OTA upgrade, it appears to be trying to load to 0x53E000. It appears to be writing successfully until it reaches 0x540000 when it starts failing (end of memory?). In looking at the .map file, it appears the firmware upgrade functions are located at 0x53E000. However, they don't appear to be over-written (can perform multiple attempts to upgrade). I'll attempt to figure out the correct settings for DS2 but in the meantime, if anyone has any suggestions, I would appreciate it.
I’ve attached a log from my latest attempt. I just picked DS2=0x51FA00 since it would make two equal areas (0x501400 – 0x51FA00 and 0x51FA00 – 0x53E00). I turned on ENABLE_WICED_FW_DEBUG to see what was going on. It looks like it is doing everything correct but does not recover from the subsequent reset. I suspect it is one of the following:
- The boot firmware does not know where to find DS2 and is ending up in the weeds.
- My code is not compiled as position independent code.
I’m not sure how to solve either one of those issues. I’ve attached a log of my OTA update
I've attached a new log. I found that the value for DS2 in the .btp file was 0x520A00 so I changed my settings accordingly. Things are still not correct. I programmed the board with a version string "0.74", then recompiled to get a bin file with version "0.75".
When the board is powered, I get the correct version, the dumps of both sections (DS1 and DS2) look correct, and the active section is shown as 0x501400. The first download completes successfully, and on reset, the active section is shown as 0x520A00 and the section dumps look correct, however, the version still reads "0.74".
On the second download, the download stalls at 0x51C000 and the board hangs. Upon inspection of the map file, this is where the fw_upgrade functions are located and I suspect the board is hangingwhen those functions are overwritten. Again power cycling the board, the active section and section dumps look correct but the version is still incorrect. Trying to do any subsequent downloads fail right away as I suspect the call to wiced_firmware_upgrade_init_nv_locations() is calling corrupted memory.
To further add to the mystery, on at least two occasions (there have been many), the firmware version has updated correctly, although not at the initial reset after the upgrade.
It appears that the MCU is running code out of DS1 even though the active section is DS2. I'm not sure how to verify and fix this. Anyone have any ideas?
ota-upgrade.log.zip 1.7 K
1 of 1 people found this helpful
Concluding this thread.
Dev team has detected a bug in the OTA firmware update and the fix will be available in the upcoming BTSDK release.