BLE OTA Upgradable Stack & SRAM Initialization

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Howdy All,

   

After successfully following the BLE OTA Upgradable Stack example/tutorial, I now have a functioning system that can handle any of (1) App Upgrade, (2) Stack Upgrade, or (3) Both App and Stack Upgrade. The tutorials are excellent!

   

Along the way I've come across a curious case, which hopefully has a simple answer. If the Stack project is slightly altered (such as changing the Project Header printout by a single character) and the Application is rebuilt, attempting to push the Application OTA fails. I believe this is because the new Application is "expecting" a different Stack than the one it finds.

   

The Application fails in the InitializeBootlaoderSRAM() function, which for the GCC compiler is simply a wrapper for Bootloader_Start_c().

   

This function initializes the .BSS section of RAM. Debugging via UART printouts shows that a *good* OTA leads to a RAM initialization where the data source is 0x00000000 and the data destination is 0x00000000. A *bad* OTA leads to an initialization where the source is 0x00000000, but the destination is a random (?), much higher value.

   

Obviously a user should never be allowed to upgrade an Application on top of the wrong Stack, but it seems this should be an easy mitigation.

   

Is there a Bootloader/Bootloadable option or feature I am missing that would catch a mismatch like this? It is easy enough to store custom values in SFLASH, or even manually alter the Bootloader Metadata, but I am hopeful there is a better way.

   

Thanks!

0 Likes
1 Solution
Anonymous
Not applicable

Case closed. The response:

   

 

   

"Your assumption is right. It failed because of the stack mismatch.

   

But unfortunately as of now there is no way to find this stack mismatch. The user should be aware of the stack versions before proceeding with an update."

   

 

   

Fair enough!

View solution in original post

0 Likes
3 Replies
Anonymous
Not applicable

Hi,

   

Please create a Tech Support case with us.

   

Regards,

   

-Madhu Sudhan

0 Likes
Anonymous
Not applicable

And please share the answer with us 🙂

0 Likes
Anonymous
Not applicable

Case closed. The response:

   

 

   

"Your assumption is right. It failed because of the stack mismatch.

   

But unfortunately as of now there is no way to find this stack mismatch. The user should be aware of the stack versions before proceeding with an update."

   

 

   

Fair enough!

0 Likes