Receiving Hard Fault when trying to Mass Erase.

[SMcGr]

Hi everyone,

I am using the Nucleo-WB55RG to try and fully erase/program the flash memory. However, when the FLASH_MassErase() function is called in stm32wbxx_hal_flash_ex.c, a hard fault exception occurs. I believe this has to do with trying to erase the secure memory only accessible through CPU2. When I try to boot up CPU2 (set C2BOOT pin) I receive a PGSERR flag in the FLASH_C2SR register. This has been extremely inconvenient that for the entire flash to be erased, you need execute from CPU2 and the boot process is not exactly straight forward. Are there any suggestions on how to gain access to CPU2 and perform the mass erase function? Thanks.

Steve

[Le Corre Pierre · Accepted solution]

Dear @steven.mcgrath1.565121516664519E12,

As you mention, the function FLASH_MassErase() present inside stm32wbxx_hal_flash_ex.c of  STM32CubeWB V1.2.0 cannot be used.

This is linked to the security on the FLASH only accessible to the CPU2. This function has been introduced to support some enginering sample and can now be removed.

We will remove this function in the next delivery of stm32cubewb, keeping only the

EraseInitStruct.TypeErase = FLASH_TYPEERASE_PAGES;

You can refer to the example present inside the STM32CubeWB V1.2.0 under:

• Projects\P-NUCLEO-WB55.Nucleo\Examples\FLASH\FLASH_EraseProgram

This example explains how to configure and use the FLASH HAL API to erase and program the internal Flash memory with FLASH_TYPEERASE_PAGES.

Edit: Add direct link to the example under github

Best regards.

Pierre.

[SMcGr]

Hi Pierre,

Thank you for the fast response this was extremely helpful. I am just curious as to the importance of the CPU2. I notice that there are registers located in the flash memory section of the reference manual that use CPU2, however, in your application note AN5247 it states that " The secure part is accessible by CPU2 only, and contains RSS and the wireless firmware. This part is not accessible by the debug port, by the user application or by the bootloader". Does this suggest that CPU2 is not accessible to the user even though there are R/W control registers in the reference manual? Any clarification regarding either the access of CPU2 or the significance of the CPU2 registers in the Flash register section of the reference manual would be greatly appreciated. Thank you.

Steve

[SMcGr]

Hi Pierre,

One last question as well. I realize that the Secure Flash memory start address is set in the FLASH_SFR flash register. Is there any documentation on what this value will be depending on the flash size of the processor? Is this register able to be modified or a set value?. For example, I am assuming it will be a different value for the STM32WBCC (256kB of flash), STM32WBCE (512kB of flash), and the STM32WBCG (1Mb of flash) processors. I already know that in the G series this value is set to 0xCB000, however this cannot possibly be constant for all series since it is larger than the total flash size.

Steve

[Le Corre Pierre]

Dear @SMcGr​ 

In STM32WBxx product, the CPU2 is dedicated to wireless firmware and Firmware upgrade service.

They take the form of binaries and are provided by ST only. Only those officials binaries are accepted by the device.

They can be found inside the STM32CubeWB V1.2.0 under:

• Projects\STM32WB_Copro_Wireless_Binaries

You can find inside the same directory a detailed explanation on how to use those binaries (Release_Notes.html)

Firmware Upgrade Services Binary

• stm32wb5x_FUS_fw.bin

Wireless Coprocessor Binary

• stm32wb5x_BLE_Stack_fw.bin
• stm32wb5x_BLE_HCILayer_fw.bin
• stm32wb5x_Thread_FTD_fw.bin
• stm32wb5x_Thread_MTD_fw.bin
• stm32wb5x_BLE_Thread_fw.bin
• stm32wb5x_Mac_802_15_4_fw.bin
• stm32wb5x_rfmonitor_phy802_15_4_fw.bin

The FLASH_SFR register is only accessible by the CPU2 and permit to manage the different binaries above and various STM32WBxx devices.

This means effectively that the CPU2 is not accessible by the user.

BR.

Pierre.

[Christophe Arnal]

​Hello,

The Secure area is accessible only by the CPU2 but all C2_xx registers may be accessed by both the CPU1 and the CPU2.

1/ The C2_xx register should be written only by the CPU2. The goal is to avoid  sharing configuration between the two CPU by Software and using a semaphore to configure a single resource

e.g :

If the CPU2 needs the GPIOA clock, it just needs to set the GPIOAEN bit in the RCC_C2AHBENR register

if the CPU1 needs the GPIOA clock, it just needs to set the GPIOAEN bit in the RCC_AHBENR register

When any of the CPU does not need the clock, it can reset the clock with its own bit without wondering if the other CPU needs the clock or not.

Only when both bits are set to '0', the clock is made OFF by hardware.

Without the C2 register, you need to use a semaphore to avoid collision to access the register and most important, you need to share between the two CPUs the information on whereas the clock is required by one of the two CPUs so that you don't wrongly switch OFF the clock when you don't need it anymore whereas the other CPU may still need it.

2/ There is no risk on the security when the CPU1 writes these C2 registers, the only side effect is that you may corrupt the CPU2 behavior

Regards

[Christophe Arnal]

​Hello,

The secure flash area is fully under control of the CPU1 and there is nothing you can do to change it.

The address may change according to the product and may change as well slightly for the same product in case the CPU2 firmware binary increases between two update.

It is therefore recommended to keep at least one extra flash sector free below the secure area if you plan to update the CPU2 firmware with a new version that could be greater than the current one.

The secure flash address is automatically calculated by the FUS depending of the product and the CPU2 firmware to be installed/updated.

Regards.