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

[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.

[Necronomicon]

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

[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. ��

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 · Accepted solution]

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.

[Necronomicon]

"I feel like everyone is somehow magically supposed to know all this already" - Looks like I'm not the only one. I learned all of this the hard way and from at least 10 different places.

In my opinion, an application note containing all the condensed information needed to get you up and running would be appropriate.

A single document containing:

• Important considerations regarding hardware design
• Basic schematics
• A warning that the wireless firmware does not come pre-installed on the devices in giant red letters
• Detailed instructions on firmware installation
• A guide on how to create a basic wireless application using CubeMX
• FAQ

Something like this would have saved me weeks and lots of headaches.

[towynlin]

���� 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.

[Necronomicon]

I was running CubeIDE 1.4.1, build 7610_20200730_1509 (UTC) with CubeMX 6.0.0-RC5, build 20200716-0824 (UTC) on Windows and I just updated to CubeIDE 1.4.2, build 7643_20200813_1322 (UTC) with CubeMX 6.0.1-RC3, build 20200810-1643 (UTC), but the linker files are still created with the same error.

Maybe this issue only exists in the Windows version?