3 Replies Latest reply on Jun 13, 2016 10:14 AM by samb_1578006

    BLE OTA Upgradable Stack & SRAM Initialization

    samb_1578006

      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!