OTA FixedStack / UpdatableStack

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

cross mob
Anonymous
Not applicable

I have the need to update the Cypress PRoC over BLE (OTA).  The application itself is also BLE (so should share the BLE API code space rather than duplicating it).  I am referencing AN 97060.

I assumed that the FixedStack OTA would allow me to put the BootLoader service in the fixed BootLoader part, and my own services in the BootLoadable part and they could still share the large BLE API calls.  But AN97060 says "Make sure that the final bootloadable project schematic does not contain the BLE Component. If the bootloadable project already contains a BLE Component, then: a. Move it to BLE_OTA_FixedStack_Bootloader01 project.  b. Add and configure the bootloader service into the existing BLE Component (see Adding Bootloader Service). "

I read that as saying that I have to define all my BLE services up front in the FixedStack area (and can therefore no longer add to or update them).

==> Is that true for the FixedStack OTA?  That my services/characteristics are frozen in the fixed stack area?  And only non BLE code goes in the application area?

I initially was looking at the UpgradableStack, but when compiling, it appears that with BLE, the stack application is already almost 50% of the flash space thereby making it possible that it will later exceed 50% and not be able to be updated anyway (you need half the flash to hold the new copy of the StackApplication when it is being updated).  But the UpgradableStack model does allow me to have a BLE component in the 'UserApplication' area leading me to believe that I can update my BLE services without having to update the Stack portion of the code...

==> Is it true that UpgradableStack solution would allow me to have just the boot loader service and application update in the StackApplication area and all of my custom BLE services in the UserApplication area? 

I am ok with not updating the Stack area if I can use all existing BLE APIs and define my own services from the User Application area...

Thank you for your assistance!

Kevin

0 Likes
1 Solution
Anonymous
Not applicable

==> Is that true for the FixedStack OTA?  That my services/characteristics are frozen in the fixed stack area?  And only non BLE code goes in the application area?

As the Fixed Stack OTA Bootloader document states:

BLE stack is part of the bootloader and cannot be upgraded (including the BLE profiles) via OTA.

The BLE profiles will be frozen into the "fixed" part of the image.

==> Is it true that UpgradableStack solution would allow me to have just the boot loader service and application update in the StackApplication area and all of my custom BLE services in the UserApplication area? 

I would think that your custom BLE services need to be associated/linked with the BLE stack, and thus would need to be put in the StackApplication area. I could be wrong however, as I've not played with the bootloader directly. If you were allowed to split the custom services from the BLE stack, then while updating the firmware, the stack would change without the BLE profiles changing, or vice versa which would lead to function calls and returns to locations that are not longer correctly associated with the function expected due to the partial progress of the firmware image update.

Most of the cypress chips have a "double" memory version of the chip that will easily support the full-copy bootloader architecture. But, that will increase BOM obviously.

Epratt

View solution in original post

0 Likes
2 Replies
Anonymous
Not applicable

==> Is that true for the FixedStack OTA?  That my services/characteristics are frozen in the fixed stack area?  And only non BLE code goes in the application area?

As the Fixed Stack OTA Bootloader document states:

BLE stack is part of the bootloader and cannot be upgraded (including the BLE profiles) via OTA.

The BLE profiles will be frozen into the "fixed" part of the image.

==> Is it true that UpgradableStack solution would allow me to have just the boot loader service and application update in the StackApplication area and all of my custom BLE services in the UserApplication area? 

I would think that your custom BLE services need to be associated/linked with the BLE stack, and thus would need to be put in the StackApplication area. I could be wrong however, as I've not played with the bootloader directly. If you were allowed to split the custom services from the BLE stack, then while updating the firmware, the stack would change without the BLE profiles changing, or vice versa which would lead to function calls and returns to locations that are not longer correctly associated with the function expected due to the partial progress of the firmware image update.

Most of the cypress chips have a "double" memory version of the chip that will easily support the full-copy bootloader architecture. But, that will increase BOM obviously.

Epratt

0 Likes
Anonymous
Not applicable

Epratt - thank you for the reply.  I actually eventually went to the updatable stack and now understand the architecture better. 

With the updatable stack, the 'stack' contains the BLE stack plus a BLE profile that contains the OTA part of the code.  The launcher determines whether to launch the stack 'application' which only knows the OTA profile, or my application that has other profiles.  One of my profiles actually can be written to in order to tell the part to boot back into the OTA profile for updating.  [OTA examples use a button but my hardware does not have a button for that function.].

My guess would be now that the fixed stack behaves the same way (separate profile for OTA in the stack vs what is in my app profile).  Obviously the fixed stack just can't have itself updated (because it's fixed).  So the fixed stack would have likely worked for me as well but now I'm using the updatable stack.

My problem now (that I'll post as a separate thread) is that I want to share the stack build date/time with my application so that the phone can know the build date time of both stack and application and therefore know if something needs to be updated.  I haven't figured out yet how to share fixed memory in my stack with my application....