H743 ._user_heap_stack in D2 section causes Hard Fault

[Joerg Wagner]

Posted on January 03, 2018 at 22:16

Hello.

Why is it not possible to point the ._user_heap_section in the D2 RAM section?

A tiny project based on SW4STM32 for NUCLEO-H743ZI is attached.

I just modified the linker script to have _user_heap_stack in D2 and not DTCM or D1.

I'm not able to debug this app.

Basically there is a D1-to-D2 AHB bridge to provide a link via AXIM to the CPU.

I have no idea because it works when it is located in D1 for instance.

Thank you, Joerg

[Tesla DeLorean]

Posted on January 04, 2018 at 14:58

Does the memory need initialization or mapping?

Could you set the Initial SP to some working Internal SRAM, and then change the stack to the memory you want after SystemInit is called but before main?

Not using the H7 here, but presumably you could uncheck 'run to main()' and step that startup code and see if the processor faults, and if so what causes it flags, and then work to address/resolve those issues.

[Joerg Wagner]

Posted on January 04, 2018 at 15:34

Thanks for the ideas. Well it makes more sense having a H743.

Stepping through is difficult. Currently it stops at:

void HAL_TIM_IRQHandler(TIM_HandleTypeDef *htim)

{  /* Capture compare 1 event */  if(__HAL_TIM_GET_FLAG(htim, TIM_FLAG_CC1) != RESET)

called from SystemClock_Config() -->   ret = HAL_RCC_OscConfig(&RCC_OscInitStruct);

I used the CubeMX 4.23.0 to generate SystemClock_Config() and one of the HAL examples (GPIO),

because there are a lot of differences and I believe more in HAL than CubeMX.

As I mentioned before: domains D1 and DTCMRAM work

[Joerg Wagner · Accepted solution]

Posted on January 07, 2018 at 19:51

An important code line in SystemClock_Config is missing which CubeMX does not generate:

https://community.st.com/0D50X00009XkYPsSAN