STM32H747IGT6 stuck

[Katsu_RRSC]

Hello.

I have designed my own STM32H747IGT6 board.

And I created a simple project with STM32CubeIDE to confirm its operation.

In this project, CM7 is a program that simply blinks the LED in a while loop. (CM4 is just code generation)

 while (1)
  {
    HAL_GPIO_TogglePin(GPIOE,GPIO_PIN_9);
    HAL_Delay(200);
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
  }
  /* USER CODE END 3 */
}

However, when I debug the M7, the code stops at this point and I can't continue.

  /* 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();
  }

This is obviously happening because CM4 is not running.

So I checked this link and changed the run configuration and debug configuration for CM7 and CM4, but it still stuck at the same point.

Also, after reading AN5286, I checked the addresses of CM7 and CM4 in STM32CubeProgrammer, but they were the same as the default addresses mentioned in the AN, so I did not change the addresses.

I don't know if this is a hardware or software issue.

Because it was my first time designing a board using this microcontroller.

[peterdonchev]

Hi,

Will you be using the CM4 core?
If not, I think you can disable it completely and remove the synchronization code from the main function.
I am currently working on a project with the STM32H747XIH and utilizing both cores.

Some observations:
To debug both cores, they must be enabled in the USER option bytes. With the current tools, debugging will not work if only one core starts and then enables the other.

Additionally, I have modified the synchronization code in the following way:

/* USER CODE BEGIN Boot_Mode_Sequence_1 */
  /* Wait until CPU2 boots and enters in stop mode or timeout*/
  while((__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) != RESET));
/* USER CODE END Boot_Mode_Sequence_1 */
......................................
/*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 */
while((__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) == RESET) );
/* USER CODE END Boot_Mode_Sequence_2 */

I simply removed the timeout variable and the error handling.
Please note that this is not the final production code; it is intended for development purposes only.

Regards,
Peter

[Imen.D]

Hello @Katsu_RRSC ,

You can refer to this application note as a reference for CM7 and CM4 project configuration :

• AN5361 Getting started with projects based on dual-core STM32H7 microcontrollers in STM32CubeIDE.

I advise you also these tutorials to configure the debugger on STM32H7 dual core:

• Video: Dual Core Debugging on STM32H7 with STM32CubeIDE
• STM32H7 Dual-Core: How to communicate between CM4 ... - STMicroelectronics Community

[Imen.D]

• AN5361 Getting started with projects based on dual-core STM32H7 microcontrollers in STM32CubeIDE.

[Katsu_RRSC]

Thank you for your reply!

I plan to use the CM4 core in the future, but for now I just wanted to check how it works so I tried it with CM7 only.
To do that, I first unchecked BCM4 in CubeProgrammer and removed the timeout variable and error handling as you said.
I then ran the program, but the LED did not blink.
I tried debugging instead and found that it was stopping at the following point.

while((__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) != RESET));

What is the reason for it stopping?

Also,you said that debugging doesn't work, is that why it's stuck during debugging?

If so, how can I check that it works?

I am having trouble because there is very little information on the Internet about the operation of the multi-core STM32H747.

By the way, it worked without any special configuration on H747-DISCO. I'm really confused.

[peterdonchev]

Hi Katsu_RRSC,

This code is necessary only if Cortex-M4 (CM4) is enabled. If CM4 is disabled, the synchronization code, including both loops waiting for CPU2 (CM4), should be removed. Specifically:

• Remove the loop that waits for CM4 to boot and enter stop mode:

while((__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) != RESET));​

• Remove the loop that waits for CM4 to wake up from stop mode:

while((__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) == RESET));

Please review my comment again, and I suggest following the advice provided by @Imen.D .

Regards,
Peter

[Katsu_RRSC]

Thank you so much for your quick reply!
I'm not a native speaker so I use machine translation to read your text. It seems I misread your text. Sorry about that.

I deleted the loop as you said, but then I got the message "Target is not responding, retrying..." during writing and couldn't write. After that, I solved it by setting boot0 to high and erasing the flash.

Also,when you say "the synchronization code", does that just mean these loops and the error handling?

The advice by @Imen.D is about dual core debugging, so I would like to try that after it works with just the CM7 core.

[peterdonchev]

I just ran a quick test with VSCode, and I can write and debug the CM7 core with the CM4 core disabled. What IDE are you using? You might need to check the debug configuration. What debug tool are you using? Please note that the ST-Link V2 is very unreliable, and I often have to disconnect and reconnect it (including cycling the board's power).

---

Also,when you say "the synchronization code", does that just mean these loops and the error handling?

Yes, error handling is not necessary for debugging.

[peterdonchev]

P.S.: Could you share your project?

[Katsu_RRSC]

I am using STM32CubeIDE.
I am using ST-LinkV3MINIE as a debug tool.
It doesn't work well with the board I designed, but when I write a program with the exact same settings on H747I-DISCO, it works fine...

I've also attached some files, is this enough?(I've changed the file names.)

[peterdonchev · Accepted solution]

Unfortunately, I'm already using STM32CubeMX 6.13.0, so I had to migrate the project. After the migration, I adjusted the power supply settings in RCC

and updated the LED GPIO to the corresponding port on my board, PF7. The test successfully ran on my board, and the LED is flashing. I'm attaching my project.