Сначала проверьте, в порядке ли ваш двоичный файл, затем попробуйте telnet, затем gdb. Rust также увеличивает вероятность неудачи, поэтому начните с чего-нибудь простого:
so.s
.thumb
.globl _start
_start:
.word 0x20001000
.word reset
.thumb_func
reset:
ldr r0,some_addr
ldr r1,[r0]
add r1,r1,#1
str r1,[r0]
b .
.align
some_addr: .word 0x20000000
построить это
arm-none-eabi-as so.s -o so.o
arm-none-eabi-ld -Ttext=0x08000000 so.o -o so.elf
arm-none-eabi-objdump -D so.elf
arm-none-eabi-objdump -D so.elf
so.elf: формат файла elf32-littlearm
Разборка раздела .text:
08000000 ‹_start›: 8000000: 20001000 andcs r1, r0, r0 8000004: 08000009 stmdaeq r0, {r0, r3}
08000008: 8000008: 4802 ldr r0, [pc, # 8]; (8000014 ‹some_addr›) 800000a: 6801 ldr r1, [r0, # 0] 800000c: 3101 добавляет r1, # 1 800000e: 6001 str r1, [r0, # 0] 8000010: e7fe bn 8000010 ‹сбросить + 0x8› 8000012: 46c0 nop; (mov r8, r8)
08000014 ‹some_addr›: 8000014: 20000000 и cs r0, r0, r0
для небольших программ (прочтите документацию st) это может быть основано на адресе 0x08000000 или 0x00000000 для этой части. 0x08000000 является предпочтительным. Таблица векторов должна быть первой, в этом случае игнорируйте разборку, просто посмотрите значения
8000000: 20001000 andcs r1, r0, r0
8000004: 08000009 stmdaeq r0, {r0, r3}
0x08000009 - это адрес сброса, ИЛИ красный с единицей. так 0x08000008 | 1 - это 0x08000009. Так что это, по крайней мере, загрузится и попытается получить код без ошибок.
Этот код просто считывает слово по адресу 0x20000000 и увеличивает его, sram не зависит от сброса, поэтому мы можем продолжать сбрасывать и видеть приращение этого значения.
используя любые конфигурации и интерфейс, которые у вас есть, я объединяю openocd для первой части в один файл и несу его вместе с проектом вместе с конфигурациями для различных интерфейсов (stlinks разных версий и jlink).
openocd -f jlink.cfg -f target.cfg
Open On-Chip Debugger 0.9.0 (2019-04-28-23:34)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : JLink SWD mode enabled
swd
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
cortex_m reset_config sysresetreq
Info : J-Link ARM-OB STM32 compiled Jun 30 2009 11:14:15
Info : J-Link caps 0x88ea5833
Info : J-Link hw version 70000
Info : J-Link hw type J-Link
Info : J-Link max mem block 15344
Info : J-Link configuration
Info : USB-Address: 0x0
Info : Kickstart power on JTAG-pin 19: 0x0
Info : Vref = 3.300 TCK = 1 TDI = 1 TDO = 1 TMS = 1 SRST = 1 TRST = 1
Info : J-Link JTAG Interface ready
Info : clock speed 1000 kHz
Info : SWD IDCODE 0x1ba01477
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Если вы не видите строку точек наблюдения, если она возвращается на консоль, это не сработало.
В другом окне
telnet localhost 4444
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
>
Теперь остановим микросхему и напишем нашу программу. Значения psr, pc и т. Д. Могут отличаться от моих в зависимости от того, что у вас было запущено.
> reset halt
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000010 msp: 0x20001000
> flash write_image erase so.elf
auto erase enabled
device id = 0x20036410
flash size = 64kbytes
wrote 1024 bytes from file so.elf in 0.437883s (2.284 KiB/s)
Давайте прочитаем и увидим, что оно есть, должно совпадать со словами из разборки
> mdw 0x08000000 20
0x08000000: 20001000 08000009 5000f04f 31016801 e7fe6001 ffffffff ffffffff ffffffff
0x08000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
0x08000040: ffffffff ffffffff ffffffff ffffffff
Предположим, что это случайный мусор, и это нормально, пока мы видим, что он увеличивается.
> mdw 0x20000000
0x20000000: 2e006816
> reset
> halt
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000012 msp: 0x20001000
> mdw 0x20000000
0x20000000: 2e006817
Таким образом, значение увеличивается, если вы выполняете сброс, затем выполняете остановку (не остановку сброса в одной команде), а затем сбрасываете эту ячейку памяти, которая должна увеличиваться каждый раз.
Теперь вы можете выбрать путь gdb (я не использую gdb, поэтому его не устанавливаю) с этим двоичным файлом или проверить двоичный файл ржавчины, сначала проверив таблицу векторов, чтобы убедиться, что он правильный, по крайней мере, без если вектор сброса верен, вы ошибетесь и не запустите какой-либо код на процессоре. Можете прошить через telnet или можете попробовать gdb.
Если у gdb возникла проблема с файлом, возможно, вы используете не тот файл. или файл построен неправильно. вы пробовали простую программу в этом репозитории? Можете ли вы создать минимальную программу из этого репозитория, функцию пустой записи, бесконечный цикл или счетчик, который считается вечно?
Это действительно проблема GDB? Это проблема openocd? Это проблема инструментов Rust? Это проблема двоичного кода Rust? Это ошибка в документации, и вы указываете gdb не на ту проблему с файлом? Если вышеперечисленное работает, то openocd работает, binutils, по крайней мере, работает, отладчик / оборудование работает, он устраняет их, а затем становится, это вещь ржавчины, вещь gdb, использование неправильного файла или что-то еще?
person
old_timer
schedule
16.02.2020
