Skip to main content
HKIM.13
HKIM.13
Associate
December 11, 2019
Solved

STM32WB55CEUx custom board ble stack updating.

  • December 11, 2019
  • 32 replies
  • 8656 views

Hi, I recently designed my own pcb board for STM32WB55CEUx MCU.

Then, during working with my board I got some problem at APP_BLE_Init() function

and the symptoms are exactly same with

this

STM32WB55 BLE Stack trouble on new hardware: https://community.st.com/s/question/0D50X0000B5IOp2SQG/stm32wb55-ble-stack-trouble-on-new-hardware

and this

STM32WB : Bug in FW_WB_V1.0.0: aci_gap_set_discoverable > hci_send_req > hci_cmd_resp_wait - wait infinitely for hci_cmd_resp_release after few connection/disconnection

https://community.st.com/s/question/0D50X0000AYqZ6mSQF/stm32wb-bug-in-fwwbv100-acigapsetdiscoverable-hcisendreq-hcicmdrespwait-wait-infinitely-for-hcicmdresprelease-after-few-connectiondisconnection

So, I think I should update the ble stack inside my mcu.

But, I can only find the examples for the nucleoboard, which has USB bootloader mode.

I only have ST-link interface in my custom board.

How can I update ble stack with only stlink? or is it impossible?

Every pins of STM32WB55CEUx is available in my custom pcb board and other normal functions except ble work normally.

Any other tips for my situation is welcomed.

This topic has been closed for replies.
Best answer by Remi QUINTIN

OK the issue is coming from the fact that the FUS_operator (the FW converting commands from the SWD port into commands to be processed by the FUS) is not able to be loaded at 0x08000000. As a consequence, none of the FUS commands like FWdelete or FWupgrade can be executed by the FUS.

Let’s erase all the code located in the unsecure area (from 0x08000000 to the SFSA pointer).

To do that, set the RDP level to 0xBB and then revert to 0xAA. Do this in to successive commands. This will erase all data in the unsecure region.

Then let’s see what happen if you issue a new FWdelete command.

32 replies

Show previous replies
Remi QUINTIN
Remi QUINTIN
ST Technical Moderator
February 12, 2021

​Can you download the option bytes with this command?

STM32_Programmer_CLI.exe -c port=SWD -ob displ

RLour.1
RLour.1
Associate II
February 12, 2021

Here is the output

C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin>STM32_Programmer_CLI.exe -c port=SWD -ob displ
 -------------------------------------------------------------------
 STM32CubeProgrammer v2.6.0
 -------------------------------------------------------------------
 
ST-LINK SN : 066FFF545057717867194739
ST-LINK FW : V2J37M26
Board : P-NUCLEO-WB55
Voltage : 3.26V
SWD freq : 4000 KHz
Connect mode: Normal
Reset mode : Software reset
Device ID : 0x495
Revision ID : Rev B
Device name : STM32WBxx
Flash size : 1 MBytes
Device type : MCU
Device CPU : Cortex-M4
 
 
UPLOADING OPTION BYTES DATA ...
 
 Bank : 0x00
 Address : 0x58004020
 Size : 96 Bytes
 
██████████████████████████████████████████████████ 100%
 
 Bank : 0x01
 Address : 0x58004080
 Size : 8 Bytes
 
██████████████████████████████████████████████████ 100%
 
 
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 : 0x3 (0x3)
 
 Security Configuration Option bytes - 1:
 
 ESE : 0x1 (Security enabled)
 
 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)
OPTION BYTES BANK: 1
 
 Security Configuration Option bytes - 2:
 
 SFSA : 0xD0 (0xD0)
 FSD : 0x0 (System and Flash secure)
 DDS : 0x1 (CPU2 debug access disabled)
 C2OPT : 0x1 (SBRV will address Flash)
 NBRSD : 0x1 (SRAM2b is non-secure)
 SNBRSA : 0x14 (0x14)
 BRSD : 0x1 (SRAM2a is non-secure)
 SBRSA : 0xA (0xA)
 SBRV : 0x3D800 (0x3D800)
 
