Issues with flashing FUS and BLE stack to custom STM32WB55CE board

[GHajj]

I have a custom STM32WB55CE-based board on which I wish to run some BLE software.

I have attempted to flash them according to the instructions in the release notes in the coprocessor binary folder, but it throws an "RSS_IMAGE_NOT_FOUND" error and retries twice before giving up. Since the CE has 512KB of flash, I use the addresses given for that size. Since the BLE stack address is outside of the actual range of the 512 KB flash, I have also tried to flash it at an appropriate address by calculating the offset from the 1MB flash FUS address and applying it to the 512 KB address. This doesn't really change anything. The stack I'm trying to flash is the "stm32wb5x_BLE_Stack_fw.bin".

Reading the FUS version gives 0x01000200 which is correct for the binary I have tried to install, but as it doesn't actually work I'm assuming that something is wrong.

My understanding is that the FUS should be flashed at the absolute end of the flash (address end of flash - size of FUS) and that the BLE stack should be flashed just ahead of it (address FUS address - size of BLE stack). The sizes of these binaries aren't clear, so calculating the proper address isn't easy. I'm assuming that the file size isn't telling the whole story as the stated addresses don't line up in that case.

My guess as to why it doesn't work is that the option bytes are causing issues here. Exactly how everything is supposed to be laid out is not explained well in any reference manual or application note, so there is not a lot to go on. It is probably related to the security configuration, PCROP protection or something similar.

Where is the SBRV supposed to point? To the FUS? Or maybe the BLE stack? Has anyone else dealt with these problems?

I'll paste all the relevant option bytes in a code block.

RDP: AA
BOR_LEV: 0
 
nBOOT0: checked
nBOOT1: checked
nSWBOOT0: checked
SRAM2RST: unchecked
SRAM2PE: checked
nRST_STOP: checked
nRST_STBY: checked
nRSTSHDW: checked
WWDGSW: checked
IWGDSTDBY: checked
IWDGSTOP: checked
IWDGSW: checked
IPCCDBA: 0x0
 
ESE: checked
SFSA: 0xf4
FSD: unchecked
DDS: checked
C2OPT: checked
NBRSD: unchecked
SNBRSA: 0x10
BRSD: checked
SBRSA: 0x0
SBRV: 0x3d000
 
PCROP1A_STRT: 0x1ff 0x8000ff8
PCROP1A_END: 0x0 0x8000008
PCROP_RDP: checked
PCROP1B_STRT: 0x1ff 0x8000ff8
PCROP1B_END: 0x0 0x8000008
 
WRP1A_STRT: 0xff 0x807f800
WRP1A_END: 0x0 0x8000000
WRP1B_STRT: 0xff 0x807f800
WRP1B_END: 0x0 0x8000000

Hi.

I ask similar question 2 month ago, but they did not answer me.

https://community.st.com/s/question/0D50X0000B09GjHSQU/binary-install-address-for-stm32wb5xxe512k-and-stm32wb5xxc256k-devices

I also suggested that need to calculate the offsets, but have not tried it yet, since there is no suitable chip.

[MWB_CHa]

Hi,

First, SBRV and SFSA are pointing to the right addresses vs. FUS version V1.0.2 (0x080F4000).

And there is no PcROP protection set.

The address where you shall load your BLE binary is simply (0x08080000 - TotalBinaryFileSize).

When we say TotalBinaryFileSize, it means the size aligned to the nearest upper 4KB boundary (size of the sector).

For example, if binary size = 193KB (197632bytes), then TotalBinaryFileSize you shall use is = 207704bytes (196KB).

and so the address would be 0x08080000-0x31000= 0x08004F000.

Normally that should work, but make sure that you use the right version of BLE binary file (from same release package of FUS V1.0.2).

Other point that may lead to "RSS_IMAGE_NOT_FOUND" is when you leave an previous binary footer while loading a new one (ie. load a binary of size 192KB then load a binary of size 90KB in same address). In that case the FUS would detect the older binary footer and apply it to the new binary which is different and so will fail the upgrade operation.

So basically, best option is to perform a sector erase of all flash from 0x08080000 to the address where you will load your BLE binary to avoid any issues.

I hope it helps.

[Christophe Arnal]

Hello,

The above reply from CHa is all correct.

The BLE Stack provided in the v1.2.0 package is 0x28000 bytes size ( aligned on 4K).

On a STM32WB55CE (512K) device, it should be loaded at 0x08080000 - 0x28000 = 0x08058000

Make sure you have first erase all sectors until the top of the flash before starting the update process to make sure there is nothing left from a previous update that would be wrongly read by the FUS.

Regards.

[Remi QUINTIN]

First be sure to load the FUS FW at 0x0807A000.

0x0807E000 mentionned is the release notes is not a correct address to load the FUS FW. This should be corrected soon.

To know where to load any binary, you simply need to calculate the loading address = Flash end Address - Binary size.

For a 512KB device: Loading Address = 0x08080000-0x6000 (24KB of FUS size) = 0x0807A000.

In your case, the FUS update process answers with the error FW_NOT_AUTHENTIC because the binary is located in a wrong address and its footer is written outside the flash boundary and so can't be found by FUS and the authentication fail. You just need to place the binary in the right location as explained above.

Once the update done, the new FUS is installed in another memory location accessible by the M0+ core only and the space in the Flash memory starting from 0x0807A000 is free again for other applications.

Now, as the space used to download the FUS FW (it is different from the location where the updated FUS is installed) is free and as the BLE stack FW size is 0x28000, the address to load this RF stack is  0x08080000 - 0x28000 = 0x08058000.

Hope this is clarifying the overall update process and the computation of all these addresses.

Hi, Remi.

Hm, one clarifying question:

You very clearly explained everything, but why for the 1MB chip these numbers do not converge?

