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:
Is that right or am I misunderstanding?
Solved! Go to 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.
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.
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?
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?
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.