STM32WB55CC BLE stack not initializing

Necronomicon · ‎2020-08-27

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

Necronomicon · ‎2020-09-14

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.

View solution in original post

towynlin · ‎2020-08-27

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

Necronomicon · ‎2020-08-27

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

Remi QUINTIN · ‎2020-08-28

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 · ‎2020-08-28

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 · ‎2020-08-28

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 · ‎2020-08-28

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 · ‎2020-08-28

>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 · ‎2020-08-28

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

towynlin · ‎2020-08-28

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.