STM32WB - IPCC - Hard Faullt

[JR2963]

Hello,

I am working on an STM32WB project where I need to erase and write to the flash memory. I have utilized the flash_driver.c files that I found in the STM32WB examples. I tried to integrate these into my project (which does not use FreeRTOS or BLE - though I had to enable BLE in CubeMX to satisfy flash_driver.c dependencies).

However, I encounter a hard fault when calling the uint32_t FD_EraseSectors(uint32_t FirstSector, uint32_t NbrOfSectors) function. The crash occurs specifically at the following line:

 

 

 

shci_send(SHCI_OPCODE_C2_FLASH_ERASE_ACTIVITY, 1, local_buffer, p_rsp);

 

 

 

I am unsure how to debug this issue. Could you please provide some guidance or advice on how to resolve this problem?

Thank you.

[Lubos KOUDELKA]

Hello,
in case CPU2 is not turned on (cases where radio is not used), there is no need to use flash driver with synchronization to second core. Simple flash access like on other single core STM32 MCUs shall be used. Example FLASH_EraseProgram can be followed in this case. 
Sending shci command when CPU2 is not used/initialized trigger hardfault as used resources are not initialized.

Best regards,
Lubos

[JR2963]

@Lubos KOUDELKA  Thanks for the answer. I need to clarify something please. I'm using BLE (I have the Stack + FUS loaded). However, I have a custom Bootloader that needs to erase and write to flash memory, and only when it jumps to the application is BLE used (BLE is not utilized in the bootloader). But I assume that if I'm in the bootloader, CPU2 is already running because the FUS and STACK are loaded, right?! 

[Lubos KOUDELKA]

Hello,
CPU2 is started by CPU1 - fact, that BLE stack is loaded does not mean automatically, that it's used. In general, until CPU2 is not started (C2BOOT bit in PWR_CR4 register), no flash access protection is needed. When CPU2 is initialized, flash need to be handled as shared resource.
As you're getting hardfault when you try to use shci_send from my bootloader, I expect CPU2 is not activated in your bootloader.
You may verify in debug by checking C2BOOT bit, that CPU2 (RF) is not yet active in your bootloader and turned on later in your application.

[JR2963]

Thank you, For sure I call function 

HAL_PWREx_HoldCore(PWR_CORE_CPU2); in my bootloader