Difference between revisions of "ST STM32WB"

From SEGGER Wiki
Jump to: navigation, search
(→‎Programming the option bytes)
(→‎Option bytes flash)
 
(28 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
The ST STM32WB series devices are heterogeneous dual-core MCUs with a Cortex-M4 for the end-user application and a Corte-M0 for the BLE stack.
 +
The ST STM32WB series devices are heterogeneous dual-core MCUs with a Cortex-M4 for the end-user application and a Cortex-M0 for the BLE stack.
 
The STM32WB series currently consists of 3 sub-families:
  
The STM32WB series currently consists of 3 sub-families:
 
* STM32WBx0
  
* STM32WBx0
Line 5: Line 5:
 
* STM32WBxM
  
* STM32WBxM
   
  +
<div class="toclimit-3">
 
__TOC__
  
__TOC__
  +
</div>
   
 
== Internal flash ==
  
== Internal flash ==
 
The STM32WB device series comes with varying sizes of internal flash up to 1 MB, which is generally supported by J-Link.
  
The STM32WB device series comes with varying sizes of internal flash up to 1 MB, which is generally supported by J-Link.
  +
{| class="seggertable"
−  
−
{| class="wikitable
  
 
|-
  
|-
 
! Device name !! Range / Size
  
! Device name !! Range / Size
 
|-
  
|-
−
| STM32WBxxx'''C''' || 0x0800_0000 - 0x0804_0000 (256 KB)
 +
| STM32WBxxx'''C''' || 0x0800_0000 - 0x0803_FFFF (256 KB)
 
|-
  
|-
−
| STM32WBxxx'''E''' || 0x0800_0000 - 0x0808_0000 (512 KB)
 +
| STM32WB1xx'''C''' || 0x0800_0000 - 0x0804_FFFF (320 KB)<ref name="STM32WB1xx" />
 
|-
  
|-
−
| STM32WBxxx'''Y''' || 0x0800_0000 - 0x080A_0000 (640 KB)
 +
| STM32WBxxx'''E''' || 0x0800_0000 - 0x0807_FFFF (512 KB)
 
|-
  
|-
−
| STM32WBxxx'''G''' || 0x0800_0000 - 0x0810_0000 (1 MB)<ref>Partially used for wireless stack.</ref>
 +
| STM32WBxxx'''Y''' || 0x0800_0000 - 0x0809_FFFF (640 KB)
  +
|-
  +
| STM32WBxxx'''G''' || 0x0800_0000 - 0x080F_FFFF (1 MB)<ref name="STM32WB5xxxG" />
 
|}
  
|}
−
<references />
 +
<references>
  +
<ref name="STM32WB1xx">The ST STM32WB1x devices are special compared to the other STM32WB devices e.g. the sector size is 2KB instead of 4KB.</ref>
  +
<ref name="STM32WB5xxxG">Partially used for BLE stack image. The section that is reserved for this purpose is read/write protected.</ref>
  +
</references>
  +
{{Note|1=Concerning STM32WBxxx'''G''' (1MB) devices:<br>
  +
A chip erase for these devices will usually fail.
  +
This is because a part of the flash is protected as long as a wireless stack is present, resulting in a write protection error during chip erase.}}
  +
  +
== Option bytes flash ==
  +
Option byte programming is directly supported by J-Link.
  +
Alternatively, option bytes can be programmed via the Flash registers as shown in the [[ST_STM32#Option_bytes | ST STM32 main article]].
   
 
== RSS / FUS ==
  
== RSS / FUS ==
 
Root Security Service (RSS) and the Firmware Upgrade Service (FUS) are responsible for secure wireless stack updates and encryption key management.
  
Root Security Service (RSS) and the Firmware Upgrade Service (FUS) are responsible for secure wireless stack updates and encryption key management.
 
This firmware is executed by the secure core (Cortex-M0) and is not accessible by the end user or a debug probe.
  
This firmware is executed by the secure core (Cortex-M0) and is not accessible by the end user or a debug probe.
−
This firmware is factory installed in the STM32WB flash memory and is marked as secured.
 +
It is factory installed on any ST STM32WB devices flash memory and is marked as secured.
  +
On some STM32WB devices, the last sectors of the user flash are used for the RSS ande Wireless stack (WS), on others, flash outside of the user area is used for this purpose.
−
Therefore the end-user needs to take into consideration when choosing this device, as part of the memory will be already reserved for the RSS (around 5%).
  
  +
{{Note|1=
−
The RSS uses between 10 sectors (v0.5.3) and 12 sectors (v1.1.0) and is written in the flash memory end sectors.
  
  +
* Before executing any upgrade/erase attempt, please make sure that you are using the latest version of the [[J-Link Software Pack]].
−
For example, for a 1MB device, this will be stored starting at the address 0x080F4000 for v1.1.0 and 0x080F6000 for v0.5.3.
  
  +
* The upgrade process and the required steps were extensively reworked/changed with J-Link Software V7.86f.<br>This section describes this new, reworked process.
  +
}}
   
 
=== How to update the Wireless Stack ===
  
=== How to update the Wireless Stack ===
−
Uploading a wireless stack to the STM32WBxx can be done with [[J-Link Commander]].
 +
Updating FUS and WS stack can automatically be done with [[J-Link Commander]] or [[J-Flash]]
 
This section describes how this is done via the following steps:
  
This section describes how this is done via the following steps:
 
# Acquire Wireless Stack binaries and determine the correct flash address.
  
# Acquire Wireless Stack binaries and determine the correct flash address.
−
# Start the device in boot loader mode.
 +
# Select the device <DeviceName> - FUS in the J-Link Commander or J-Flash.
  +
# Download the data file to the correct position, specified by the ST documentation.
−
# Connect to the MCU using [[J-Link Commander]].
  
−
# Load wireless stack to target using J-Link Commander.
  
−
{{Note|FUS & Stack upgrades are currently '''not''' supported via [[J-Flash]].}}
  
−  
   
 
==== Acquire Wireless Stack binaries ====
  
==== Acquire Wireless Stack binaries ====
Line 46: Line 58:
 
After downloading:
  
After downloading:
 
* Unpack the package
  
* Unpack the package
−
* Navigate to '''<tt>STM32Cube_FW_WB_V<Version>\Projects\STM32WB_Copro_Wireless_Binaries\.</tt>'''
 +
* Navigate to '''<tt>STM32Cube_FW_WB_V<Version>\Projects\STM32WB_Copro_Wireless_Binaries\</tt>'''
 
* Open '''<tt>Release_Notes.html</tt>''', which contains information about:
  
* Open '''<tt>Release_Notes.html</tt>''', which contains information about:
  +
** The available image options
−
** Where each stack starts.
  
−
** The corresponding binary files and where they should be programmed to.
 +
** The corresponding binary files and where they should be programmed to
−
Bellow in [[#Available Stacks from ST|Available Stacks from ST]] you may find the current available stacks and assigned addresses.
  
   
−
==== Start Device in system boot loader mode ====
 +
==== J-Link Commander - Upgrading the image ====
  +
Open the J-Link commander (%JLinkInstallDir%\JLink.exe) using the following example command line (example for ST STM32WB55RG devices):
−
It is important that the device starts in system boot mode. The update procedure relies on the system boot loader to be executed,
  
  +
Windows:
−
as the system bootloader sets up the shared tables, which are required for the Wireless Stack and FUS upgrade.
  
  +
JLink.exe -autoconnect 1 -device "STM32WB55RG - FUS" -if swd -speed 4000
  +
Linux/MacOS:
  +
JLinkExe -autoconnect 1 -device "STM32WB55RG - FUS" -if swd -speed 4000
  +
After connecting to the MCU successfully, download the image using the [[J-Link_Commander#LoadFile | LoadFile]] command,
  +
followed by the [[J-Link_Commander#Exit | Exit]] command.
  +
The mandatory reset is issued implicitly by the loadfile command.
  +
loadfile <PathToBinary>\stm32wb5x_BLE_Stack_fw.bin, <Address>
  +
Exit
  +
* <tt><PathToBinary></tt> is the path to the unpacked package location (see [[#Acquire Wireless Stack binaries | Acquire Wireless Stack binaries]]).
  +
* <tt><Address></tt> is the address the binary has to be flashed to (see [[#Acquire Wireless Stack binaries | Acquire Wireless Stack binaries]]).
  +
{{Note|1=
  +
* Make sure that the Exit step is executed '''before''' severing the connection between J-Link and device, as the option bytes are restored during this step.
  +
* The address the image has to be downloaded to differs depending on the image version, the used device and the selected image option.}}
  +
===== Example (STM32WB5xxG, version 1.1.0) =====
  +
J-Link> loadfile "C:\Users\Fabian\Desktop\STM32Cube_FW_WB_V1.13.0\Projects\STM32WB_Copro_Wireless_Binaries\STM32WB5x\stm32wb5x_BLE_Stack_full_fw.bin" 0x080C7000
  +
J-Link> Exit
   
  +
==== J-Flash - Upgrading the image ====
−
This can be done with the following configurations:
  
  +
# Create a project for the device you are using (<DeviceName> - FUS)
−
{| class="wikitable" style="text-align: center;
  
  +
# Add the data file to the project (make sure to select the correct start location of the image, as binary files do not contain address information!)
−
! nBOOT1<br>FLASH_OPTR[23] !! nBOOT0<br>FLASH_OPTR[27] !! BOOT0<br>pin PH3 !! nSWBOOT0<br>FLASH_OPTR[26] !! Main Flash<br>empty<br>
  
  +
# '''Important:''' Check: ''Options > Project Settings > Production > Actions performed by 'Production Programming' > Disconnect afterwards''
  +
# Download the image via ''Target > Production Programming (F7)''
  +
# Wait for the process to complete (Takes ~30 seconds)
  +
  +
==== Flasher stand-alone - Upgrading the image ====
  +
The upgrade process is also supported via Flasher stand-alone programming (since V7.86g).
  +
In J-Flash:
  +
# Create a J-Flash project as described [[#J-Flash - Upgrading the image | here]]
  +
# Download the data & config file to Flasher via ''File > Download config & data file to Flasher''
  +
# Execute the upgrade by pressing the program button on the Flasher (PROG)
  +
  +
==== Starting the wireless stack ====
  +
The following table shows under which conditions the wireless stack will be
  +
(re)started and running on disconnect (e.g. closing J-Link Commander).
  +
{| class="seggertable" style="text-align: center;
  +
|-
  +
! WS State before connect !! FUS/WS was updated<br>after connect !! Is WS started<br>on disconnect
  +
|-
  +
| Running || {{NO}} || {{YES}}
 
|-
  
|-
  +
| '''Not''' running || {{NO}} || {{NO}}<ref>Only applies if the WS is '''not''' manually started by the user during the session. If it was, the state would also be "running". </ref>
−
| '''---''' || '''---''' || {{NO}} || {{YES}} || {{YES}}
  
 
|-
  
|-
−
| {{YES}} || '''---''' || {{YES}} || {{YES}} || '''---'''
 +
| Running || {{YES}} || {{YES}}
 
|-
  
|-
−
| {{YES}} || {{NO}} || '''---''' || {{NO}} || '''---'''
 +
| '''Not''' running || {{YES}} || {{YES}}
 
|}
  
|}
  +
<references />
−
'''{{YES}} == Set / HIGH'''<br>
  
−
'''{{NO}} == Not set / LOW'''<br>
  
−
'''--- == Don't care'''
  
−
{{Note|For information on how to program the option bytes, please refer to [[#Example - Setting system boot mode {{!}} this example]]}}
  
−  
−
==== Connect to the Device with J-Link Commander ====
  
−
Before connecting to the Device, please make sure you are using the latest version of the [[J-Link Software Pack]].
  
−
Open the J-Link commander (%JLinkInstallDir%\JLink.exe) using the following command line:
  
−
Windows:
 
−
JLink.exe -autoconnect 1 -device "STM32WB55xx - FUS" -if swd -speed 4000
  
−
Linux/MacOS:
  
−
JLinkExe -autoconnect 1 -device "STM32WB55xx - FUS" -if swd -speed 4000
  
−
The above command output should be as following:<br>
  
−
[[File:STM32WB55_Connect.PNG | thumb | left | 1000px | STM32WB55 - FUS connect]]
  
−
<br clear="all">
  
−  
−
==== Downloading the wireless stack ====
  
−
After connecting to the MCU successfully, download the Update using the [[J-Link_Commander#Reset | Reset]] and [[J-Link_Commander#LoadFile | LoadFile]] commands.
  
−
Even though resetting the device is not mandatory, it is highly recommended.
  
−
r
  
−
loadfile <PathToBinary>\stm32wb5x_BLE_Stack_fw.bin, <Address>
  
−
*<tt><PathToBinary></tt> is the path to the unpacked package location (see [[#Acquire Wireless Stack binaries | Acquire Wireless Stack binaries]]).
  
−
*<tt><Address></tt> is the address the binary has to be flashed to (see [[#Acquire Wireless Stack binaries | Acquire Wireless Stack binaries]]).
  
−
{{Note|The address the wireless stack has to be downloaded to differs depending on update version and device.}}
  
−
'''Example (STM32WB5xxG, version 1.1.0)''':
  
−
J-Link> loadfile "C:\Users\Fabian\Desktop\STM32Cube_FW_WB_V1.13.0\Projects\STM32WB_Copro_Wireless_Binaries\STM32WB5x\stm32wb5x_BLE_Stack_full_fw.bin" 0x080C7000
  
−
The output should look like the following:<br>
  
−
[[File:STM32WB55_WS_upgrade.PNG | thumb | left | 1000px | STM32WB55 - FUS stack upgrade]]
  
−
<br clear="all">
  
   
 
=== How to delete the Wireless Stack ===
  
=== How to delete the Wireless Stack ===
  +
The WS is deleted during the "Reset"-step.
−
# Start the device in system boot loader mode as described [[#Start_Device_in_system_boot_loader_mode | here]].
  
  +
Thus, triggering a reset will delete the WS. This can be done in different ways.
−
# Connect to the device as described [[#Connect_to_the_Device_with_J-Link_Commander | here]].
  
  +
==== J-Link Commander ====
−
# '''(Optional/Recommended)''' Reset the device using the [[J-Link_Commander#Reset | Reset]] command.
  
  +
# Connect to the device.
−
# Erase the the device using the [[J-Link_Commander#Erase | Erase]] command.
  
  +
# Issue the [[J-Link_Commander#Reset | Reset]] command.
−
Reset
  
  +
# Disconnect to make sure that the boot mode is restored.
−
Erase 0xFFFFFFFF, 0xFFFFFFFF // Selecting this range will prevent anything but the wireless stack to be erased.
  
  +
==== J-Flash ====
  +
# Create a project for the device (- FUS!).
  +
# Connect to the device. This will implicitly trigger a reset.
  +
# Disconnect to make sure that the boot mode is restored.
   
  +
=== How to update FUS ===
−
{{Note|Not providing an erase range also works. However, J-Link will report a erase error, and a part of the flash will be deleted.
  
  +
Follow the same steps as explained in ''[[#How to update the Wireless Stack | How to update the Wireless Stack]]'', but with a FUS image instead of a WS image.
−
To prevent this, the above address range is provided.}}
  
  +
{{Note|1=
−
[[File:STM32WB55_WS_erase.PNG | thumb | left | 1000px | STM32WB55 - FUS stack erase]]
  
  +
* Once the FUS is updated from the v0.5.3 to v1.0.1 is not possible to reverse RSS or install WS from previous versions. The RSS/FUS can only upload wireless stacks within the same release version.
−
<br clear="all">
  
  +
* During the FUS upgrade, the WS will be deleted.}}
−  
−
=== How to update the RSS ===
  
−
Same process as a wireless Stack. Simply loadbin over J-Link Commander to the memory specified by ST and wait for the process to finish.
 
−
<br>'''Warning:'''<br>
  
−
Once the FUS is updated from the v0.5.3 to v1.0.1 is not possible to reverse RSS or install WS from previous versions.
 
−
The RSS/FUS can only upload wireless stacks within the same release version.
  
   
 
=== How does it work ===
  
=== How does it work ===
−
The process for uploading a Wireless stack to STM32WBxx with J-Link works by uploading the binary to the flash memory and then by requesting a Wireless stack upgrade to the FUS(Firmware Upgrade Service),
 +
The process for upgrading the WS/FUS on the ST STM32WBxx with J-Link works by uploading the binary to the flash memory and then by sending an upgrade request to the FUS.
−
by means of communication with IPPC and shared tables.
 +
This is done using the Inter-Processor Communication Channel (IPCC) via shared tables.
  +
The process is described step-by-step below.
−  
  +
{{Note|1=To guarantee that the IPCC can be used and the Info table is setup, the device boot mode will be changed during connect to start the device in system boot mode. The boot mode will be restored on disconnect.}}
−
==== The upgrade process ====
  
  +
# Connect:
−
# Before the upgrade is started the J-Link will request the FUS/RSS to delete any current wireless stack that might be installed.
  
  +
#* The device is forced to boot in system bootmode via option bytes.
−
# The uploaded stack to the flash will be checked by J-Link if it contains a valid image signature.
  
  +
#* FUS is started through IPCC.
−
# A WS_UPGRADE request is made to the FUS. During this process, the MCU will reset several times. Until the Cortex-M0 becomes responsive the J-Link will try every second to establish a connection with the FSU.
 
  +
# Reset: The wireless stack is deleted by issuing the corresponding IPCC command.
−
{{Note|This process takes around 20 to 30 seconds depending on the Wireless stack size.}}
  
  +
# Flash program:
−  
  +
#* The upgrade image is programmed to the device flash
−
=== Available Stacks from ST ===
  
  +
#* The upgrade procedure is triggered by issuing the corresponding IPCC command.
−
[[File:STM32WB55 WS Binaries.PNG | thumb | left | 1000px | STM32WB5x wireless binaries]]
  
  +
#* The wireless stack is started after a successful upgrade.
−
<br clear="all">
  
  +
# Disconnect:
−  
  +
#* If no Reset/Download was executed, the WS state will be restored (running/not running).
−
For the correct download address, please refer to:<br>
  
  +
#* The option bytes are restored to their original values before connect.
−
<tt>STM32Cube_FW_WB_V<Version>\Projects\STM32WB_Copro_Wireless_Binaries\STM32WB5xRelease_Notes.html</tt>
  
  +
{{Note|The whole process takes around 20 to 30 seconds, depending on the downloaded image.}}
   
 
=== Sending FUS commands manually ===
  
=== Sending FUS commands manually ===
 
In case a command is not supported out of the box, it has to be sent manually.
  
In case a command is not supported out of the box, it has to be sent manually.
 
This can be done via the IPCC mailbox system used for FUS communication.
  
This can be done via the IPCC mailbox system used for FUS communication.
−
To do so, a connection has to be established via the J-Link Commander. See: [[#Connect to the Device with J-Link Commander | Connect to the Device with J-Link Commander]].
 +
To do so, a connection has to be established via the J-Link Commander.
−
{{Note|
 +
{{Note|1=
 
* The mailbox buffer addresses depend on the device setup. In the following, the default system bootloader boot mode default locations are used.
  
* The mailbox buffer addresses depend on the device setup. In the following, the default system bootloader boot mode default locations are used.
−
*For a list of available commands and the corresponding responses, please refer to the ST documentation (AN5185).}}
 +
* For a list of available commands and the corresponding responses, please refer to the ST documentation (AN5185).}}
  +
==== General sequence ====
−  
 
Reset
  
Reset
−
Mem32 0x58000C0C, 1 // Channel 2 (CH2bit == bit 1) busy? Wait for it to clear. Otherwise, prcoeed.
 +
Mem32 0x58000C0C, 1 // Channel 2 (CH2F bit == bit 1) busy? Wait for it to clear. Otherwise, prcoeed.
 
Write4 0x20030064, 0 // Clear mailbox message header
  
Write4 0x20030064, 0 // Clear mailbox message header
 
Write4 0x20030068, 0 // Clear mailbox message buffer
  
Write4 0x20030068, 0 // Clear mailbox message buffer
Line 148: Line 166:
 
Write4 0x58000C08, 0x20000 // Set CH2F via CH2S (channel 2 data transmit bit)
  
Write4 0x58000C08, 0x20000 // Set CH2F via CH2S (channel 2 data transmit bit)
 
Write4 0x58000C04, 0xFFFDFFFD // Unmask Channel 2 interrupt (CH2FM & CH2OM)
  
Write4 0x58000C04, 0xFFFDFFFD // Unmask Channel 2 interrupt (CH2FM & CH2OM)
−
Mem32 0x58000C0C, 1 // _IPCC_C1TOC2SR Still busy (bit 1 == 1)? => Repeat this until unoccupied (bit 1 == 0).
 +
Mem32 0x58000C0C, 1 // _IPCC_C1TOC2SR Still busy (bit 1 == 1)? => Repeat this until unoccupied (bit 1 == 0).
−
Mem32 0x20030064, <8+n> // Read command response: 8 bytes (header + response message) + n bytes payload.
 +
Mem32 0x20030064, <8+n> // Read command response: 8 bytes (header + response message) + n bytes payload.
 
In case a Payload is required for the command, it has to be added after "Send command <Cmd>".
  
In case a Payload is required for the command, it has to be added after "Send command <Cmd>".
 
The payload contains 0 - 255 bytes:
  
The payload contains 0 - 255 bytes:
Line 158: Line 176:
 
Write1 0x2003016D, <Payload253>
  
Write1 0x2003016D, <Payload253>
 
Write1 0x2003016E, <Payload254>
  
Write1 0x2003016E, <Payload254>
  +
−
 
 
==== Example - Get FUS state ====
  
==== Example - Get FUS state ====
 
Reset
  
Reset
−
Mem32 0x58000C0C, 1 // Channel 2 (CH2bit == bit 1) busy? Wait for it to clear. Otherwise, prcoeed.
 +
Mem32 0x58000C0C, 1 // Channel 2 (CH2F bit == bit 1) busy? Wait for it to clear. Otherwise, prcoeed.
 
Write4 0x20030064, 0 // Clear mailbox message header
  
Write4 0x20030064, 0 // Clear mailbox message header
 
Write4 0x20030068, 0 // Clear mailbox message buffer
  
Write4 0x20030068, 0 // Clear mailbox message buffer
Line 169: Line 187:
 
Sleep 500 // Make sure command had enough time. Alternatively wait for C1TOC2SR bit 1 to turn 0.
  
Sleep 500 // Make sure command had enough time. Alternatively wait for C1TOC2SR bit 1 to turn 0.
 
Mem32 0x20030064, 2 // Read command response: 8 bytes (header + FUS state).
  
Mem32 0x20030064, 2 // Read command response: 8 bytes (header + FUS state).
−
{{Note| Instead of waiting for the channel to turn unoccupied, we simply wait 500ms in the example. Alternative, wait for C1TOC2SR Channel 2 bit (bit 1) to turn 0.}}
 +
{{Note|1=Instead of waiting for the channel to turn unoccupied, we simply wait 500ms in the example. Alternative, wait for C1TOC2SR Channel 2 bit (bit 1) to turn 0.}}
   
 
=== FAQ ===
  
=== FAQ ===
−
'''How does J-Link communicates with the FUS and performs the Wireless stack upgrade/delete requests?'''<br>
 +
==== How does J-Link communicate with the FUS? and performs the Wireless stack upgrade/delete requests? ====
−
The communication between the J-Link and the RSS/FUS is performed by use of the IPPC(Inter-Processor Communication Channel) and shared tables that are pre-defined by Cortex-M0.
 +
For the communication with the RSS/FUS, the Inter-Processor Communication Channel (IPCC) is used via shared tables, specified by ST.
  +
==== Does this mean that the Cortex-M0 is always running the FUS firmware? ====
−  
−
'''Does this mean that the Cortex-M0 is always running the RSS firmware?'''<br>
 +
No, the FUS firmware is only running when
−
No, the RSS firmware is only running when a wireless stack is not installed or a request is made through the IPCC and shared tables.
 +
* No wireless stack is installed
  +
* A FUS start request is sent via the IPCC and accepted by FUS.
−  
−
'''Can I delete the RSS firmware?'''<br>
 +
==== Can I delete the FUS firmware? ====
  +
No, the FUS firmware can not be fully deleted. It can only be upgraded.
−
No, it is marked as ''secure'' so it is not possible to delete it.
  
−  
−
'''Can I make my own Wireless stack and upload it?'''<br>
  
−
Currently, ST only allows uploading STs encrypted wireless stacks.
  
−  
−
== Programming the option bytes ==
  
−
Option byte programming is directly supported by J-Link.
  
−
To use option byte programming, the "STM32WBxxxx (allow opt. bytes)" variant of the device has to be selected.
  
−
Alternatively, option bytes can be programmed via the flash registers as shown below.
  
−  
−
=== Example - Setting system boot mode ===
  
−
Connect to the device using the following command line:
  
−
"%JLinkInstDir%/JLink.exe" -device "STM32WB55CG" -if SWD -speed 4000 -autoconnect 1
  
−
Read the OPTR register, and check if the required boot options are already set.
  
−
Mem32 0x58004020, 1 // Read OPTR to determine boot option bits.
  
−
If not, you can modify them via the following sequence.
  
−
Reset
  
−
Write4 0x58004008, 0x45670123 // Unlock FLASH_CR
  
−
Write4 0x58004008, 0xCDEF89AB // Unlock FLASH_CR
  
−
Write4 0x5800400C, 0x08192A3B // Unlock FLASH_OPTR
  
−
Write4 0x5800400C, 0x4C5D6E7F // Unlock FLASH_OPTR
  
−
Write4 0x58004020, 0x33FFF1AA // Clear nBOOT0 & nSWBOOT0, keep nSWBOOT0 set.
  
−
Write4 0x58004014, 0x00020000 // Set OPTSTRT
  
−
Sleep 200 // Give operation some time
  
−
Write4 0x58004014, 0x08000000 // Set OBL_LAUNCH
  
−
{{Note|
  
−
* For this example <tt>FLASH_OPTR</tt> is assumed to have ST production value (<tt>0x3DFF_F1AA</tt>).
  
−
* Setting <tt>OBL_LAUNCH</tt> will trigger a reset. This means, the debug connection will be lost afterwards.
  
−
* The same method can be used to reset the option bytes after performing a stack upgrade.
  
−
* When selecting <tt>"STM32WB55CG (ALLOW OPT. BYTES)"</tt>, the option bytes can be written directly (address: <tt>0x1FFF_8000</tt>), however the option bytes will not have loaded afterwards. It is either required to set <tt>OBL_LAUNCH</tt> (see above) or power-cycle the device.
  
−
}}
  
   
 
== Evaluation boards ==
  
== Evaluation boards ==

Latest revision as of 16:03, 22 September 2023

The ST STM32WB series devices are heterogeneous dual-core MCUs with a Cortex-M4 for the end-user application and a Cortex-M0 for the BLE stack. The STM32WB series currently consists of 3 sub-families:

  • STM32WBx0
  • STM32WBx5
  • STM32WBxM

Internal flash

The STM32WB device series comes with varying sizes of internal flash up to 1 MB, which is generally supported by J-Link.

Device name Range / Size
STM32WBxxxC 0x0800_0000 - 0x0803_FFFF (256 KB)
STM32WB1xxC 0x0800_0000 - 0x0804_FFFF (320 KB)[1]
STM32WBxxxE 0x0800_0000 - 0x0807_FFFF (512 KB)
STM32WBxxxY 0x0800_0000 - 0x0809_FFFF (640 KB)
STM32WBxxxG 0x0800_0000 - 0x080F_FFFF (1 MB)[2]
  1. ↑ The ST STM32WB1x devices are special compared to the other STM32WB devices e.g. the sector size is 2KB instead of 4KB.
  2. ↑ Partially used for BLE stack image. The section that is reserved for this purpose is read/write protected.
Note:

Concerning STM32WBxxxG (1MB) devices:
A chip erase for these devices will usually fail.

This is because a part of the flash is protected as long as a wireless stack is present, resulting in a write protection error during chip erase.

Option bytes flash

Option byte programming is directly supported by J-Link. Alternatively, option bytes can be programmed via the Flash registers as shown in the ST STM32 main article.

RSS / FUS

Root Security Service (RSS) and the Firmware Upgrade Service (FUS) are responsible for secure wireless stack updates and encryption key management. This firmware is executed by the secure core (Cortex-M0) and is not accessible by the end user or a debug probe. It is factory installed on any ST STM32WB devices flash memory and is marked as secured. On some STM32WB devices, the last sectors of the user flash are used for the RSS ande Wireless stack (WS), on others, flash outside of the user area is used for this purpose.

Note:
  • Before executing any upgrade/erase attempt, please make sure that you are using the latest version of the J-Link Software Pack.
  • The upgrade process and the required steps were extensively reworked/changed with J-Link Software V7.86f.
    This section describes this new, reworked process.

How to update the Wireless Stack

Updating FUS and WS stack can automatically be done with J-Link Commander or J-Flash This section describes how this is done via the following steps:

  1. Acquire Wireless Stack binaries and determine the correct flash address.
  2. Select the device <DeviceName> - FUS in the J-Link Commander or J-Flash.
  3. Download the data file to the correct position, specified by the ST documentation.

Acquire Wireless Stack binaries

The wireless stack binaries can be downloaded from https://www.st.com/en/embedded-software/stm32cubewb.html.
After downloading:

  • Unpack the package
  • Navigate to STM32Cube_FW_WB_V<Version>\Projects\STM32WB_Copro_Wireless_Binaries\
  • Open Release_Notes.html, which contains information about:
    • The available image options
    • The corresponding binary files and where they should be programmed to

J-Link Commander - Upgrading the image

Open the J-Link commander (%JLinkInstallDir%\JLink.exe) using the following example command line (example for ST STM32WB55RG devices): 

Windows:
  JLink.exe -autoconnect 1 -device "STM32WB55RG - FUS" -if swd -speed 4000
Linux/MacOS:
  JLinkExe  -autoconnect 1 -device "STM32WB55RG - FUS" -if swd -speed 4000

After connecting to the MCU successfully, download the image using the LoadFile command, followed by the Exit command. The mandatory reset is issued implicitly by the loadfile command. 

loadfile <PathToBinary>\stm32wb5x_BLE_Stack_fw.bin, <Address>
Exit
Note:
  • Make sure that the Exit step is executed before severing the connection between J-Link and device, as the option bytes are restored during this step.
  • The address the image has to be downloaded to differs depending on the image version, the used device and the selected image option.
Example (STM32WB5xxG, version 1.1.0)
J-Link> loadfile "C:\Users\Fabian\Desktop\STM32Cube_FW_WB_V1.13.0\Projects\STM32WB_Copro_Wireless_Binaries\STM32WB5x\stm32wb5x_BLE_Stack_full_fw.bin" 0x080C7000
J-Link> Exit

J-Flash - Upgrading the image

  1. Create a project for the device you are using (<DeviceName> - FUS)
  2. Add the data file to the project (make sure to select the correct start location of the image, as binary files do not contain address information!)
  3. Important: Check: Options > Project Settings > Production > Actions performed by 'Production Programming' > Disconnect afterwards
  4. Download the image via Target > Production Programming (F7)
  5. Wait for the process to complete (Takes ~30 seconds)

Flasher stand-alone - Upgrading the image

The upgrade process is also supported via Flasher stand-alone programming (since V7.86g). In J-Flash:

  1. Create a J-Flash project as described here
  2. Download the data & config file to Flasher via File > Download config & data file to Flasher
  3. Execute the upgrade by pressing the program button on the Flasher (PROG)

Starting the wireless stack

The following table shows under which conditions the wireless stack will be (re)started and running on disconnect (e.g. closing J-Link Commander).

WS State before connect FUS/WS was updated
after connect		 Is WS started
on disconnect
Running NO.png YES.png
Not running NO.png NO.png[1]
Running YES.png YES.png
Not running YES.png YES.png
  1. ↑ Only applies if the WS is not manually started by the user during the session. If it was, the state would also be "running".

How to delete the Wireless Stack

The WS is deleted during the "Reset"-step. Thus, triggering a reset will delete the WS. This can be done in different ways.

J-Link Commander

  1. Connect to the device.
  2. Issue the Reset command.
  3. Disconnect to make sure that the boot mode is restored.

J-Flash

  1. Create a project for the device (- FUS!).
  2. Connect to the device. This will implicitly trigger a reset.
  3. Disconnect to make sure that the boot mode is restored.

How to update FUS

Follow the same steps as explained in How to update the Wireless Stack, but with a FUS image instead of a WS image.

Note:
  • Once the FUS is updated from the v0.5.3 to v1.0.1 is not possible to reverse RSS or install WS from previous versions. The RSS/FUS can only upload wireless stacks within the same release version.
  • During the FUS upgrade, the WS will be deleted.

How does it work

The process for upgrading the WS/FUS on the ST STM32WBxx with J-Link works by uploading the binary to the flash memory and then by sending an upgrade request to the FUS. This is done using the Inter-Processor Communication Channel (IPCC) via shared tables. The process is described step-by-step below.

Note:
To guarantee that the IPCC can be used and the Info table is setup, the device boot mode will be changed during connect to start the device in system boot mode. The boot mode will be restored on disconnect.
  1. Connect:
    • The device is forced to boot in system bootmode via option bytes.
    • FUS is started through IPCC.
  2. Reset: The wireless stack is deleted by issuing the corresponding IPCC command.
  3. Flash program:
    • The upgrade image is programmed to the device flash
    • The upgrade procedure is triggered by issuing the corresponding IPCC command.
    • The wireless stack is started after a successful upgrade.
  4. Disconnect:
    • If no Reset/Download was executed, the WS state will be restored (running/not running).
    • The option bytes are restored to their original values before connect.
Note:
The whole process takes around 20 to 30 seconds, depending on the downloaded image.

Sending FUS commands manually

In case a command is not supported out of the box, it has to be sent manually. This can be done via the IPCC mailbox system used for FUS communication. To do so, a connection has to be established via the J-Link Commander.

Note:
  • The mailbox buffer addresses depend on the device setup. In the following, the default system bootloader boot mode default locations are used.
  • For a list of available commands and the corresponding responses, please refer to the ST documentation (AN5185).

General sequence

Reset
Mem32  0x58000C0C, 1          // Channel 2 (CH2F bit == bit 1) busy? Wait for it to clear. Otherwise, prcoeed.
Write4 0x20030064, 0          // Clear mailbox message header
Write4 0x20030068, 0          // Clear mailbox message buffer
Write4 0x2003006C, <Cmd>      // Write command packet "<Cmd>"
// Optional: Send payload here.
Write4 0x58000C08, 0x20000    // Set CH2F via CH2S (channel 2 data transmit bit)
Write4 0x58000C04, 0xFFFDFFFD // Unmask Channel 2 interrupt (CH2FM & CH2OM)
Mem32  0x58000C0C, 1          // _IPCC_C1TOC2SR Still busy (bit 1 == 1)? => Repeat this until unoccupied (bit 1 == 0).
Mem32  0x20030064, <8+n>      // Read command response: 8 bytes (header + response message) + n bytes payload.

In case a Payload is required for the command, it has to be added after "Send command <Cmd>". The payload contains 0 - 255 bytes: 

Write4 0x20030070, <Payload0-3>
...
Write4 0x20030168, <Payload248-251>
Write1 0x2003016C, <Payload252>
Write1 0x2003016D, <Payload253>
Write1 0x2003016E, <Payload254>

Example - Get FUS state

Reset
Mem32  0x58000C0C, 1          // Channel 2 (CH2F bit == bit 1) busy? Wait for it to clear. Otherwise, prcoeed.
Write4 0x20030064, 0          // Clear mailbox message header
Write4 0x20030068, 0          // Clear mailbox message buffer
Write4 0x2003006C, 0x00FC5210 // Write command packet <Type(Command packet) | Command (FUS_GET_STATE) | payload length == 0>.
Write4 0x58000C08, 0x20000    // Set CH2F via CH2S (channel 2 data transmit bit)
Write4 0x58000C04, 0xFFFDFFFD // Unmask Channel 2 interrupt (CH2FM & CH2OM)
Sleep 500                     // Make sure command had enough time. Alternatively wait for C1TOC2SR bit 1 to turn 0.
Mem32 0x20030064, 2           // Read command response: 8 bytes (header + FUS state).
Note:
Instead of waiting for the channel to turn unoccupied, we simply wait 500ms in the example. Alternative, wait for C1TOC2SR Channel 2 bit (bit 1) to turn 0.

FAQ

How does J-Link communicate with the FUS? and performs the Wireless stack upgrade/delete requests?

For the communication with the RSS/FUS, the Inter-Processor Communication Channel (IPCC) is used via shared tables, specified by ST.

Does this mean that the Cortex-M0 is always running the FUS firmware?

No, the FUS firmware is only running when

  • No wireless stack is installed
  • A FUS start request is sent via the IPCC and accepted by FUS.

Can I delete the FUS firmware?

No, the FUS firmware can not be fully deleted. It can only be upgraded.

Evaluation boards

  • TBD
Retrieved from "https://wiki.segger.com/index.php?title=ST_STM32WB&oldid=16393"