STM32H755 CM7 Reset_Handler Stuck at 'ldr sp, =_estack'

[durna]

Hello everyone,

I am currently working on a project using the STM32H755 microcontroller, and I am facing an issue with the program getting stuck in the `Reset_Handler` during debugging. Specifically, the code halts at the instruction `ldr sp, =_estack`, which sets the stack pointer, and does not proceed further.

### Project Setup:
- **Microcontroller**: STM32H755
- **Core**: Only using the Cortex-M7 (CM7) core, with Cortex-M4 (CM4) code generation disabled.
- **Debugger**: ST-LINK V3
- **IDE**: STM32CubeIDE
- **Firmware**: No custom firmware for CM4, only CM7 is active.

### Steps Taken:
1. I created the project with STM32CubeMX, configured it to use only the CM7 core (CM4 is disabled).
2. During debugging, the code reaches `Reset_Handler` but gets stuck at `ldr sp, =_estack`.
3. I have tried stepping through the code and confirmed the program halts at the stack pointer initialization.

### Possible Causes Considered:
- **Dual-Core Synchronization**: Since this is a dual-core MCU, I suspect there might be some synchronization code left that attempts to wake up CM4, causing CM7 to wait indefinitely.
- **Linker Script**: I have reviewed the linker script but am unsure if the stack pointer (_estack) is correctly defined for CM7's RAM region.
- **Memory Configuration**: I am also wondering if the memory regions are correctly defined in the linker script, especially since CM7 and CM4 share certain memory areas.
- **ST-LINK V3 Debugger**: It's possible that the debugger configuration might be causing some issues with resetting the core.

### What I Need Help With:
- Has anyone encountered a similar issue with the STM32H755 or other STM32H7 series MCUs? Specifically with single-core operation where CM4 is not being used.
- Could this issue be related to a dual-core synchronization process that’s still present in the code, even though CM4 is disabled?
- What changes should be made in the linker script to ensure the correct stack pointer for CM7 is used?
- Any advice on how to bypass or resolve the issue with the `Reset_Handler` getting stuck?

I would greatly appreciate any help or suggestions!

Thank you in advance!

Best regards,

[Tesla DeLorean]

What address SPECIFICALLY is it trying to load?

Does it need to load this? Doesn't it implicitly load SP/PC to reach Reset_Handler?

You have a working Hard Fault Handler?

Settings in Option Bytes?

[TDK]

> I have tried stepping through the code and confirmed the program halts at the stack pointer initialization.

How exactly are you "confirming" this? What happens when you press play and then pause?

Are hardware watchdogs enabled in option bytes?

Doesn't matter if _estack is defined correctly, this statement can execute. Core sync issues also would not matter here.

[durna]

Steps I Took:

1. I used CubeProgrammer to remove the checkmark from the BCM4 box, which disabled the M4 core. After this, I clicked Disconnect and closed the CubeProgrammer application.

2. Then, I opened CubeIDE, created a new project, and selected the appropriate board.

3. For the M7 core, I enabled the CPU ICache and DCache options.

4. I assigned the pins I selected for controlling the LEDs to the M7 core.

5. In the RCC tab, I enabled the HSE option and configured the clock settings to 400 MHz.

6. I clicked on Code Generate, and all the code was written into the main.c file under the CM7 core.

7. Inside the main.c file, I commented out the following lines of code: 

   /* Wait until CPU2 boots and enters in stop mode or timeout*/
   timeout = 0xFFFF;
   while((__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) != RESET) && (timeout-- > 0));
   if (timeout < 0)
   {
   Error_Handler();
   }
   
   /*Take HSEM */
   HAL_HSEM_FastTake(HSEM_ID_0);
   /*Release HSEM in order to notify the CPU2(CM4)*/
   HAL_HSEM_Release(HSEM_ID_0,0);
   /* wait until CPU2 wakes up from stop mode */
   timeout = 0xFFFF;
   while((__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) == RESET) && (timeout-- > 0));
   if (timeout < 0)
   {
   Error_Handler();
   }

8. I built the project after editing the code.

9. Then, I proceeded to debug for the CM7 core.

10. I added the following code inside the while (1) loop:"HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_10);
    HAL_Delay(1000);
    HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_11);
    HAL_Delay(1000);

11. I built the project and started debugging for CM7. The code execution started at SCB_EnableICache();.

12. I pressed Step Over, and the code reached SCB_EnableDCache();. After pressing Step Over again, the program no longer stayed inside the main.c file. Instead, the Step Over and Resume buttons became inactive, and I could not click them anymore.

13. It seems that the code is stuck at the ldr sp, =_estack line, as I suspected earlier.

[durna]

all files of project is here https://github.com/hasandurna/stm32h755

[mƎALLEm]

Hello,

I tested your project and all are fine. I can reach while (1) and toggle the pins.

I have a doubt in your option byte configuration. Could you please unzip and upload the attached option byte configuration using STM32CubeProgrammer?

Refer to this article: Restoring the STM32 option bytes to their factory settings using STM32CubeProgrammer / section 1.2 Option bytes factory reset (import option).

[mƎALLEm]

Hello,

Now I'm reading this:

---

I pressed Step Over, and the code reached SCB_EnableDCache();. After pressing Step Over again, the program no longer stayed inside the main.c file. Instead, the Step Over and Resume buttons became inactive, and I could not click them anymore.

---

Don't step over/into SCB_EnableICache/SCB_EnableDCache.

Put a break point at HAL_Init() and step over starting from this point.

[durna]

Hello and thank you.

I want to try the solution you mentioned, but the version of CubeProgrammer that my computer supports is 2.7.0.

In this version there is no arrow next to the “read” button as mentioned on the site you directed me to and therefore I cannot select the “Export current MCU option bytes” option.

What should I do now?

[mƎALLEm]

See my last comment, it seems it's not an option byte issue but stepping over SCB_EnableICache/SCB_EnableDCache is not recommended. 

[durna]

ok now I am trying the method you mentioned, but is there anything wrong with the other operations I did?

Shutting down the M4 kernel via CubeProgrammer, putting the code to wake up the M4 kernel in main.c (M7) in the comment line etc?