C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin>

Remi QUINTIN
Remi QUINTIN
ST Technical Moderator
February 12, 2021

It seems the SBRV value (0xF6) is pointing to an old version of the FUS.

To avoid any weird result, you should first upgrade the FUS to v1.0.2 and then to V1.1.0.

Please read the releases notes under directory STM32Cube_FW_WB_V1.10.0\Projects\STM32WB_Copro_Wireless_Binaries\STM32WB5x

Then select the stm32wb5x_FUS_fw_1_0_2.fin file to first upgrade the FUS to V1.0.2 and then use stm32wb5x_FUS_fw.bin file to upgrade the FUS to V1.1.0.

Those binaries are 6 sectors big (24KB). So you should load those binaries 6x 0x1000 below address 0x080D000 = 0x080CA0000.

What is strange is the value of the SFSA option byte: 0xD is not an expected value as it seems a FW had already been uploaded/programed. So It is not clear no me why you cannot erase it.

So, upgrade the FUS to its latest version and then try the fwfelete command again.

Could you tell what baord are you usning , The Nucleo board or your custom board?

RLour.1
RLour.1
Associate II
February 12, 2021

This is a standard P-NUCLEO_WB55.

I have 5 and 7 jumpered together on CN7 and JP1 set to USB_MCU. RED LED4 lights. nothing appears on the PC indicating a serial port. That does not seem like a good thing.

Any more suggestions?

How to flash the Wireless Coprocessor Binary via USB (Command Line Interface)

  • Inside the below procedure, the references to binaries name and install address are provided in the section Main Changes of this file.
  • STEP 1: Use STM32CubeProgrammer
    • Version 2.0 or higher.
    • It gives access to Firmware Upgrade Service (FUS) (AN5185 : ST firmware upgrade services for STM32WB Series.) through Bootloader.
    • It is currently available as Command Line Interface (CLI) mode.
  • STEP 2: Access to Bootloader USB Interface (system flash)
  • Boot mode selected by Boot0 pin set to VDD
  • For P-NUCLEO-WB55.Nucleo :
    • Jumper between CN7.5(VDD) and CN7.7(Boot0)
      • Power ON via USB_USER and Jumper JP1(USB_MCU)
  • For P-NUCLEO-WB55.USBDongle :
    • Move switch SW2 to Boot0
      • Connect P-NUCLEO-WB55.USBDongle

There is no device to connect to do download anything.

RLour.1
RLour.1
Associate II
February 12, 2021

I was able to program those images using the GUI STM32CubeProgrammer from the STLINK if. This address, 0x080CA000, works better than than 0x080CA0000. I still don't see a bootloader when BOOT0 is jumpered CN7.5 to CN7.7 and I am connected to the USER USB and JP1 in the USB_MCU position.

RLour.1
RLour.1
Associate II
February 12, 2021

I am about ready to punt on this and switch to an NR52840

Remi QUINTIN
Remi QUINTIN
ST Technical Moderator
February 12, 2021

Dont give up!!

So you are now using the USB port and not the SWD port as before. So the CLI command should now use port=USB1 instead of port=SWD.

In that case it a little different as you will use the bootloader.

see the document attached and check for the USB port whether your connection + jumpers are correctly set.

You can use the CubeProgrammer tool which is an easy tool to program the WB55… and all STM32 families. You can get it on the www.st.com website.

In USB mode, you are able to read the FUS version and all the option bytes, activate the FUS , delete any FW and program your application or the RF FW quite easily.

With the Cube programmer tool, you can connect either in USB or in SWD mode.

RLour.1
RLour.1
Associate II
February 12, 2021

I have switched back and forth between the two ports trying to use either SWD or the bootloader (which does not appear to be there). I don't get any USB device enumeration when I use the user USB with boot0 tied high. So the SWD port is the only one that responds. Yes, I am configuring JP1 correctly for the two different modes.

