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.

[tester]

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

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

[tester]

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

[SSher.3]

I'm experiencing the exact same issue!!

Guys from STM, are you going to provide any input? It's clearly typical issue which you need to address.
I spent bunch of time designing the project, prototyping the board and got stuck on this issue.

[TBran.3]

I've got a support ticket open with ST at this point, hopefully they'll find the resolution soon.

[tester]

If you manage to solve this issue, tell ST Staff to post the solution here

[Jerry06 · Accepted solution]

I experienced the same issue. Just mentioned in this post https://community.st.com/t5/stm32-mcus-wireless/stm32wb-cpu1-stuck-waiting-cpu2-at-init/m-p/580103#M16082, the problem is caused by that, the clock of the application is configured on the HSE and the bootloader is on LSE for the RF system wakeup. So configuring the clock source of RF system wakeup to LSE in your application is a way to solve the problem.

[TBran.3]

Holy smokes dude, that was it! Thank you so much! I've been banging my head against the wall for so long.

For everyone else, just to be clear, here is the setting in CubeMX that needs to be modified (must be LSE, not HSE):

[tester]

Can confirm! Changing the RFWKP Clock to LSE fixed my issue, I can now boot from normal firmware to OTA again!

[OliM]

I just want to add that if you have no LSE you can also, like any other project, reconfigure the bootloader to use HSE instead 
https://community.st.com/t5/stm32-mcus/configuring-stm32wb-for-bluetooth-le-without-an-lse-crystal/ta-p/49465
That's something I already did successfully in the past. Using HSE in an application which DOES have an LSE is something you should not do normally since it will increase power consumption n-fold.