May 2, 2025
STM32H743 Nucleo board -- "blink" bare metal demo
This is "blink1" in my Github repo, in anticipation of blink2,
blink3, and beyond.
This began by copying the blink1 demo from my F411 repo and making
it an exercise to find out how much needed to be changed for the H743.
After half a day of writing code and working on it, I was ready to give
it a try. Of course it did not work. How do we debug this?
With absolutely no IO and a board that simply doesn't do anything,
our options are limited. One approach is to just think (always a
worthwhile thing to do in such situations) as well as to check the
code for gross blunders and stupid mistakes. It often helps to go
do something else, then come back later for a second look.
Another good option is to use OpenOCD and see if the code has ran off
into some crazy address or if some such thing is going on.
In these cases, I have my own OpenOCD guide to fall back on:
I start openocd running and use "telnet localhost 4444" to connect to it.
halt
[stm32h7x.cpu0] halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x08000058 msp: 0x2001fff0
I can look at "blink.dump" to find out that this PC is in the delay()
routine, which is good -- exactly what one would expect given that this
demo spends almost all of its time looping in delay().
The stack pointer also looks entirely proper.
I type "resume" and "halt" over and over to see if anything unexpected
happens, but it never does. The disassembled code looks like:
08000050 :
8000050: b082 sub sp, #8
8000052: 4b04 ldr r3, [pc, #16] @ (8000064 )
8000054: 9301 str r3, [sp, #4]
8000056: 9b01 ldr r3, [sp, #4]
8000058: 1e5a subs r2, r3, #1
800005a: 9201 str r2, [sp, #4]
800005c: 2b00 cmp r3, #0
800005e: d1fa bne.n 8000056
8000060: b002 add sp, #8
8000062: 4770 bx lr
8000064: 000c3500 .word 0x000c3500
There is some thumb code to admire. The above is from the file
"blink.dump", which is generated by my build process, but you can
also get a disassembly from OpenOCD as follows:
> arm disassemble 0x08000050 32
0x08000050 b082 sub sp, #8
0x08000052 4b04 ldr r3, [pc, #0x10]
0x08000054 9301 str r3, [sp, #4]
0x08000056 9b01 ldr r3, [sp, #4]
0x08000058 1e5a subs r2, r3, #1
0x0800005a 9201 str r2, [sp, #4]
0x0800005c 2b00 cmp r3, #0
0x0800005e d1fa bne #0x8000056
0x08000060 b002 add sp, #8
0x08000062 4770 bx lr
0x08000064 3500 adds r5, #0
0x08000066 000c movs r4, r1
You just don't get a handy "fixup" of the PC relative accessed
constant at 0x08000064. But you do get to verify that what you
expect is in flash and running!!
You can check the register contents via:
reg
===== arm v7m registers
(0) r0 (/32): 0x00000010
(1) r1 (/32): 0x00010000
(2) r2 (/32): 0x0007c3e3
(3) r3 (/32): 0x0007c3e4
(4) r4 (/32): 0x00000000
(5) r5 (/32): 0x00000000
(6) r6 (/32): 0x00000000
(7) r7 (/32): 0x00000000
(8) r8 (/32): 0x00000000
(9) r9 (/32): 0x00000000
(10) r10 (/32): 0x00000000
(11) r11 (/32): 0x00000000
(12) r12 (/32): 0x00000000
(13) sp (/32): 0x2001fff0
(14) lr (/32): 0x080000f9
(15) pc (/32): 0x0800005c
(16) xPSR (/32): 0x21000000
Here register "r3" holds the delay value which is counting down to zero,
and that is pretty much the only interesting thing.
Actually the "lr" register is interesting. Note that it holds an odd value,
indicating that we should return to thumb mode. The actual return is
to 0x080000f8, just as it should be.
So, there is no major screw up going on -- I just have some bug in my program.
Power control and domains
It turns out this is not the problem, see the next page.
My big theory is that I need to do something to switch on power domains.
This is a new aspect of the H743. We have D1, D2, and D3 and by powering
down sections of the chip, it is possible to save power.
Almost certainly the chip comes out of reset with these switched off.
Another look at the TRM reveals a whole section (section 6) devoted to
power control. The section is almost 50 pages long and describes
registers, so I had better go take a look!
Feedback? Questions?
Drop me a line!
Tom's Computer Info / tom@mmto.org