Skip to main content
SKopp.2
SKopp.2
Associate
August 28, 2020
Solved

Coprocessor Binary upgrade procedure from CPU1 (without using bootloader/SWD)

  • August 28, 2020
  • 6 replies
  • 2373 views

AN5185 mentions the process to install a new/updated version of the coprocessor binary.

My setup:

STM32WB5xxE(512K)

stm32wb5x_BLE_Stack_full_fw.bin (v1.6.0)

I'm able to program the BLE stack using a debug probe (SWD) using the description given in the Copro_Wireless_Binaries Release Notes.

AN5185 gives the following instructions to calculate the program address:

  1. If new install (no wireless stack currently installed): 0x08000000+(SFSA x 4KB) - ImageSize
  2. If a wireless stack is already installed:
    1. If new image size <= current image size: WirelessStackAddress - ImageSize
    2. If new image size > current image size: WirelessStackAddress - (2xImageSize – WirelessStackSize

It is advised to perform a FUS_FW_DELETE operation before starting a wireless stack

installation. (This is performed by CubeProgrammer when option -firstinstall=0 is selected)

For case 1 (no stack currently installed) the calculation yields a different address than the release notes:

SFSA: 0xF4

ImageSize: 164.816 bytes

--> Program Address = 0x08000000 + (0xF4 * 4KB) - 164816 = 0x80C BC30

Which is different from the (working) 0x805 7000

Not surprisingly when trying to install the stack with address 0x80C BC30 it fails.

For case 2.1 (a version of the wireless stack is already installed, new image smaller or equal in size):

Wireless Stack Address (i assume current): 0x805 7000

ImageSize: 164.816 bytes

--> Program Address = 0x805 7000 - 164816 = 0x802 EC30

Trying to update the stack with this address fails.

Case 2.2 I didn't try yet.

All the attempts to program were made with the Stm32CubeProgrammer tool, supplying the firstinstall=1 argument for it not to erase the stack previous to installing/updating.

So the questions are:

  1. Why do the calculated addresses differ from what is listed (and working) in the Release Notes?
  2. What is the correct procedure to update (without deleting) the wireless stack
  3. How does the FUS find a newly installed image? Which address is it looking at to find it?

Regarding question 3: AN5185 also states in the footnotes of Table 9 that when sending a FW_UPGRADE IPCC command to CPU2, the source and destination address fields are currently not supported. This is also seen in the BLE_OTA demo application, which supplies these parameters as 0, which then does not include them in the IPCC message. How will CPU2 find the encrypted image in case of an update (i.e. old stack not deleted)?

Your help on this topic is highly appreciated!

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

​For the value of the key word or the programming process, please have a look at the application note AN5185. All is esplained there.

6 replies

Remi QUINTIN
Remi QUINTIN
Technical Moderator
August 31, 2020

​1) Addresses provided in the releases notes (not the AN) are always assuming a cleanup of the secure part of the Flash memory. This is achieved calling the fwdeletete command which erases the RF FW stack and set the SFSA to 0xF4 which is the very start of the FUS area.

Then you just have to calculate le size of the FW you want to download and subtract is from address 0x080F4000.

2)The correct procedure is the one described in AN5185 but it is not very optimized from a free memory standpoint.

The previous wireless stack would never been erased and the new one would be stored further down the flash memory, consuming even more free memory area. There is no interest to keep the previous wireless stack.

3) On reset, the FUS is activated and go through the Flash memory , starting from address 0x08000000, looking for a specific magic number which indicates the start of the new FW. So you can download the FW wherever in the flash memory and the FUS will find it. Note that the wireless stack is installed at the location it has been downloaded. So in order to keep the maximum free space for the user application, it is key to load the RF FW as close as possible from the FUS area (as stated in point 1).

SKopp.2
SKopp.2Author
Associate
August 31, 2020

Hello,

thank you for the explanation of the process.

So for downloading a new wireless firmware via a wireless connection one would need to

  • Download the new Wireless FW in a temporary/download area
  • Delete the old stack
  • copy the Wireless FW to the designated address
  • request FUS to install it

Could you give details about the magic number? The idea would be to modify the magic while the image is stored in the temporary area to avoid accidential installation at a wrong address and re-installing the correct magic when moving the image to the correct address.

Thank you in advance.

Remi QUINTIN
Remi QUINTIN
Technical Moderator
August 31, 2020
  1. Delete the old stack
  2. Download OTA the new Wireless FW to the designated address
  3. Reboot
  4. FUS wil check if an upgrade request has been issued and install the new FW.

I am not aware of the magic key word indicating the start of the new image.

SKopp.2
SKopp.2Author
Associate
September 1, 2020

How would an OTA download in step 2 work when the old stack has been deleted in step 1?

Remi QUINTIN
Remi QUINTIN
Technical Moderator
September 1, 2020

​You are perfectly right. My mistake. it is OTA.

In  fact the RF stack must remain in Flash memory to perform the OTA.

So you download the new RF stack somewhere below the current SFSA pointer.

Then the FUS will analyse it, decrypt it and if all is OK, install it at the location of the old RF stack.

The sequence is absolutely not the same as when it is done via CubeProgrammer.

Remi QUINTIN
Remi QUINTINAnswer
Technical Moderator
September 1, 2020

​For the value of the key word or the programming process, please have a look at the application note AN5185. All is esplained there.

SKopp.2
SKopp.2Author
Associate
September 1, 2020

Another oddity:

When no Wireless Stack is installed SFSA is 0xF4. This results in a starting safe memory Address of 0x080F 4000.

This is outside of the flash memory area for the 512kB variant of the STM32WB55.

When using this base address and accounting for the 4k page boundary yields the supplied addresses for the 1M Flash part. So using the calculation 0x08000000+(SFSA x 4KB) - ImageSize is only valid for the 1M part?

Remi QUINTIN
Remi QUINTIN
Technical Moderator
September 2, 2020

Whatever the type of device, the FUS is always installed in the FUS area somewhere over 0x080F4000.

So for a 512KB Flash memory device, the FUS is not impacting the memory space used for the RF stack or the user application.

Hence SFSA = 0xF4 after a FWdelete command. This is indeed out of the memory space available for the user but it is done on purpose.

So the calculation you are using should not consider the SFSA after a Fwdelete command. You should just load your binary at the address 0x08000000 +Size of the Flash memory - ImageSize .

When a FW is already installed and you don’t do a fwdelete command (OTA case), then the address should be 0x08000000+(SFSA x 4KB) - ImageSize.

Terms & ConditionsAccessibility statement