STM32WB FOTA Practical Questions

[TBran.3]

Hi all,

Looking to implement FOTA on a custom board which uses the STM32WB55M module. I understand the principles of the FOTA solution and the services/characteristics and have looked over the relevant app note, but I have a couple of questions about how precisely to actually implement the solution.

1. Would installing both the OTA application and the user application be a matter of compiling each (OTA app with a linker script specifying a start address of 0x08000000 and the user app at (IIRC) 0x08007000) separately and then loading each binary separately at the respective addresses?

2. For custom boards, is it typical to just use the OTA application given in the STM32CubeWB software package (with some slight modifications to, for example, the BSP functions which control Nucleo LEDs)?

In other words, what I *think* is the procedure, given that I currently have a custom board with a user application:

1. Modify user app linker script to start at an address beyond where the OTA app will end
2. Take the OTA app from STM32CubeWB and modify the HW-specific functions (i.e. LED controls) to match up with my hardware.
3. Ensure VTOR is moved correctly for user application (at 0x08007000 instead of 0x08000000?)
4. Add reboot request char to one of the services in my user application
5. Compile both programs
6. Load OTA app binary at 0x08000000 using CubeProg
7. Load user app binary at 0x08007000 using CubeProg (or OTA)

Is that right or am I misunderstanding?

Thanks.

[The Seeker]

Hi, 

I have the same issue and I think like you but i'm not sure it is correct.

[TBran.3]

I should note that it appears the default OTA app already handles VTOR correctly, shouldn't require any changes there, other than to comment out the VTOR update in the user application startup code.

I followed my proposed process above and it appears that the application never boots though, so still some debugging to do. It seems too that this *should* be the process based on the notes in the readme.txt found in the BLE_p2pServer_ota example in STM32CubeWB.

[TBran.3]

Ok it looks like it just needed a power cycle. After following more or less the above process, I can write to the reboot request char and get the app to reboot into the OTA app. I can even debug the OTA app and catch the point at which it jumps into it after the reboot request, but it never seems to advertise as STM_OTA. The OTA app and not the user app is clearly running though. What am I missing?

[TBran.3]

So when I issue the reboot command and it jumps into the OTA app, it seems to hang here. It's just idling waiting for an event it appears, so it never exits SHCI_C2_BLE_Init(), which means it never makes it to Ble_Hci_Gap_Gatt_Init(). Is this a bug in the OTA app or does this mean I haven't commanded the reset correctly somehow?

[TBran.3]

I'm still stuck here. Tried a few things but have never been able to track down the issue. Anyone out there ever run into this or have any ideas?

[OliM]

What is missing from your description and probably also from your code is the magic number used by the OTA application to verify that you have a good Firmware.

[TBran.3]

I have these, as long as I didn't make a typo somewhere.

C definitions, in app_ble.c:

Linker file changes:

I'm attaching my entire linker file...

[TBran.3]

While I'm at it, here's the relevant sections from other parts of the code as well:
custom_stm.c, handling the incoming reboot request:

custom_app.c, actually processing the reboot request:

Interestingly enough, if I write a 0 to the reboot request characteristic, which corresponds to a request to reboot into the user application, that works correctly. It is only when I send 0x01 0x07 0x<num sectors> to enter OTA update mode that the OTA loader application hangs.

[tester]

I have the exact same problem. Not advertising as STM_OTA but also my user code is not deleted, is that also the case for you?