cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H725IGK6 Boot Issues

KRega.1
Associate II

I'm using STM32H725IGK6. I come from Microchip PIC world.

When pulling up 'BOOT0' with 10kΩ to VCC(3.3V) , I'm able to run my code on my custom designed board using STM32CUBEIDE.

When I press RST or power cycle board, nothing runs. This is expected right? Since I'm in Bootloader mode.

State 1) Here is the issue. When pull 'BOOT0' to ground through 10kΩ, I can program the device only once and if I try to reprogram thereafter, I get the 'no target found error'. No code runs on the device. I do see the current of the device increase to a level similar when code is running when in Boot0=vcc mode.

State 2) I then set Boot0 back to VCC and I'm able to debug and run code again. If I open STM32CubeProgrammer, I'm able to erase the chip completely.

I then put the device back to State 1) again have the same issue. I'm able to connect and program once only with no code running. I'm unable to get anything to work when Boot0 is at GND.

Notes: pin 'VBAT' is always powered (connected to a battery at 3.3V)

In STM32CUBEMX, 'Debug' is set to 'Serial Wire'

I have also tried to hold reset switch down in both Boot modes to connect to the device. I have used the STM32CubeProgrammer to program the device making sure that the option bytes are set with no write protect.

What am I missing?

See attachment for schematic.

Thanks,

Kevin

3 REPLIES 3

With BOOT0 Low it is running your code, for good or bad.

You could perhaps turn off "Run to main()" and step the code in from the Reset_Handler

The most likely causes of failure are

a) Incorrect LDO/SMPS power settings

b) Incorrect VOS setting

c) Incorrect PLL/HSE_VALUE based on how you're clocking. If you do nothing it should run at 64 MHz off HSI

d) Some broken startup code that Hard Faults

You could end up in infinite while loops in Error_Handler() and HardFault_Handler()

Low power modes may hinder the debugger wrestling control

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
KRega.1
Associate II

Thank you for your quick reply. Turns out it was the SupplySource setting in MX and Power regulator Voltage Scale.(both set wrong)

I Can't tell you how many hours I spent trying to figure this out.

Why is it that this code will work when I load it from CUBEIDE in BOOT=1 mode and not run when BOOT=0 ?

Also what/where is a good document that describes these settings? I couldn't find it in the datasheet.

Thanks!

TDK
Guru

> Why is it that this code will work when I load it from CUBEIDE in BOOT=1 mode and not run when BOOT=0 ?

This is an educated guess. Might not be 100% accurate.

BOOT0=1 runs the system bootloader after a normal reset. During debugging, the device resets at least twice and runs code between these resets. During the first reset, if it runs your code (BOOT0=0), and your power supply settings are wrong, the SWD connection is lost and debugging fails. If it runs the bootloader instead (BOOT0=1), there is no issue and the connection is not lost. At the last reset, the debugger manually forces the code to execute where it think it should via the SWD protocol, hence the debugging session works, at least up until the power is configured.

> Also what/where is a good document that describes these settings? I couldn't find it in the datasheet.

The reference manual is the best source of technical information. The datasheet contains only device-specific info.

https://www.st.com/resource/en/reference_manual/dm00603761-stm32h723733-stm32h725735-and-stm32h730-value-line-advanced-armbased-32bit-mcus-stmicroelectronics.pdf

If you feel a post has answered your question, please click "Accept as Solution".