Hard fault during EEPROM emulation Init with STM32C5A

[canyldrm]

Hello everyone,

I am having an issue with EEPROM Emulation initialization in my STM32 project.

I am currently trying to implement the EEPROM Emulation utility using STM32CubeMX2 v1.1.0.

The program starts with mx_system_init(), which initializes the peripherals and other required modules such as FLASH, RCC, etc. After that, I call mx_eeprom_emulation_init(). During this initialization, the MCU enters a HardFault.

Detailed information

The call hierarchy is:

main() → mx_eeprom_emulation_init() → EE_Init() → EE_FLITF_Init() → Page_GetState() → EE_ITF_FLASH_ReadData()

Inside EE_ITF_FLASH_ReadData(), the code tries to access address:

0x09000018

and immediately enters a HardFault.

I also analyzed the fault using the Fault Analyzer in STM32CubeProgrammer. The results are:

• SCB_BFAR: 0x09000018
• BusFault: Precise data access error (PRECISERR)
• The BusFault is escalated to a HardFault (FORCED)

I also checked the EDATA_EN option bit in STM32CubeProgrammer, and it appears to be enabled correctly.

At this point, I am not sure why accessing the EDATA region causes a BusFault.

Has anyone experienced a similar issue with EEPROM Emulation / EDATA on STM32C5 devices?

Is there any additional configuration required, such as MPU/SAU memory region configuration, privilege settings, or FLASH security/access configuration, before accessing the EDATA area?

Any suggestions would be greatly appreciated.

Thank you.

[STOne-32]

Dear ​@canyldrm ,

This Knowledge Article my help on debugging the case : 

Hope it helps ,

Regards,

STOne-32

[canyldrm]

I have already followed this guide and implemented the required code and configurations. However, the problem still persists. I think the EEPROM Emulation utility may have been updated because one of the #define statements mentioned in the guide does not exist in my version. Actually, I am not sure which version is newer.

[waclawek.jan]

I also checked the EDATA_EN option bit in STM32CubeProgrammer, and it appears to be enabled correctly.

What does this mean, exactly?

Can CubeProgrammer read the data area at 0x0900’0000?

JW

[canyldrm]

I checked in debug mode that the EDATA_EN bit is set to 1. I also reprogrammed the option bytes, setting it first to 0 and then back to 1.
I can see the data area at 0x0900’0000 there is no error while reading the address 0x0900’0000. All the values are 0xFFFFFFFF.

[waclawek.jan]

And what happens if you read given address in program before mx_eeprom_emulation_init()?

JW

[canyldrm]

I have tried to read the address 0x09000018 before mx_eeprom_emulation_init(), hard fault is occured(bus fault - precise data access violation). 
*((uint64_t *)p_data) = (*(volatile uint64_t *)0x09000018); simple read operation 

[waclawek.jan]

What happens if you try to read given address as a byte, halfword, word?

Also, what happens if you try to read from 0x08400000, instead?

I’m not familiar with the ‘M33, so if this is consequence of some security stuff, I am off.

JW

 

[Andrew Neil]

Debugging Cortex-M Hard Faults

[Khaled_DHIF]

Hello ​@canyldrm , 

Have you configured the MPU correctly in your code? I have tried this setup, and the mx_eeprom_emulation_init() API executes normally with no system exceptions raised:

