OTAP Using Custom Memory Configuration Results In Erased "INT_STORAGE" and OTAP Failure

[primus]

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:

primus_11-1729506364597.png

2. I changed the memory partioning, more specifically I reduced the size of "PROGRAM_FLASH":

primus_12-1729506408226.png

And reduced the size and starting address of the OTAP dump address "INT_STORAGE":

Experiment 1:
 primus_13-1729506444957.png
Experiment 2:
primus_14-1729506463345.png

I used the following SDK:

primus_15-1729506544141.png

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.

primus_0-1729504550873.png

Prior to initiating OTAP, the dump address "INT_STORAGE" is empty as seen in the below image.

primus_1-1729504727577.png

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.

primus_2-1729505057427.png

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.

primus_3-1729505162172.png

If we look at the new dump address "INT_STORAGE" (0x76000), it too is cleared.

primus_4-1729505223906.png

However, if we look at the default dump address (0x7a000), it still holds data.

primus_5-1729505263069.png

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.

primus_6-1729505355276.png

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.

primus_7-1729505861489.png

primus_8-1729505874522.png

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.

primus_9-1729506065847.png

However, the memory at the new dump address (0x80000) is showing the start of the sb3 file.

primus_10-1729506111716.png

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?

[primus · Accepted solution]

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". 

primus_0-1729520108244.png

Enabling this line and changing the size to the desired value of "PROGRAM_FLASH" fixed the issue!