STM32L031K6: Why can't I access registers r0 through r3 with a simplest-possible assembly program using gcc/gdb?

[IanJ]

I'm brand new to STM32 development, but have many years of programming experience in higher level languages. I'm trying to get a very basic assembly program to run on an STM32L031K6 Nucleo board, as a kind of hello world example. I've attached a small tarfile with the files I'm using to produce the problem I describe here.

My process is to run "build.sh", then plug in my Nucleo board and start "st-util". Then I fire up "arm-non-eabi-gdb minimal.elf", setting gdb to use the port 4242 remote port via "target extended-remote :4242", load, continue, and ctrl-c to break into the program. Then, inspecting registers in gdb, I see this:

(gdb) i r
r0 0x30 48
r1 0x30 48
r2 0x16575448 374821960
r3 0x7fff 32767
r4 0x33333333 858993459
r5 0x44444444 1145324612
r6 0x55555555 1431655765
r7 0x66666666 1717986918
r8 0x77777777 2004318071
r9 0xffffffff 4294967295
r10 0xffffffff 4294967295
r11 0xffffffff 4294967295
r12 0xffffffff 4294967295
sp 0xffffffff 0xffffffff
lr 0x20002000 536879104
pc 0xffffffff 0xffffffff
cpsr 0xf1000000 4043309056

What I should be seeing is each of r0 through r7 set to their respective 0x11111111 style numbers. Yet r0 through r3 are completely wrong, and r4 through r8 are offset by one. I don't understand what I'm doing that may be causing this problem.

I've also tested this code with an STM32F042K6 Nucleo board, modifying things to use "cortex-m0" as the cpu, and setting the RAM size and start location to 6k, and it produces a very similar result. This leads me to believe that either something is wrong with my toolchain (currently using the gcc-arm-none-eabi-10-2020-q4-major package, downloaded from developer.arm.com, and running on an Ubuntu derivative), or my understanding of the assembly I'm writing is flawed.

If anyone can help me sort out what I'm doing wrong, I would appreciate the help. I figure there's no point continuing past this point until I can figure out why this very basic example isn't working correctly.

[waclawek.jan]

The program looks OK, I've assembled and run it with the expected result (albeit on an 'F4).

(gdb) moni reset halt
adapter speed: 2000 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000008 msp: 0x20002000
(gdb) c
Continuing.
 
Program received signal SIGINT, Interrupt.
0x0800001c in reset_handler ()
(gdb) i r
r0 0x0 0
r1 0x11111111 286331153
r2 0x22222222 572662306
r3 0x33333333 858993459
r4 0x44444444 1145324612
r5 0x55555555 1431655765
r6 0x66666666 1717986918
r7 0x77777777 2004318071
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
sp 0x20002000 0x20002000
lr 0xffffffff -1
pc 0x800001c 0x800001c <reset_handler+20>
xPSR 0x1000000 16777216
(gdb)

I'd suspect your toolchain, namely the gdb server (with whatever intermediary you use), to be intrusive. These should raise a flag:

sp 0xffffffff 0xffffffff

lr 0x20002000 536879104

pc 0xffffffff 0xffffffff

JW

[IanJ]

Thanks for the speedy response, Jan. It appears that st-util (the GDB server) is the likely culprit. I'm looking into OpenOCD now, as a possible replacement. Thanks for your confirmation that I should be on the right track.

[IanJ]

OpenOCD works perfectly. For anyone else running into this problem, I run OpenOCD with the following command line (should be similar for other Unix-like OSes):

openocd -f interface/stlink.cfg -f target/stm32l0.cfg

Then connect in arm-eabi-none-gdb with "target extended-remote :3333" and all proceeds properly.