【发布时间】:2021-03-22 20:03:32
【问题描述】:
微控制器是一个STM32 F767ZI,它包含一个32位ARM Cortex M7
当给寄存器设置值时,寄存器似乎都偏移了 1。
例如下面的代码:
核心.S
.syntax unified
.cpu cortex-m7
.fpu softvfp
.thumb
// Global memory locations
.global vtable
.global reset_handler
.type vtable, %object
vtable:
.word _estack
.word reset_handler
.size vtable, .-vtable
/*
* The Reset handler
*/
.type reset_handler, %function
reset_handler:
// The '_estack' value is defined in the linker script
LDR sp, =_estack
// Dummy values
LDR r5, =0xDEADBEEF
MOV r3, #50
.size reset_handler, .-reset_handler
linkerScripts/stm32-767zi.ld
_estack = 0x20080000;
MEMORY
{
FLASH ( rx ) : ORIGIN = 0x08000000, LENGTH = 2048K
RAM ( rxw ) : ORIGIN = 0x20000000, LENGTH = 512K
}
运行编译时:
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./linkerScripts/stm32-767zi.ld -o main.elf
结果:
如您所见,r6 设置为 0xdeadbeef 而不是 r5,这是前面代码中编写的内容。此偏移量与设置的其他两个寄存器相同。
我相信链接描述文件的值是正确的,所以我认为问题是由于其他地方的配置不正确造成的。
所以,我有点不确定如何从这里开始,并询问是否有人对可能出现的问题有任何想法或建议。
【问题讨论】:
-
这很好奇!我以前从未见过这样的事情。可能是 JTAG 实现中的错误?
-
您能否提供一些有关 JTAG 探针、GDB 服务器软件、您正在使用的 GDB 版本的信息?
-
这根本与问题无关,但看起来你正在尝试做一个非常小的实现。为此,您可以将负载降低到 sp,因为硬件已经从向量中的第一个条目开始为您执行此操作。
-
请提供一个编译示例,其中包括未运行到以太网中的代码以及您停止程序以检查寄存器的位置
-
@old_timer 我还在程序末尾添加了一个无限循环,并将其停在那里。之前我只是简单的让它运行到最后,然后检查寄存器的值。
标签: assembly arm gdb gnu cortex-m