STM32H7 is stucked in system bootloader when trying to jump to the application

[APaus.1]

We are experiencing issues when using system bootloader on STM32H7 MCUs. Enter to the bootloader is correct - when BOOT0 pin is held high and reset is performed, MCU enters system bootloader. We use USB DFU for communication with bootloader and PC can recognize DFU device correctly, we can connect, perform FW update. However when trying to jump to the application the issue appears:

with STM32H743 rev Y (bootloader version 0xD2) jump to application works with addresses 0x8008ACC or 0x8000123

with STM32H753 rev V (bootloader version 0x90) jump to application doesn't work with any address

From the program counter read-out it seems that MCU is stucked in system bootloader at address 0x1FF0AAF0, however DFU device disappears from Device manager.

The idea is to be able to run the application without need to perform manual reset of MCU.

What could be the issue? Thank you in advance

[MM..1]

JRead AN2606 H74xxx limitations page 273 now

[APaus.1]

Actually I read it several times already. If you mean the part with jump issue, I already tried to move stack pointer to different address (Ram end @ - 16 and lower) - in ld script, but nothing has changed.

[MM..1]

Your info is oposite to pdf. 0XD2 in AN GO not work at all.

0x90 ...

[APaus.1]

Yes, actually it is interesting as with 0xD2 version of bootloader jump to application works with go command (or --start command). version 0x90 which should be newer doesn't work. Jump command is acknowledged in command line but nothing happens - only DFU device disconnects.

I add log files from command line when verbose mode is set. Maybe it says something to you.

[MM..1]

Normal is GO to addr 8000000 if code is linked here. Bootloader then reads from this addr to real start.

Limitations cant be corrected only with replacing system boot with your own bootloader .

[Amel NASRI]

Hi @APaus.1​ ,

Does the article Using STM32H7 MCUs, how to jump into system bootloader from application code? help you?

-Amel

[APaus.1]

Hello Amel,

not really, as the issue is not in jumping into system bootloader from application, but in jumping from system bootloader to application using Cube Programmer CLI. I opened the case with ST and now it's waiting to be reviewed team responsible for system bootloader. When I get the result I will share it here.

By the way I found out that after attempt to jump to the application USB2 peripheral registers are filled with 0x02 values.

[Rav K]

Hello APaus.1,

Were you able find a solution to this issue? I have tried changing my linker script to move the stack pointer to a different address (Ram end @ - 16 and lower) and but still not able to get the application to run via the Go command.