Skip to main content
SMcGr
SMcGr
Associate II
August 19, 2019
Solved

Receiving Hard Fault when trying to Mass Erase.

  • August 19, 2019
  • 2 replies
  • 1532 views

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

This topic has been closed for replies.
Best answer by Le Corre Pierre

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.

2 replies

Le Corre Pierre
Le Corre PierreAnswer
ST Employee
August 20, 2019

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
SMcGrAuthor
Associate II
August 20, 2019

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

C
Christophe Arnal
ST Employee
September 2, 2019

​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

Le Corre Pierre
Le Corre Pierre
ST Employee
August 21, 2019

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.

Terms & ConditionsAccessibility statement