Perhaps I can try the dongle that came in the Nucleo Pack

Switch to boot0, reset... blue LED lights. UART Connect on the STM32CubeProgrammer:

Verbosity at 3

 17:56:43:251 : Serial Port COM11 is successfully opened.

 17:56:43:251 : Port configuration: parity = none, baudrate = 115200, data-bit = 8,                    stop-bit = 1.0, flow-control = off

 17:56:43:251 : No Init bits value is : 0

 17:56:43:251 : Sending init command:

 17:56:43:252 : byte 0x7F sent successfully to target

 17:56:45:251 : Wait ends after 1 loop, dataready = 0, delay = 2000

 17:56:45:251 : Timeout error occured while waiting for acknowledgement.

 17:56:45:251 : No response from target received

 17:56:45:251 : byte 0x7F sent successfully to target

 17:56:45:351 : Wait ends after 1 loop, dataready = 0, delay = 100

 17:56:45:351 : Timeout error occured while waiting for acknowledgement.

 17:56:45:351 : No response from target received

 17:56:45:351 : Error: Activating device: KO. Please, verify the boot mode configuration and check the serial port configuration. Reset your device then try again...

Back to the Nucleo board...

I think the address you gave me was not correct. I believe the address is 0x080EC000 since this is the 1Meg part.

Here is the result of erasing the 6 sectors

 17:45:24:084 : Flash sector erase ...

 17:45:24:087 : Flash erase...

 17:45:24:123 : Init flashloader...

 17:45:24:124 : Loader sector erase...

 17:45:24:141 : Init flashloader...

 17:45:24:157 : Loader sector erase...

 17:45:24:157 : Init flashloader...

 17:45:24:173 : Loader sector erase...

 17:45:24:190 : Init flashloader...

 17:45:24:190 : Loader sector erase...

 17:45:24:208 : Init flashloader...

 17:45:24:208 : Loader sector erase...

 17:45:24:217 : Init flashloader...

 17:45:24:227 : Loader sector erase...

 17:45:24:238 : Existing specified sectors are erased successfully Protected sectors are not erased

Here is the log of the flash download

 17:44:36:266 : Memory Programming ...

 17:44:36:266 : Opening and parsing file: stm32wb5x_FUS_fw_1_0_2.bin

 17:44:36:268 :  File         : stm32wb5x_FUS_fw_1_0_2.bin

 17:44:36:268 :  Size         : 24492 Bytes

 17:44:36:268 :  Address      : 0x080EC000

 17:44:36:268 : Erasing memory corresponding to segment 0:

 17:44:36:271 : Memory erase...

 17:44:36:296 : Erasing internal memory sectors [236 241]

 17:44:36:296 : Init flashloader...

 17:44:36:307 : Loader sector erase...

 17:44:36:316 : Download in Progress:

 17:44:36:316 :  Size         : 24496 Bytes

 17:44:36:316 :  Address      : 0x080EC000

 17:44:36:316 : Buffer program...

 17:44:36:344 : Loader write range...

 17:44:36:432 : Init flashloader...

 17:44:36:547 : Loader write range...

 17:44:36:635 : Error: failed to download Segment[0]

 17:44:36:636 : Error: failed to download the File

These boards have been around a while, perhaps the bootloader is no longer compatible.

Remi QUINTIN
Remi QUINTIN
ST Technical Moderator
February 15, 2021

Indeed, it may be an old board with a very old FUS version or even with no FUS at all on it.

Moreover, the IPCCDBA option byte is set to 3 which prevents both cores to properly communicate with each other.

In addition to this, SRAM2a and SRAM2b internal memories are set as non-secure which is not the expected configuration.

So first try so set IPCCDBA = 0 and check whether you get some BLE activity.

And then check if there is a FUS on it by reading the FUS version with the Cubeprogrammer tool is USB mode.

Otherwise, I would recommend you get a more recent board.

Terms & ConditionsAccessibility statement