STM32WB55CC BLE stack not initializing

[Necronomicon]

Hello,

I'm trying to implement BLE functionality on a custom board equipped with an STM32WB55CC using CubeMX.

I managed to successfully (or so I think, the option bytes look good) install the BLE stack binary, but the device is not advertising. I managed to get a working test program on a P-NUCLEO-WB55 and I created the program running on my custom board identically.

Using the debugger, I found out that the APP_BLE_Init() function is actually never reached, so I assume the stack on the M0 is not responding.

I have searched the forum quite extensively without results, so any help or ideas would be greatly appreciated.

Thanks,

Stephan

[towynlin]

Are you calling UTIL_SEQ_Run(~0) from the main while loop to run sequencer tasks?

[Necronomicon]

Yes, I do. I also added the required Interrupt handlers, but those are never reached, either.

[Remi QUINTIN]

​How did you program your board? using CubeProgrammer in CLI or GUI mode?

Could you dump the secure option bytes, SFSA and SBRV in particular?

[Necronomicon]

I first tried using the GUI, which I used to update the FUS, but for the BLE stack, I had to use the CLI because the GUI version doesn't allow starting the stack after installation when using the SWD interface (is this a bug?).

Here's a dump of the option bytes:

OPTION BYTES BANK: 0
 
 Read Out Protection:
 
 RDP : 0xAA (Level 0, no protection)
 
 BOR Level:
 
 BOR_LEV : 0x0 (BOR Level 0 reset level threshold is around 1.7 V)
 
 User Configuration:
 
 nBOOT0 : 0x1 (nBOOT0=1 Boot from main Flash)
 nBOOT1 : 0x1 (Boot from code area if BOOT0=0 otherwise system Flash)
 
 nSWBOOT0 : 0x0 (BOOT0 taken from the option bit nBOOT0)
 SRAM2RST : 0x0 (SRAM2 erased when a system reset occurs)
 SRAM2PE : 0x1 (SRAM2 parity check disable)
 nRST_STOP : 0x1 (No reset generated when entering the Stop mode)
 nRST_STDBY : 0x1 (No reset generated when entering the Standby mode)
 nRSTSHDW : 0x1 (No reset generated when entering the Shutdown mode)
 WWDGSW : 0x1 (Software window watchdog)
 IWGDSTDBY : 0x1 (Independent watchdog counter running in Standby mode)
 IWDGSTOP : 0x1 (Independent watchdog counter running in Stop mode)
 IWDGSW : 0x1 (Software independent watchdog)
 IPCCDBA : 0x0 (0x0)
 
 Security Configuration Option bytes:
 
 ESE : 0x1 (Security enabled)
 SFSA : 0x17 (0x17)
 FSD : 0x0 (System and Flash secure)
 DDS : 0x1 (CPU2 debug access disabled)
 C2OPT : 0x1 (SBRV will address Flash)
 NBRSD : 0x0 (SRAM2b is secure)
 SNBRSA : 0xF (0xF)
 BRSD : 0x0 (SRAM2a is secure)
 SBRSA : 0xA (0xA)
 SBRV : 0x5C00 (0x5C00)
 
 PCROP Protection:
 
 PCROP1A_STRT : 0x1FF (0x80FF800)
 PCROP1A_END : 0x0 (0x8000800)
 PCROP_RDP : 0x0 (PCROP zone is kept when RDP is decreased)
 PCROP1B_STRT : 0x1FF (0x80FF800)
 PCROP1B_END : 0x0 (0x8000800)
 
 Write Protection:
 
 WRP1A_STRT : 0xFF (0x80FF000)
 WRP1A_END : 0x0 (0x8000000)
 WRP1B_STRT : 0xFF (0x80FF000)
 WRP1B_END : 0x0 (0x8000000)

[Remi QUINTIN]

Using the last version V2.5 of CubeProgrammer, it is possible to activate the RF stack once it is installed. just check "start stack after upgrade" but I agree this is only functional with the USB port. This feature does not exist yet via the SWD port. Indeed this could explain the BLE stack not running.

The option bytes are OK.

In last resort, I would recommend reprogramming the RF stack after a fw delete. I assume you are using the last CubeWB FW package version V1.8 with FUS1.1.0.

[Necronomicon]

Yes, I am running CubeWB FW package version V1.8 with FUS1.1.0 and CubeProgrammer v2.5.

The option to start the stack after the upgrade is greyed out, that's why is used the CLI version, is this also only available via the USB interface?

I already tried re-installing the stack several times and I just tried it again for good measure, but still no success.

[Remi QUINTIN]

​>is this also only available via the USB interface?

Yes for now!

I am running out of ideas. I will discuss with my colleagues to find new experiments to perform.

[Necronomicon]

So there is no way to start the BLE stack without a USB interface?!

[towynlin]

I'm watching this closely because I have a very similar if not quite identical problem. My board does run APP_BLE_Init() but it waits forever for a response in hci_reset(). For now I won't add off-topic clutter to the thread, but I'm also stuck and eagerly awaiting an answer here.

[Necronomicon]

Since nobody else seems to have anything, would you mind adding some off-topic clutter to this thread?

[Necronomicon]

