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

IanJ · ‎2021-04-06

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 · ‎2021-04-06

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 · ‎2021-04-09

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 · ‎2021-04-10

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.