en.stm32cubeh7_v1-9-0\STM32Cube_FW_H7_V1.9.0\Projects\STM32H735G-DK\Demonstrations\Oscilloscope_SignalsGenerator\STM32CubeIDE

[senthil]

Oscilloscope_SignalsGenerator example Not Loading the Kit. i got the Error like

Error in final launch sequence:

Failed to execute MI command:

load E:\\ST\\en.stm32cubeh7_v1-9-0\\STM32Cube_FW_H7_V1.9.0\\Projects\\STM32H735G-DK\\Demonstrations\\Oscilloscope_SignalsGenerator\\STM32CubeIDE\\Debug\\Oscilloscope_SignalsGenerator-STM32H735G-DK_OoB_V1.0.0.elf 

Error message from debugger back end:

Load failed

Failed to execute MI command:

load E:\\ST\\en.stm32cubeh7_v1-9-0\\STM32Cube_FW_H7_V1.9.0\\Projects\\STM32H735G-DK\\Demonstrations\\Oscilloscope_SignalsGenerator\\STM32CubeIDE\\Debug\\Oscilloscope_SignalsGenerator-STM32H735G-DK_OoB_V1.0.0.elf 

Error message from debugger back end:

Load failed

Failed to execute MI command:

load E:\\ST\\en.stm32cubeh7_v1-9-0\\STM32Cube_FW_H7_V1.9.0\\Projects\\STM32H735G-DK\\Demonstrations\\Oscilloscope_SignalsGenerator\\STM32CubeIDE\\Debug\\Oscilloscope_SignalsGenerator-STM32H735G-DK_OoB_V1.0.0.elf 

Error message from debugger back end:

Load failed

Load failed

[Imen.D]

Hello @senthil​ ,

Which CubeIDE version are you using ?

I added the topic "STM32CubeIDE" to your question in order to increase its chance to be reviewed by our CubeIDE experts.

Hello @Markus GIRDLAND​ ,

Can you please help on this issue ?

Imen

[senthil]

STM32CubeIDE

Version: 1.6.1

Build: 9958_20210326_1446 (UTC)

[Markus GIRDLAND]

Hello senthil!

First of all, the linker script is wrong. The flash address is set to 0x9080000 which should be 0x8000000. It's either a fault in the documentation or the example project.

From our testing it looks like the example project is configuring the power regulator into the wrong mode as well.

The error stems from this:

/** Supply configuration update enable
*/
HAL_PWREx_ConfigSupply(PWR_LDO_SUPPLY);
/** Configure the main internal regulator output voltage

So, I will probably need to refer this along to @Amel NASRI​ . What is the correct power regulator configuration for an STM32H735G-DK? Seems to be different in MX generated project vs example projects... None work well?

[Amel NASRI]

Hi @senthil​ & @Markus GIRDLAND​ ,

Default configuration for STM32H735G-DK is SMPS mode. This is what we find in UM2679 Discovery kit with STM32H735IG MCU.

Being in a deadlock situation because of a mismatch between HW & FW setting for the power, it is required to follow the sequence described in the same user manual:

1. Power off the board.
2. Set SW1 (BOOT0) to 1 (system memory). This changes the BOOT0 pin to 1 instead of 0, thus changing the device boot address to boot address 1 and making the bootloader start in System memory. This avoids starting firmware in the user Flash with a wrong SMPS/LDO configuration versus the hardware board configuration.
3. Power on the board and connect using STM32CubeProgrammer
4. Erase the user Flash.
5. Power off the board and set SW1 to 0.
6. The board is recovered and can be used normally with matching firmware PWR.

You can find some more details in this article as well: Unable to connect to STM32H7 devices.

-Amel

PS: PS: Once your question is answered, please click on "Select as Best" for the comment containing the answer to your initial question.

[senthil]

i follow your steps, still i am getting Same Error but other example folder Projects Working this Demonstrations Folder Projects Not working.

[mattias norlander]

Hi @senthil​,

I had a look at this. I think there are some mix-ups / copy-paste errors in this example project.

As @Markus GIRDLAND​ shared:

• ROM memory region is incorrectly set to:
  • ROM  (rx)  : ORIGIN = 0x9080000 ,  LENGTH = 1024K
  • Origin should be: 0x8000000 
• Be careful. Also the SCB->VTOR points incorrectly to 0x9080000. change line 267 in from/to:
  • SCB->VTOR = VECT_TAB_ADDRESS | VECT_TAB_OFFSET; // Incorrect
  • SCB->VTOR = FLASH_BANK1_BASE | VECT_TAB_OFFSET;  // Correct!
• Next issue. is that PWR configuration does not work properly.
  • Comment out this line 151(?) main.c: //HAL_PWREx_ConfigSupply(PWR_DIRECT_SMPS_SUPPLY);
• Now to the more difficult part and here is where I stopped my attempts... TIM6 and TIM7 is mixed up in this example. In stm32h7xx_hal_timebase_tim.c: HAL_InitTick, you will notice that there is a mix of references to TIM6 and TIM7.
  • I think TIM7 is intended to be used to drive the HAL based on that TIM6 later seem to be used for sginal generation in this example.

@Amel NASRI​, can we have someone from CubeH7 do a proper analysis? Internal ticket references: 107323 + 107327 + 107329.

@senthil​, as I said, no master of how this example should be working, so these are just some preliminary findings that may point you in the right direction. I will forward the issue internally to get some proper fixes.

[mattias norlander]

@senthil​,

Some follow-up: The three first bullets in my reply above has been fixed. More analysis on-going.

Something worth mentioning is that if you generate a new "STM32Cube project" inside CubeIDE or with stand-alone CubeMX, then there is an important bug fix for this board in MX-6.2.1 corresponding to IDE-1.6.1. This is with respect to the power regulator configuration. Using the previous version will "brick" the board (recoverable as described by Amel above).

[senthil]

I am Directly Open the Example Project in CubeIDE

STM32CubeIDE

Version: 1.6.1

Build: 9958_20210326_1446 (UTC)

OS: Windows 10, v.10.0, x86_64 / win32

Java version: 11.0.9.1

[Cartu38 OpenDev]

"I am Directly Open" ... please share snapshot of explain more "directly" .. there are numemous way to do ... my answer is depending of way 🙂