Today I tried the exact same installation procedure on a P-NUCLEO-WB55 and it worked as expected (turns out the "start stack after upgrade" option is not required).

Could my problem potentially be caused by a hardware issue? I doubt it, but I'm slowly running out of ideas.

[towynlin]

Over the past week, I got my STM32WB55CC board successfully advertising, but I don't expect any of following info will help you @Necronomicon​. Here's hoping it does. :crossed_fingers:

​

The reason I suggested calling UTIL_SEQ_Run(~0) from the main while loop was that a few weeks ago I didn't know that was necessary. I expected that all the autogenerated code would have run the sequencer from somewhere. In that case (not running the sequencer) APP_BLE_Init() was never called, the same symptom you described. However, once I ran the sequencer, I got past that point.

​

The next roadblock was in hci_reset() where the code got stuck in a sequencer wait state for a response from CPU2 that never came. Until reading this thread and related info, I didn't know that these chips as shipped from the factory actually don't work, and that you have to go through a multi-stage firmware upgrade and wireless stack installation process using windows-only tooling. I'm developing on a mac with the STM32CubeIDE.

​

I spun up a Windows 10 VM on VirtualBox to install the STM32CubeProgrammer, and I figured out the physical and digital rigamarole I had to go through to get the ST-LINK-V3SET (with latest firmware) recognized by the Windows VM. Then I started learning about the ST bootloader and the option bytes. I tried to set the option bytes from the app in main flash unsuccessfully, but I was successfully able to boot into the ST bootloader in system memory using the STM32CubeProgrammer option bytes page in the Windows VM. I discovered (not easily/obviously) and read AN5185 "ST firmware upgrade services for STM32WB Series " and AN2606 "STM32 microcontroller system memory boot mode ".

​

Just like you, I'm using SWD. USB is connected on my board, but it's not validated yet. I have not yet been able to do anything other than charge over USB. As you mentioned, the STM32CubeProgrammer GUI, on the Firmware Upgrade Services page (which only even appears when the app is connected to a programmer with a valid target board attached) has the "Start stack after upgrade" checkbox grayed out. However, the STM32_Programmer_CLI.exe has a startstack option where 1 is the default according to the -h help. I ended up using the GUI to (1) delete firmware, (2) install FUS v1.0.2, and (3) install FUS v1.1.0. I then used the CLI to install the full BLE stack. I explicitly set startstack=1 just in case, but that may not be necessary.

​

I performed these operations while running the ST bootloader in system memory by setting option bytes as nBOOT0=0, nBOOT1=1, nSWBOOT0=0. If I recall correctly the firmware upgrades caused those 3 option bytes to be reset to the 1, 1, 1 state to boot from main flash, meaning that before each of the 3 firmware installations/upgrades I had to set them to 0, 1, 0 again. I don't know for certain whether that was required, but at the time my best guess was that it was the safest bet.

​

I also used the "Memory & File edition" [sic] page to verify the Device Information Table according to AN5185. My IPCCDBA option byte remained set to 0x0 before, during, and after this process, but the Device Information Table moved around --- I'm guessing set by or related to the 3 different FUS versions I was running during this process. I just now used that page to read memory at 0x20030000, and at the moment I don't see the magic number 0xA94656B9, but the subsequent version bytes look correct. I don't understand under what conditions the Device Information Table gets moved or written or set to valid data. During the upgrade process, it did, at least sometimes, have the valid data I expected.

​

I feel like everyone is somehow magically supposed to know all this already and like this post won't help you or will all be super obvious to you, but there it is. I hope by some stroke of luck there's a nugget in here that at least gets you thinking about a possible solution or at least an experiment to try. I hope it's not a hardware issue! Good luck!

[Necronomicon]

First of all, thank you for taking the time to write this detailed reply. Second of all, it's working now!

Since you pointed at AN5185, I tried reading the device information table using the "Memory & File edition" tab, but I didn't see anything useful. According to AN5185, p. 32, Table 21, this is to be expected when using SWD: "So when accessing device via SWD, it is normal to not find device info table valid because it has not yet been written or CPU2 has not been enabled yet."

After that I decided to check the memory contents around 0x20030000 while single-stepping through the program, but nothing was changing there, everything remained at 0. This behaviour was certainly strange, so I compared this to a working program on a P-NUCLEO-WB55 and saw that various addresses were supposed to be written to theses locations.

This led me to compare the linker files of both the program on my custom board and the one running on the Nucleo and - lo and behold! - the shared RAM address in my linker file was incorrect.

Instead of

RAM_SHARED (xrw) : ORIGIN = 0x20030000, LENGTH = 10K

it was set to

RAM_SHARED (xrw) : ORIGIN = 0x20010000, LENGTH = 10K

This appears to be an error in the CubeMX project templates, because I never changed the file and the test project I just created has the same mistake.

I hope this thread is helpful to anyone having the same issue.

[towynlin]

:clapping_hands::party_popper: Amazing! Congrats!

I checked my linker file, and it has the correct origin for RAM_SHARED. I'm using (and have recently generated code from) STM32CubeMX​ 6.0.1-RC3, build 20200810-1643 (UTC) as part of the CubeIDE 1.4.2 on a mac. What version are you using? I looked at a couple versions of the release notes and found no mention of RAM_SHARED.