Hello, Im working on an OTA feature using the internal memory. My custom board has a smaller memory than the KW45B41Z-EVK and as such I need to reconfigure the memory sections.
I use the "otap_client_att_bm" demo with only 3 modifications.
1. I changed the gAppOtaExternalStorage_c flag to use the internal memory:
2. I changed the memory partioning, more specifically I reduced the size of "PROGRAM_FLASH":
And reduced the size and starting address of the OTAP dump address "INT_STORAGE":
Experiment 1:
Experiment 2:
I used the following SDK:
I conducted all experiments on the evaluation board.
My OTA application works fine when using the default location, 0x7a000 for "INT_STORAGE" (memory section for receiving and storing sb3 file). However, when changing the "INT_STORAGE" to a lower address it seems the OTAP process erases the contents of my newly defined "INT_STORAGE" and therby the new sb3 image.
To verify this, I modified the "INT_STORAGE" by two sectors, from 0x7a000 to 0x76000, as seen in the image below.
Prior to initiating OTAP, the dump address "INT_STORAGE" is empty as seen in the below image.
I then initiate the OTAP and set a breakpoint in the "OTA_SetNewImageFlagWithOffset" function, since the image transfer is complete upon entering this function. At this time we can observe that the sb3 image is stored at the new dump address (0x76000), see image below.
Once the OTAP sequence is finished, i.e. the device has rebooted it is no longer functional. The memory at the start address explains this.. see image below. The new application is only written up untill address 0xb0.
If we look at the new dump address "INT_STORAGE" (0x76000), it too is cleared.
However, if we look at the default dump address (0x7a000), it still holds data.
Additionally, if we compare the contents of the default "INT_STORAGE" (0x7a000) with the contents of the sb3 file I sent over with an offset of 0x4000, i.e. what was written at address 0x7a000 before the reboot, we can see that it matches up perfectly.
This leads me to believe that the first 16kB or 0x4000 bytes of the sb3 image are erased during the reboot of the OTAP process and as such the sb3 file fails to be processed.
I did the same experiment but moved the dump address the other direction, i.e. one sector higher (0x80000). During this experiment the OTA succeeds but the same behavior can be observed in the memory. Default "PROGRAM_FLASH" section is erased, i.e. 0x00 -> 0x7a000. The below screenshots show the memory of the device prior to OTAP initialization, showing that the default "INT_STORAGE" remains unchanged.
I then continue to do the same OTAP sequence as previously and break at the same location. At this point the memory at the default "INT_STORAGE" address is identical as prior to the image receival.
However, the memory at the new dump address (0x80000) is showing the start of the sb3 file.
And the OTAP is successful in booting the new image after the reboot.
These two experiments leads me to the conclusion that the erasing of "PROGRAM_FLASH" section does not account for the active memory configuration but rather strictly considers the default memory partioning. Which seems like strange/unwanted behavior as the memory partioning is completly optional. Do you have any fix for the addressing of the erase operation that removes parts of my sb3 image? Or can you provide source code for the OTA bootloader so that I may look into the issue?
Found the issue in the sb3 file generation..
By default the Over The Air Programming tool sets an erase command in the sb3 file from address "0x00" with a size of "0x7a000" effectively erasing parts of the sb3 file stored at "0x76000".
Enabling this line and changing the size to the desired value of "PROGRAM_FLASH" fixed the issue!
Found the issue in the sb3 file generation..
By default the Over The Air Programming tool sets an erase command in the sb3 file from address "0x00" with a size of "0x7a000" effectively erasing parts of the sb3 file stored at "0x76000".
Enabling this line and changing the size to the desired value of "PROGRAM_FLASH" fixed the issue!
