Skip to main content
Associate
September 24, 2025
Question

STM32H723 enable icache and dcache disable mpu: hardfault occurs with one piece among 100.

  • September 24, 2025
  • 4 replies
  • 801 views

When we were working on a small batch, we encountered a situation where one of about 100 pcbs would frequently trigger a hardfault. We found that the problem would recur when the cache was enabled. When the mpu was enabled and configured correctly, it would run normally. Only this one MCU had this problem. We determined that this was an individual, low-probability problem. Through experiments, we felt that the default memory attribute of its peripherals was normal, not device, which caused the error when accessing a reserved address during cache.

4 replies

Ozone
Principal
September 24, 2025

Software, as a sequence of instructions, is consistent, and does behave the same every time.

I suspect you have a problem with your power supply, the core clock frequency is at the limit, or both.
Or your PCB has EMI issues.

zxcAuthor
Associate
September 25, 2025

If it is a hardware problem, after I reconfigure the MPU, it will return to normal. The default MPU or not turning on the MPU (this is the default) will not work properly and the gpio initialization will hang.

mƎALLEm
Technical Moderator
September 25, 2025

Hello,

1- 100 boards are the same?

2- Same application?

3- What do you mean by configuring the MPU? give more details about that config.

4- Did you enable the MPU background config preventing the speculative access?:

void MPU_Config(void)
{
 MPU_Region_InitTypeDef MPU_InitStruct;

 /* Disable the MPU */
 HAL_MPU_Disable();

 /* Configure the MPU as Strongly ordered for not defined regions */
 MPU_InitStruct.Enable = MPU_REGION_ENABLE;
 MPU_InitStruct.BaseAddress = 0x00;
 MPU_InitStruct.Size = MPU_REGION_SIZE_4GB;
 MPU_InitStruct.AccessPermission = MPU_REGION_NO_ACCESS;
 MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;
 MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
 MPU_InitStruct.IsShareable = MPU_ACCESS_SHAREABLE;
 MPU_InitStruct.Number = MPU_REGION_NUMBER0;
 MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
 MPU_InitStruct.SubRegionDisable = 0x87;
 MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_DISABLE;

 HAL_MPU_ConfigRegion(&MPU_InitStruct);

 /* Enable the MPU */
 HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);
}

 

"To give better visibility on the answered topics, please click on ""Accept as Solution"" on the reply which solved your issue or answered your question."
Pavel A.
Super User
October 6, 2025

@zxc I apologize, misinterpreted the subregion disable mask. Indeed the range 0x08000000 is masked by bit 0 of the mask. So... no more ideas.

mƎALLEm
Technical Moderator
October 6, 2025

It's hard to find the root cause of this kind of issues in the forum.

To me:

- Either there is a quality issue so as I said you need to contact your local FAE  

- Or an issue in your boards: pins/balls not well soldered.

Do you have a way to measure the VCAP voltage level? if yes, measure it and compare to what was provided in the datasheet versus the VOS you are using.

"To give better visibility on the answered topics, please click on ""Accept as Solution"" on the reply which solved your issue or answered your question."
LCE
Principal II
October 6, 2025

Have you checked all power supplies with a scope and DMM ?

Stable clock source ?

Core voltage supply in the correct range for the internal clock frequency ?

Core voltage supply correctly set and buffered ?

PCB layout, ... - so much that can go / be done wrong.