2025-06-20 2:37 AM - edited 2025-06-20 2:39 AM
Hello ST team,
I’m currently developing on the STEVAL-PROTEUS1 platform and encountered an issue when transitioning from the application firmware to the bootloader.
Specifically, after executing a jump from the application to the bootloader (located at 0x08000000), the bootloader hangs during CPU2 initialization. It gets stuck at the following function call:
SHCI_C2_BLE_Init(&ble_init_cmd_packet);
This only occurs when jumping from the application. When powering on the board directly into the bootloader, everything works as expected, and BLE initialization succeeds.
I have ensured that:
CPU2 is not held in reset by the application before the jump.
The jump procedure clears necessary registers (SCB->VTOR, stack pointer, etc.).
Despite this, SHCI_C2_BLE_Init() does not return or proceed further.
Has anyone experienced similar behavior on the STEVAL-PROTEUS1 or other STM32WB-based boards? Are there additional steps required to properly re-initialize CPU2 when switching from application to bootloader?
Any suggestions or guidance would be greatly appreciated.
Thanks in advance!
Best regards,
2025-06-20 2:43 AM
As a follow-up to my previous question regarding SHCI_C2_BLE_Init() hanging in the bootloader after jumping from the application — I would like to confirm one key detail related to OTA updates.
If I want to implement BLE-based OTA firmware upgrade (e.g., using ST’s STM32CubeProgrammer or a custom mobile app), does the bootloader need to reinitialize the BLE stack and expose a BLE service again, after jumping from the application?
Or is it possible to perform OTA upgrades entirely within the application, without jumping to the bootloader?
I understand that the reference bootloader examples usually reinitialize BLE and expose specific characteristics, but I want to know whether that's strictly required — or whether I can build OTA functionality directly into the application and skip bootloader involvement entirely.
Thank you for your clarification.