Nucleo-H723ZG LwIP HardFault_Handler problem

[MGaif.1]

I am using a NUCLEO-H723ZG board. To enable lwip, I need to enable CPU DCache. With the default settings, and further compilation and launch in STMCubeIde (latest version 1.12), the program always crashes with the error HardFault_Handler. All the same with the Nucleo-F767ZI board works without problems. I found a post on the Internet where a person says that rolling back STMCubeIde to one of the previous versions helped him with the same problem. But I think this is not the solution to the problem. How to solve this problem?

In Debugger Console:

No source file named D:\\...\\Core\\Src\\main.c.

Note: automatically using hardware breakpoints for read-only addresses.

set *(int *)0xE000EDFC=*(int *)0xE000EDFC|0x7F0

Temporary breakpoint 3, main () at ../Core/Src/main.c:77

77  MPU_Config();

[Imen.D]

Hello @MGaif.1​ and welcome to the Community 🙂

Check the debug configuration, and the .elf file.

Check the register and the address (0xE000EDFC) it may be is wrong and not defined.

It would be better to share your debugger log and screenshot of the error for more analysis.

Please have a look at this post, it may help you:

• How to make Ethernet and lwIP working on STM32

Imen

[MGaif.1]

0xE000EDFC : 0xE000EDFC <Hex> = F0070001

At startup, the first image is displayed (the first stop), at further startup it stops at HardFault_Handler (the second image) . I didn't write a single line of my code, I only indicated the use of FreeRTOS, lwIP + CPU DCache.

[MGaif.1]

I mixed up the images in places)

[MGaif.1]

The option to use CPU Control Mode or not, but the result does not affect

[MGaif.1]

Has no one ever faced a similar problem?

[Bob S]

Why do you need to enable DCache? Could you (or the Ethernet peripheral) be trying to DMA data into cached areas in RAM. If so, your code (or the HAL code) needs in invalidate the cache lines before trying to read that data. Can you try running with DCache disabled and see if it changes things.

The addresses in the stack back-trace do not look like valid code space addresses (though I am not entirely familiar with the H7 memory map). It could be that your stack is somehow getting corrupted, messing up function returns. If using an RTOS, double-check your task stack sizes. CubeIDE has a fault analyzer window. That will show you the registers. See if the SP value makes any sense (i.e. does it point to your stack area?).

[LCE]

I'm using that controller with ethernet.

I have all caches disabled.

Make sure that

• the descriptors are in SRAM1 and SRAM2 (D2 domain, starting at 0x30000000)

SRAM1_D2(xrw) : ORIGIN = 0x30000000, LENGTH = 16K

SRAM2_D2(xrw) : ORIGIN = 0x30004000, LENGTH = 16K

• no TX / RX buffers or any data that might be used by lwIP / ETH DMA are not in DTCM