Alternative Wireless Stack Install Address

[HRadt.1]

As far as I see, the wireless stack can be installed at any location.

Currently the Release Notes for the Coprocessor Binaries give an address to install them to, depending on the part flash memory size.

For example the BLE_Stack_light install location changed from version 1.6.0 to 1.8.0

When updating the wireless stack in the product (i.e. without deleting the old stack) and the new stack is larger than the previous one, AN5185 states:

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

Is the additional storage used temporarily? Or is the new stack installed below the current one?

In the latter case: would it be sensible to initially install the stack at a lower address to allow updates "in place" when the wireless stack size changes?

[Christophe Arnal]

​Hello,

The new stack replaces always the old one .

Eg:

If the current wireless stack is 100K and the new one is 120K, the FUS will secure 20K additionnal flash to install the new FW.

There is no lost/spare sectors in the secure flash after a wireless firmware is installed. The secure flash just fits what is needed.

Regards.

[HRadt.1]

Hello Christophe,

thank you for the details on this one.

One further question:

if new image size > current image size: WirelessStackAddress - (2xImageSize – WirelessStackSize)

still is true? I assume the additional space is used temporarily while extending the secure flash area?

Is it in general a problem to use any lower installation address during an update (meaning the formula just gives an upper bound)? This seems to work fine for me now, but I would appreciate it if you could confirm this.

[Remi QUINTIN]

​If you do not intend to upgrade the FW stack via OTA, I recommend you just perform a fwdelete command first and then load the stack just below the FUS area.(0x080F4000).

[HRadt.1]

I indeed intend to upgrade the wireless stack via OTA, so running a fwdelete is not an option.

[HRadt.1]

I tried testing this with the only test subject available: The BLE Light Stack. Its the only one that is available that changed it's install address with it's releases that are supported on the STM32WB55CE (512KB).

I installed the 1.5.0 stm32wb5x_BLE_Stack_light_fw.bin at the recommended address 0x08065000. Then I flashed the binary at address 0x08040000. This is LESS than the documented space needed during an update (violating the 2x ImageSize constraint). While the Stm32CubeProgrammer gave me an error message (FUS_STATE_ERR_UNKNOWN) the update worked (SFSA was changed to 0x62 and my firmware read the correct version 1.8.0).

if new image size > current image size: WirelessStackAddress - (2xImageSize – WirelessStackSize)

So is this constraint not needed? This is important for me since whith SBSFU there wouldn't be enough space to adhere to it on a 512kB device for the FULL stack.

[HRadt.1]

Since no answer was given I investigated further on my own:

It seems that if new image size > current image size: WirelessStackAddress - (2xImageSize – WirelessStackSize) is not a requirement.

What I observed though is, that all memory between the download address of the image up until the address denoted by SFSA will get erased in the process. Probably because of this, ST is recommending to install the new image as close as possible to the final address.

An official statement would be much appreciated though.

[Remi QUINTIN]

Hard to answer as this rule was given for the very first version of FUS V0.5.3.

It appears there is no relevant reason to apply this rule for the most recent versions.

In the end, the best way is to delete the previous FW and load the new one as close as possible from the base address of the FUS area (mostly 0x080F4000)

When the upgrade is performed via OTA, it is possible to load the new RF FW anywhere in memory at an address higher than 0x0807000. The BLE_OTA application will then scan the Flash memory to detect the start address of the new FW, decrypt it and finally install it in place of the current RF FW, which means at the closest area from the base address of the FUS area.

[Remi QUINTIN]

Just got confirmation that this constrint is valid for all FUS version when the old RF stack is not erased.

if new image size > current image size: WirelessStackAddress - (2xImageSize – WirelessStackSize)

The reason is that during copy and move, FUS shall have enough space to copy the new stack entirely.

Let’s take an example:

• Current stack (installed) is 100KB (=0x19000). Installed and running @0x080DB000 = 0x08F4000 - 0x19000.
• New stack (to be installed) is 162KB (=0x28800, which means 0x29000 afer 4KB rounding)
  • If you load the new stack @0x080DB000 - 162KB (rounded to 4KB = 0x29000) = 0x080B2000, the FUS will reject the operation
  •  If you load the new stack @0x080DB000 - (162KB x 2 (rounded to 4KB = 0x51000) - 100KB (0x19000)) = 0x080A3000, the FUS will accept the operation

But after installation is finished, FUS relocate the new stack at the optimum position @0x080CB000, which is 0xF4 - 0x29 =0xCB.

So no space is wasted!!!

[HRadt.1]

Thanks for comming back at this. But this is not what I observe in reality. I can install a larger stack while violating the 2xImageSize constraint.

My scenario:

STM32WB55CE (512k = 0x80000 Flash)

1 Image SBSFU installed (user area starts at 0x08016000)

Upgrading from 1.8.0 Light (4k rounded size: 0x1E000, installed at 0x08062000) to Full stack (4k rounded size: 0x29000, should be installed at 0x08057000).

while adhering to the constraint, this should not be possible.

I followed these steps

1. Fresh install of BLE_light_fw (1.8.0) at 0x08062000
2. Check SFSA to be 0x62
3. Install SBSFU with custom BLE loader
4. Load BLE_full_fw (1.8.0) to address 0x08016000 (start of download/application area)
5. Trigger the installation process on CPU2 through IPCC
6. Check Wireless Stack Type and version with SHCI_GetWirelessFwInfo()
7. Check SFSA to be 0x57

With the constraint, the maximum install address in step 4 must be (0x08080000 - 0x1E000 - 2*0x29000 = 0x08010000) which I clearly break by downloading it at 0x08016000

Could you please explain?