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?

[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?

[TBran.3]

Yep. I can power cycle to boot back into the user app IIRC. It's like it's waiting for CPU2 to reset or reinit or something, but the strange thing is that if I send 0x00 (App reboot) instead of 0x01 0x07 0xFF (FOTA reboot), it jumps to the OTA bootloader and back into my user app just fine. 

To answer your question about the while(1), you're right, the code should never get there, just added it while experimenting with stuff. Not really needed.

I'm pulling my hair out with this. I'm just hoping someone from ST can reply with an answer at this point. It seems at least 3 or 4 of us on this forum have had this problem in the last month or so.

[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]

Why do you have a while(1) after the SystemReset? That's never going to be executed, right?

[tester]

Any progress on this? I just gave up, as it was just wasting time..