2 Replies Latest reply on Mar 28, 2018 5:53 AM by user_1654946

    BLE OTA with Fixed Stack and Updatable Profile.


      Currently there are three types of Bluetooth OTA in Cypress's examples.

      1. OTA with upgradable stack and profile using external memory.
      2. OTA with fixed stack and profile where both are contained in bootloader project, uses a custom linker script to get application to work.
      3. OTA with upgradable stack and separate profiles in both bootloader and application projects. Uses bluetooth code export mode for stack on bootloader, and profile on application.


      For my project I don't need to update the bluetooth stack itself, but I do need the ability to change the profile with an update. This makes the fixed stack project example unsuitable as the profile isn't updatable with the application. I'd like to avoid using the triple-layered upgradable stack example as well since I'm adding the ability to verify signed updates to the bootloader and it's turning out to be a extra bit of pain to handle the handoff between things. (Not to mention figuring out how they even work, apparently the FAE's say there isn't any more documentation beyond the user-facing API datasheet...)


      Ideally I'd love to create a single simple bootloader project using the BLE stack code export which can be imported into the BLE component in the bootloadable application. This means that the bootloader and application can have separate profiles (like the upgradable stack example) and I have a direct BLE component to develop against in the application unlike the fixed stack example.


      Unfortunately, even though the projects compile, link and bootload just fine, the BLE component in the bootloadable application fails to initialize properly. I originally started by modifying the fixed stack example, but when it didn't work I changed to the upgradable stack example. The application BLE component worked until I removed the launcher project and converted the bootloader in the stack project to a normal type. There must be some interplay between the launcher/copier and the code export function that doesn't exist for a normal bootloader. I've already verified that I haven't run out of stack or heap space, and I've been struggling to figure out exactly where things have been failing since the debugger is disabled for bootloadable projects.


      If anybody has some ideas I would really appreciate it!