使用 OpenOCD 和 arm-none-eabi-gdb 將二進制文件加載到 stm32f103c8t6

Question

我試圖加載從 Rust 代碼編譯的二進制文件，但它不起作用。

首先，我從https://github.com/rust-embedded/discovery下載了 Rust 代碼。 然后，我建造了它。

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

它已成功編譯。

之后，我使用 OpenOCD 成功連接到 stm32f103c8t6。 然后，我運行這個命令。

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

但是好像沒讀完。

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.

我不知道為什么它不起作用。

請幫我。

Answer 1

首先看看你的二進制文件是否好，然后嘗試 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]: 8007000100000010010010000010 46c0 nop ; (移動 r8, r8)

08000014 <some_addr>: 8000014: 20000000 andcs r0, r0, r0

對於小程序（閱讀 st 文檔），這部分可以基於地址 0x08000000 或 0x00000000。 0x08000000 是首選。 向量表必須首先在這種情況下忽略反匯編只看值

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

0x08000009 是復位地址 ORRed 為 1。 所以 0x08000008 | 1 是 0x08000009。 這樣至少可以啟動並嘗試獲取代碼而不會出錯。

這段代碼只是讀取地址 0x20000000 處的字並遞增它，sram 不受復位影響，因此我們可以繼續復位並看到該值遞增。

使用您擁有的任何配置和接口，我將 st 部分的 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，所以沒有安裝）或者通過首先檢查向量表來檢查你的 rust 二進制文件以查看它是否正確，至少沒有重置向量是正確的，那么你會出錯並且不會在處理器上運行任何代碼。 可以使用 telnet 刷新它，或者您可以嘗試 gdb。

如果 gdb 對文件有問題，那么您可能使用了錯誤的文件。 或者文件構建不正確。 您是否在該存儲庫中嘗試過一個簡單的程序？ 你能從那個存儲庫中制作一個最小的程序，一個空的入口函數或一個無限循環或一個永遠計數的計數器嗎？

這真的是gdb問題嗎？ 這是一個openocd問題嗎？ 這是 Rust 工具的問題嗎？ 這是 Rust 二進制問題嗎？ 這是文檔中的錯誤並且您將 gdb 指向錯誤的文件問題嗎？ 如果以上工作，那么 openocd 工作，binutils 至少工作，調試器/硬件工作，它消除了那些，然后變成這是一個生銹的東西，一個 gdb 的東西，使用錯誤的文件的東西，還是別的什么？

Answer 2

將openocd與開發板連接openocd ，不要忘記將調試器arm-none-eabi-gdb與openocd 。

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

如果在運行openocd的終端控制台中openocd正常，您將看到以下消息：

accepting 'gdb' connection on tcp/3333`

你應該可以開始調試了。

要優化連接設置，您可以使用以下內容創建/更新.gdbinit文件：

target remote localhost:3333