After BLE OTA update, CPU2 stucks

[PCu1]

Hi, I'm working on an OTA BLE bootloader for the STM32WB5MM module.
I created from scratch with STM32CubeMX the same code as the OTA example for NUCLEO-WB55.
I'm on BLE stack 1.21
So far so good, I can update with the smartphone app.

The problem I'm having is that at the end, after receiving the BLE reset in the OTA, the microcontroller reboots correctly in the customer firmware, but remains stuck at CPU2 initialization, when hci_reset() is called in the Ble_Hci_Gap_Gatt_Init() function.

The power supply must be removed for CPU2 to work. After this action, the customer firmware is working properly.

A reset via the RESET pin does not improve the situation.

I found several similar messages about this:
https://community.st.com/t5/stm32-mcus-wireless/issue-in-ble-stack-advertisement-after-jumping-with-bootloader/m-p/63165

https://community.st.com/t5/stm32-mcus-wireless/stm32wb-cpu1-stuck-waiting-cpu2-at-init/td-p/80505

https://community.st.com/t5/stm32-mcus-wireless/stm32wb5mmg-cpu2-stuck-in-non-discovery-state/m-p/677977

 

I tried several solutions, in the OTA firmware at the end of update:
- make a jump to the customer firmware without calling NVIC_SystemReset()
- add these lines before NVIC_SystemReset()

UTIL_SEQ_PauseTask(1<< CFG_TASK_SYSTEM_HCI_ASYNCH_EVT_ID); 
SHCI_CmdStatus_t shci_response = SHCI_C2_Reinit(); 

- add aci_hal_stack_reset() or hci_reset();

Of course without success.

Note: I use the same clock configuration for OTA and customer firmware.

 

Any idea?

Pierre

[STTwo-32]

Hello @PCu1 

Could you please have a look at the Empty check paragraph of the RM0434 Rev 14. (page 74). It may be the same behavior you descripted.

Best Regards.

STTwo-32

[PCu1]

Hi @STTwo-32,

Thank you for your answer.

I checked FLASH->ACR->EMPTY and it is 0x0 after the OTA update and after the NVIC_SystemReset() which seems normal because the address 0x08000 0000 is never read as 0xFFFF FFFF.

This location is used by the OTA firmware.

 

I also unchecked nRST_STOP, nRST_STDBY and nRSTSHDW, without success.

Pierre