Before explaining the problem I want to say as a disclaimer that I am a total beginner with baremetal coding in ARM, so the problem could be anywhere.
I am following this guide to move my first steps. The big difference with the guide is that I have a STM32H753ZI board. I modified the code of the example in the following way in order to adapt it to the different hardware:
STM32H753ZI.ld:
/* Define the end of RAM and limit of stack memory */ _estack = 0x3001FFFC; MEMORY { FLASH ( rx ) : ORIGIN = 0x08000000, LENGTH = 1024K RAM ( rxw ) : ORIGIN = 0x30000000, LENGTH = 126K } core.S:
// These instructions define attirbutes of our chip and // the assembly language we'll use .syntax unified .cpu cortex-m7 .fpu softvfp .thumb // Global memory locations .global vtable .global reset_handler /* * The actual vector table. * Only the size of RAM and 'reset' handler are * included for simplicity */ .type vtable, %object vtable: .word _estack .word reset_handler .size vtable, .-vtable /* * The Reset handler. Called on reset. */ .type reset_handler, %function reset_handler: // Set the stack pointer to the end of the stack. // The '_estack' value is defined in our linker script. LDR r0, =_estack MOV sp, r0 // Set some dummy values. When we see these values // in our debugger, we'll know that our program // is loaded on the chip and working. LDR r7, =0xDEADBEEF MOVS r0, #0 MOVS r1, #6 main_loop: // Add 1 to register 'r0'. ADDS r0, r0, #1 // Loop back. B main_loop .size reset_handler, .-reset_handler Then, I compile and link it with the following two commands:
arm-none-eabi-gcc -x assembler-with-cpp -c -O0 -mcpu=cortex-m7 -mthumb -Wall core.S -o core.o arm-none-eabi-gcc core.o -mcpu=cortex-m7 -mthumb -Wall --specs=nosys.specs -nostdlib -lgcc -T./STM32H753ZI.ld -o main.elf No compilation and linking error appears up to this point. If I try to deassemble the code with arm-none-eabi-objdump -zd core.o, this is what I get:
core.o: file format elf32-littlearm Disassembly of section .text: 00000000 <vtable>: 0: 00 00 00 00 00 00 00 00 ........ 00000008 <reset_handler>: 8: 4803 ldr r0, [pc, #12] @ (18 <main_loop+0x6>) a: 4685 mov sp, r0 c: 4f03 ldr r7, [pc, #12] @ (1c <main_loop+0xa>) e: 2000 movs r0, #0 10: 2106 movs r1, #6 00000012 <main_loop>: 12: 3001 adds r0, #1 14: e7fd b.n 12 <main_loop> 16: 0000 .short 0x0000 18: 00000000 .word 0x00000000 1c: deadbeef .word 0xdeadbeef So far everything seems okay. However, when I load the code on the STM32 with arm-none-eabi-gdb --eval-command="target extended-remote :4242" main.elf and investigate the register with info-register this is what I see:
(gdb) info register r0 0x8 8 r1 0x800040c 134218764 r2 0x0 0 r3 0x4000 16384 r4 0x0 0 r5 0x4 4 r6 0x65 101 r7 0x0 0 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x1 1 sp 0x24009058 0x24009058 lr 0xffffffe9 4294967273 pc 0x802a1fe 0x802a1fe cpsr 0x1000003 16777219 The r0 register seems to be working as intended and, if I let the code run for some time, I can see its value changing. However, neither the r1 register nor the r7 register are reporting the values that were assigned in the core.S file. Additionally, also the value reported in the register sp (stack pointer) is showing problems: according to the code that I have written, it should report the value saved in _estack (which is 0x3001FFFF). Obviously this is not happening.
Do you have any idea why the values reported are not the expected ones?
Edit 1:
@the busybee sorry for the late response.
If I deassemble main.elf I obtain the following values:
main.elf: file format elf32-littlearm Disassembly of section .text: 08000000 <vtable>: 8000000: fc ff 01 30 09 00 00 08 ...0.... 08000008 <reset_handler>: 8000008: 4803 ldr r0, [pc, #12] @ (8000018 <main_loop+0x6>) 800000a: 4685 mov sp, r0 800000c: 4f03 ldr r7, [pc, #12] @ (800001c <main_loop+0xa>) 800000e: 2000 movs r0, #0 8000010: 2106 movs r1, #6 08000012 <main_loop>: 8000012: 3001 adds r0, #1 8000014: e7fd b.n 8000012 <main_loop> 8000016: 0000 .short 0x0000 8000018: 3001fffc .word 0x3001fffc 800001c: deadbeef .word 0xdeadbeef For what concerns the real values that I see, they are reported at the end of the question. I am loading the code via gdb and printing the resgister with info register. I obtain the following:
(gdb) info register r0 0x8 8 r1 0x800040c 134218764 r2 0x0 0 r3 0x4000 16384 r4 0x0 0 r5 0x4 4 r6 0x65 101 r7 0x0 0 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x1 1 sp 0x24009058 0x24009058 lr 0xffffffe9 4294967273 pc 0x802a1fe 0x802a1fe cpsr 0x1000003 16777219 Should I try to print something else?