For example : using stack fw v.1.2.0 we have stack fw size is 0x28000 and fus fw size is 0x6000.

If we get max address of 1M chip = 0x100000 then loading address of stack fw should be 0x08100000-0x28000=0x80D8000, but in "Release_Notes.html" we see: 0x080CC000.

And loading address of FUS fw should be 0x08100000-0x6000=0x80FA000, but in "Release_Notes.html" we see 0x080EC000.

Why?

For 1 MB for chip to calculate the correct address, I have to do like this:

- for stack fw : 0xF4000-0x28000 = 0xCC000. Where 0xF4000 is 0xCC000+0x28000.

- for FUS fw : 0xF2000-0x6000 = 0xEC000. Where 0xF2000 is 0xEC000+0x6000.

Isn't it strange?

And second question:

Ho to calculate correct loading address on OTA bootloader update?

If we have installed stack - the SFSA for 1MB chip is 0xCC;

Its a true if todo ?:

SFSA-"stack fw image size" : 0xCC000 - 0x28000 = 0xA4000. I.e. loading address for stack fw image is 0xA4000 ?

And is need to call SHCI_C2_FUS_FwUpgrade with params like this:

SHCI_C2_FUS_FwUpgrade(0xA4000, 0);

[GHajj]

That seems to have worked, although I did get a "FW_NOT_AUTHENTIC" issue when flashing the FUS to 0x0807A000. The BLE went in without a hitch, however.

I wanted to test the BLE before responding, but I can't get the beacon sample to work properly, not even on a nucleo wb55. I do recall having some issues with getting it to work with previous versions of the software kit, but it ended up working after a while. Are any further modifications to the code necessary to make it work?

[Remi QUINTIN]

STM32WB can support both Client & Server roles on same device.

To test it you should try the p2p_client demo.

Two STM32WB55xx boards are used, one acting as GATT client, and one as GATT server.

Hi, Remi.

Hm, one clarifying question:

You very clearly explained everything, but why for the 1MB chip these numbers do not converge?

For example : using stack fw v.1.2.0 we have stack fw size is 0x28000 and fus fw size is 0x6000.

If we get max address of 1M chip = 0x100000 then loading address of stack fw should be 0x08100000-0x28000=0x80D8000, but in "Release_Notes.html" we see: 0x080CC000.

And loading address of FUS fw should be 0x08100000-0x6000=0x80FA000, but in "Release_Notes.html" we see 0x080EC000.

Why?

For 1 MB for chip to calculate the correct address, I have to do like this:

- for stack fw : 0xF4000-0x28000 = 0xCC000. Where 0xF4000 is 0xCC000+0x28000.

- for FUS fw : 0xF2000-0x6000 = 0xEC000. Where 0xF2000 is 0xEC000+0x6000.

Isn't it strange?

And second question:

Ho to calculate correct loading address on OTA bootloader update?

If we have installed stack - the SFSA for 1MB chip is 0xCC;

Its a true if todo ?:

SFSA-"stack fw image size" : 0xCC000 - 0x28000 = 0xA4000. I.e. loading address for stack fw image is 0xA4000 ?

And is need to call SHCI_C2_FUS_FwUpgrade with params like this:

SHCI_C2_FUS_FwUpgrade(0xA4000, 0);

[Remi QUINTIN]

A 1MB Flash device has a specific context: The FUS FW is part of its accessible workspace. It is installed at the top most area of its Flash memory which is hence not available for any FW download. While on the other devices, the FUS is installed (the final location which is not the location used for download) in a memory space that is not accessible from a user standpoint. So for a 512 KB Flash device, the complete memory space is available for the download of the new FUS, which will then be installed outside of the accessible memory space. The same happens with the RF stack download but the RF stack is installed where it is downloaded.

On a 1MB Flash device, you have to consider that a part of the memory space ( top addresses) is reserved for the FUS FW. Hence the recommended download addresses which cannot be calculated in the same way as for the 512 KB and 256 KB Flash devices.  Usually we recommend to keep 52KB at the top of the Flash memory (in case of a 1MB Flash device) for all the stuff related to the FUS.

Remi, thank You very match for answer.

How about second question of correct loading address on OTA bootloader update?

I experimented with download 1.2.0 stack using AN5185 #2.1.1 "Operation instructions" like this

1. calculate image size of stack -> 0x28 pages for 1.2.0 and 0x29 pages for 1.3.1

2. get current stack address from SFSA -> 0xCC

3. get current stack size from SHCI_GetWirelessFwInfo() "MemorySizeFlash" -> 0x28 pages

4. If new image size <= current image size, then : WirelessStackAddress - ImageSize.

I.e. for 1.2.0 stack : 0x28 == 0x28 and WirelessStackAddress = 0xCC-0x28 = 0xA4.

5. If new image size > current image size: WirelessStackAddress - (2xImageSize – WirelessStackSize)

i.e. for 1.3.1 stack : 0x29 > 0x28 and WirelessStackAddress = 0xCC - (2*0x29 - 0x28) = 0xA2.

and now I successfully load both that and that stack over 1.2.0.

Am I doing everything right or was I just lucky? :)

[Remi QUINTIN]

The calculation you did is no more required if you perform a FW delete before loading the RF stack.

Now I understand you want to ​update the RF stack over the air (OTA). In that case, You cannot perform a fw delete via OTA.

So you can load the RF stack anywhere ahead of the current RF stack and in that case your calculations are correct for 1.3.1 stack, or always at 0x08007000 just above the OTA application. The OTA application will look for the footer of the stack to install going through the complete un-secure part of the Flash memory.

Hi, Remi.

I assumed that this should be done, but since it has not been written about anywhere, I asked you as a successful specialist.

Your answer is comprehensive.

Thanks!