Issues with flashing FUS and BLE stack to custom STM32WB55CE board

GHajj · ‎2019-08-14

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

Vyacheslav · ‎2019-10-22

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 · ‎2019-10-25

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.

Vyacheslav · ‎2019-10-25

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!

Vyacheslav · ‎2019-10-25

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!