Загрузите бинарный файл в stm32f103c8t6 с помощью OpenOCD и arm-none-eabi-gdb - PullRequest
0 голосов
/ 16 февраля 2020

Я пытался загрузить двоичный файл, скомпилированный из кода ржавчины, но он не работает.

Сначала я загрузил код Rust с https://github.com/rust-embedded/discovery. Затем я собрал его.

# I am in the `src/05-led-roulette` directory
rustup target add thumbv7m-none-eabi
cargo build --target thumbv7m-none-eabi

Он был успешно скомпилирован.

После этого я успешно соединился с stm32f103c8t6, ​​используя OpenOCD. Затем я запускаю эту команду.

arm-none-eabi-gdb -q target/thumbv7m-none-eabi/debug/led-roulette

Но казалось, что она не закончила чтение sh.

Reading symbols from target/thumbv7m-none-eabi/debug/led-roulette...
(gdb)

(не выполнено?!)

После этого я попробовал команду load, но она вернула следующие предложения.

Start address 0x0, load size 0
Transfer rate: 0 bits in <1 sec.

Понятия не имею, почему она не работает.

Пожалуйста, помогите мне.

Ответы [ 2 ]

1 голос
/ 16 февраля 2020

Сначала посмотрите, хорош ли ваш бинарный файл, затем попробуйте te lnet, затем gdb. ржавчина также увеличивает вероятность неудачи, поэтому начните с чего-то простого:

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

build it

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, [p c, # 8]; (8000014) 800000a: 6801 ldr r1, [r0, # 0] 800000 c: 3101 добавляет r1, # 1 800000e: 6001 str r1, [r0, # 0] 8000010: e7fe bn 8000010 8000012: 46c0 nop; (mov r8, r8)

08000014: 8000014: 20000000 andcs r0, r0, r0

для небольших программ (см. документацию st). Для этой части это может быть основано по адресу 0x08000000 или 0x00000000 , 0x08000000 является предпочтительным. Таблица векторов должна быть первой в этом случае, игнорировать разборку, просто посмотрите на значения

 8000000:   20001000    andcs   r1, r0, r0
 8000004:   08000009    stmdaeq r0, {r0, r3}

. 0x08000009 - это адрес сброса ORRed с единицей. так 0x08000008 | 1 - это 0x08000009. Так что это как минимум загрузится и попытается получить код без ошибки.

Этот код просто читает слово по адресу 0x20000000 и увеличивает его, сбрас не влияет на сброс, поэтому мы можем продолжать сбрасывать и видеть это значение инкремент.

используя любые имеющиеся у вас конфиги и интерфейс, я объединяю один openocd для первой части в один файл и переносу его вместе с проектом для различных интерфейсов (stlink разных версий и 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, p c, et c могут отличаться от моих в зависимости от того, что у вас было.

> 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, поэтому у меня нет установленного пути). ) с этим двоичным файлом или проверьте свой двоичный файл ржавчины, сначала проверив таблицу векторов, чтобы убедиться, что она верна, хотя бы по крайней мере вектор сброса является правильным, тогда вы выйдете из строя и не запустите какой-либо код на процессоре. Можно указать sh, используя te lnet, или вы можете попробовать gdb.

, если у gdb возникла проблема с файлом, возможно, вы используете не тот файл. или файл неправильно построен. Вы пробовали простую программу в этом хранилище? Можете ли вы сделать минимальную программу из этого хранилища, пустую функцию ввода или бесконечное число l oop или счетчик, который считает навсегда?

Действительно ли это проблема GDB? это проблема с openocd? это проблема инструментов ржавчины? это бинарная проблема ржавчины? это ошибка в документации, и вы указываете GDB на проблему с неправильным файлом? если вышеперечисленное работает, то работает openocd, хотя бы binutils работает, отладчик / аппаратное обеспечение работает, он устраняет их, и затем становится ли это ржавчиной, gdb, использованием неправильного файла или чем-то еще? Укажите дополнительную информацию в вопросе, чтобы помочь решить эту проблему.

0 голосов
/ 17 февраля 2020

После подключения openocd к плате не забудьте подключить отладчик arm-none-eabi-gdb к openocd.

> arm-none-eabi-gdb -se target/thumbv7em-none-eabi/release/your_binary
(gdb) target remote localhost:3333

Если в терминальной консоли, где работает openocd, все в порядке вы увидите сообщение:

accepting 'gdb' connection on tcp/3333`

и сможете начать отладку.

Чтобы оптимизировать настройку соединения, вы можете создать / обновить файл .gdbinit с содержанием:

target remote localhost:3333
...