BLE fails on cold boot, but works perfectly after entering FUS mode.

[FVercelliASC]

Hi everyone,

I am experiencing a very specific initialization issue with a custom board based on the STM32WB55RGV6.

We recently manufactured a batch of 30 boards. 22 of them are working flawlessly, but 8 boards fail to start the BLE radio on a cold boot (Power-On Reset). They all run the exact same firmware and have the exact same layout.

Hardware details:

• MCU: STM32WB55RGV6

• HSE: 32 MHz crystal (CS06410-32M)

• LSE: 32.768 kHz crystal

• RF: MLPF-WB55-01E3 filter + Ceramic Antenna

Symptoms & Debugging Steps Taken:

1. No RF Output: Using an SDR and Near Field Probes, I confirmed there is zero RF energy being transmitted on the 2.4 GHz band during a cold boot on the faulty boards.

2. HSE is Alive: I probed the 32 MHz HSE crystal with an oscilloscope, and it is oscillating perfectly at 32.000 MHz.

3. The FUS Workaround (The Clue): If I send an AT#FUS command via UART to enter the Firmware Upgrade Services mode, the CPU2 wakes up and the board successfully advertises the "STM_OTA" network.

4. Warm Boot Success: If I reset the board immediately after entering FUS mode, our nominal firmware boots up correctly, initializes the BLE stack, and the nominal BLE network appears and works perfectly!

5. Cold Boot Failure: If I completely remove power and power it back on, the BLE network fails to appear again, and I have to repeat the FUS procedure.

My Analysis: Since the radio, antenna, and crystal are physically capable of transmitting (proven by the FUS mode), this rules out cold solder joints or hardware damage. It strongly points to a timing, initialization, or IPC synchronization issue between CPU1 and CPU2 during a cold boot. These 8 specific boards might have marginal passive component tolerances causing the HSE or SMPS to take slightly longer to stabilize.

Any guidance on where to look in the code or what parameters to tweak would be greatly appreciated!

Thanks in advance.

[Imen.D]

Hello @FVercelliASC 

Check the option bytes values of SFSA and SBRV in CubeProgrammer. It could be linked to option bytes corruption.

Check also the log to see if there was any error message from CubeProgrammer.

Could you please share your BLE fw version, and what CubeProg version used.

Did you perform a mass erase and reprogram?

Try adding a command at the end FUS_START_WIRELESS_STACK in order to ensure that every time BLE stack will be running at the end.

Have a look at AN5185 with a dedicated known limitations part and check if you have the same scenario described.

[FVercelliASC]

Hi Imen, thank you for your response.

Here is the information and the results of the steps you requested:

• Option Bytes: I have attached a screenshot of the Option Bytes configuration from one of the boards where the BLE is not working. As far as I know, this configuration is identical across all boards (both working and non-working ones).

  • 

• Versions: I've attached another image showing the current FUS and STACK versions. Additionally, the CubeProgrammer version I am using is v2.21.0.

  • 

• Logs: I have also included a screenshot showing the logs obtained from CubeProgrammer for you to review.

  • 

• Mass Erase: I tried doing a full erase of our firmware and the FUS, and then reprogrammed them, but unfortunately, it was unsuccessful.

• Additional Command: I will discuss with the firmware development team about adding the FUS_START_WIRELESS_STACK command at the end, as you suggested.

Thank you for sharing the AN5185 application note; I will be reading through it carefully. Do you recommend any specific section where I might find an answer or a clue to my issue?

Best regards, FVercelli.

[Imen.D]

You can check the recommendation about the device configuration and FUS settings provided in this wiki:

STM32WB Firmware Upgrade Service - stm32mcu

[FVercelliASC · Accepted solution]

Hi Imen,

I wanted to provide a quick update and confirm that we have successfully solved the issue.

The solution was to properly initialize the MB_MEM2 section of the MCU to 0 (which is located in the shared RAM between the two cores). By ensuring this section is correctly initialized, the BLE started working flawlessly on all boards.

Thank you very much for your help and support throughout the troubleshooting process. I will go ahead and mark this topic as solved to close it.

Best regards, FVercelliASC