system_status_t mx_cortex_mpu_init(void)
{
  /* Disables the MPU */
  HAL_CORTEX_MPU_Disable();

  /*
     Initializes and configures the MPU attributes
  */
  HAL_CORTEX_MPU_SetCacheMemAttr(HAL_CORTEX_MPU_MEM_ATTR_0, HAL_CORTEX_MPU_NORMAL_MEM_NCACHEABLE);
  HAL_CORTEX_MPU_SetCacheMemAttr(HAL_CORTEX_MPU_MEM_ATTR_1, HAL_CORTEX_MPU_NORMAL_MEM_NCACHEABLE);

  /*
     Initializes and configures the MPU Region
  */
  hal_cortex_mpu_region_config_t p_region_config = {0};

  p_region_config.base_addr = 0x8FFE000;
  p_region_config.limit_addr = 0x8FFFFFF;
  p_region_config.access_attr = HAL_CORTEX_MPU_REGION_ALL_RO;
  p_region_config.exec_attr = HAL_CORTEX_MPU_EXECUTION_ATTR_DISABLE;
  p_region_config.attr_idx = HAL_CORTEX_MPU_MEM_ATTR_0;
  HAL_CORTEX_MPU_SetConfigRegion(HAL_CORTEX_MPU_REGION_0, &p_region_config);

  HAL_CORTEX_MPU_EnableRegion(HAL_CORTEX_MPU_REGION_0);

  p_region_config.base_addr = 0x9000000;
  p_region_config.limit_addr = 0x900BFFF;
  p_region_config.access_attr = HAL_CORTEX_MPU_REGION_ALL_RW;
  p_region_config.exec_attr = HAL_CORTEX_MPU_EXECUTION_ATTR_DISABLE;
  p_region_config.attr_idx = HAL_CORTEX_MPU_MEM_ATTR_1;
  HAL_CORTEX_MPU_SetConfigRegion(HAL_CORTEX_MPU_REGION_1, &p_region_config);

  HAL_CORTEX_MPU_EnableRegion(HAL_CORTEX_MPU_REGION_1);

  /* Enables the MPU */
  HAL_CORTEX_MPU_Enable(HAL_CORTEX_MPU_HARDFAULT_NMI_DISABLE, HAL_CORTEX_MPU_ACCESS_FAULT_ONLY_PRIV);

  return SYSTEM_OK;
}

 

Tell me if this solves your problem. 

Kind regards, 

DHIF Khaled

[canyldrm]

I have enabled the MPU and configured the EDATA section as non-cacheable, as shown in this configuration.(I mean i have already tried but I could miss the something)

Before trying this approach, I have a question so that we can align our projects. Are you using CubeMX2 for project configuration?

If so, which peripherals are enabled, and what are the configurations of these peripherals?

[Khaled_DHIF]

Hello ​@canyldrm , 

Yes, this code was generated by CubeMX for the STM32C562RE Nucleo. The memory region is configured as ALL_RW, normal, and non-cacheable. With this setup, the HardFault you mentioned no longer occurs. No other peripherals are enabled; this is a simple CubeMX project with only the EEPROM utility and the MPU configured. Please share your .ioc file so we can inspect it.

Kind regards, 

DHIF Khaled 

[canyldrm]

I am using CubeMx2. 

[Khaled_DHIF]

Hello ​@canyldrm , 

I noticed that no MPU configuration has been set for the memory region containing EDATA in your .ioc file. Could you please verify that?

The EDATA region spans the following address range: 

and the MPU configuration should be: 

  p_region_config.base_addr = 0x9000000;
  p_region_config.limit_addr = 0x900BFFF;
  p_region_config.access_attr = HAL_CORTEX_MPU_REGION_ALL_RW;
  p_region_config.exec_attr = HAL_CORTEX_MPU_EXECUTION_ATTR_DISABLE;
  p_region_config.attr_idx = HAL_CORTEX_MPU_MEM_ATTR_1;
  HAL_CORTEX_MPU_SetConfigRegion(HAL_CORTEX_MPU_REGION_1, &p_region_config);

 

kind regards, 

DHIF Khaled

[canyldrm]

I created a new CubeMX project to avoid the previous issues. I configured the MPU as you mentioned and called mx_eeprom_emulation_init() before entering the while loop.
After running the code, I paused the debugger and noticed that the software was stuck in the Default IRQ Handler. I think I may not have configured the fault handlers correctly, so I couldn't determine the root cause.
Could you please check my latest ioc file?

 

[waclawek.jan]

Hi ​@Khaled_DHIF ,

Is this

the reason for setting up the MPU region to mark the 0x0900’0000… area as non-cacheable?

If so, how comes accessing the 0x0840’0000 area (which IMO is “data area”, too, isn’t it?) does not cause hardfault, even if it does not have MPU setup either?

A second question, why does RM say a *Hard Fault* will be generated? Wouldn’t the correct description be, “Bus Fault will be generated (escalated to Hard Fault if Bus Fault is not enabled)”?

JW