1.概述做嵌入式開發(fā)時(shí),很多時(shí)候都會(huì)使用到GDB,從底層去理解GDB的調(diào)試過程,將更加容易的理解調(diào)試的過程。
在做嵌入式開發(fā)調(diào)試時(shí),可理解為兩個(gè)部分
嵌入式系統(tǒng)平臺(tái),啟動(dòng)一個(gè)debug stub
宿主機(jī),啟動(dòng)gdb
兩個(gè)平臺(tái)之間通過串行數(shù)據(jù)總線連接起來。
2.GDB Server的作用當(dāng)PC機(jī)啟動(dòng)GDB時(shí),需要和GDB Server建立一定的通信連接,由GDB Server解析具體的邏輯并執(zhí)行。
所以GDB Server可以是一個(gè)openocd,或者JTAG等等實(shí)際的外設(shè)模塊,和目標(biāo)板子進(jìn)行連接后,可以調(diào)試芯片。它本質(zhì)上是一個(gè)解析GDB協(xié)議的模塊,或者是一段后臺(tái)的程序。
相應(yīng)GDB的請(qǐng)求
當(dāng)gdb和嵌入式平臺(tái)進(jìn)行通信的時(shí)候,會(huì)發(fā)一系列的請(qǐng)求,例如:
讀寫內(nèi)存
讀寫寄存器
設(shè)置或者清除斷點(diǎn)
提供調(diào)試Trap
GDB斷點(diǎn)的Trap
無效指令的Trap
系統(tǒng)錯(cuò)誤的Trap
同步傳輸CPU的狀態(tài)和到遠(yuǎn)程的GDB中。
3.一個(gè)標(biāo)準(zhǔn)的gdb的調(diào)試過程一般的正常使用編譯工具鏈中都會(huì)有g(shù)db的工具,就拿riscv的來說,用riscv-nuclei-elf-gdb.exe去連接qemu上的gdb stub時(shí),采用的是tcp協(xié)議。
當(dāng)qemu去啟動(dòng)gdb server的時(shí)候。
qemu-system-riscv32.exe -M gd32vf103v_rvstar -cpu -nographic -s -S
后面的-s表示啟動(dòng)gdb server。而-S則表示綁定在TCP端口的1234端口號(hào)上。
從操作上是這個(gè)流程,那么底層的數(shù)據(jù)傳送又是怎樣的流程呢?
4.GDB 遠(yuǎn)程串行協(xié)議解析一個(gè)標(biāo)準(zhǔn)的GDB串行協(xié)議的格式如下
$packet-data#checksum
其中的消息是通過ASCII碼進(jìn)行傳輸,以$開始,以#結(jié)束。最后的checksum是命令的校驗(yàn)和。
上面就是通過Wireshark監(jiān)聽到的協(xié)議數(shù)據(jù)。
GDB與GDB server進(jìn)行通信的時(shí)候,采用收發(fā)形式進(jìn)行,必然會(huì)有下面的通信過程
發(fā)送:
$packet-data#checksum
回復(fù)
+
每次都需要回復(fù)一個(gè)+,表示收到數(shù)據(jù)。
當(dāng)沒有接受到數(shù)據(jù),或者超時(shí)時(shí),需要進(jìn)行重傳操作。
下面就是一個(gè)實(shí)際的通信過程。
gdb 和 target之間的通信一直會(huì)采用收發(fā)對(duì)稱的數(shù)據(jù)格式
比如寫內(nèi)存
gdb會(huì)調(diào)用set 0x4015cc = 0xc320。
那么gdb底層的通信是
$M4015CC,2:C320#6d
目標(biāo)機(jī)收到數(shù)據(jù)后,會(huì)首先返回
+
接著返回狀態(tài)
$OK#9a
這樣,一個(gè)通過gdb操作內(nèi)存的中的數(shù)據(jù)的通信協(xié)議就完成了。
由于GDB的指令非常多,這里就不列舉了,但是基本的原理和格式都差別不大。
比如單步調(diào)試的指令
step:
[gdb] $s#73
向下執(zhí)行的指令
Continue
[gdb] $c#63
控制臺(tái)輸出
Console Output
[target] $o48656c6c6f2c20776f726c64210a#55
這樣可以在gdb控制臺(tái)上輸出hello,world!的命令。
關(guān)于命令的格式可以查看官方文檔
https://sourceware.org/gdb/onlinedocs/gdb/Stop-Reply-Packets.html
但是舉出一些基本的規(guī)律
5.小結(jié)用采用GDB進(jìn)行調(diào)試的過程,底層的傳輸原理,采用的是非常簡單的字符串的格式,這GDB將這些命令發(fā)給硬件調(diào)試器或者板子,通過將這些命令解析后,執(zhí)行具體的邏輯,就可以正常的控制芯片中程序的行為了。這就是GDB的串行協(xié)議原理。
編輯:jq
-
嵌入式
+關(guān)注
關(guān)注
5143文章
19561瀏覽量
315444 -
寄存器
+關(guān)注
關(guān)注
31文章
5425瀏覽量
123542 -
gdb
+關(guān)注
關(guān)注
0文章
60瀏覽量
13551 -
DEBUG
+關(guān)注
關(guān)注
3文章
94瀏覽量
20403
原文標(biāo)題:GDB串行協(xié)議概述
文章出處:【微信號(hào):gh_390c588e521e,微信公眾號(hào):嵌入式小作坊】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
CM7能成功調(diào)試但CM4始終報(bào)\"Failed to read ROM table via AP 3\"錯(cuò)誤,怎么解決?
使用STM32CubeIDE對(duì)STM32H7進(jìn)行開發(fā)和調(diào)試,CM4始終報(bào)\"Failed to read ROM table via AP 3\"錯(cuò)誤怎么解決?
STM32H7雙核調(diào)試,CM7能成功調(diào)試但CM4始終報(bào)\"Failed to read ROM table via AP 3\"錯(cuò)誤是怎么回事?
i.MX93使用J-Link和SYSRESETREQ的Cortex-M33復(fù)位不起作用怎么解決?
STM32CubeIDE無法啟動(dòng)正常調(diào)試是哪里出了問題?
CubeIDE下載程序時(shí)報(bào)錯(cuò)Target no device found,但是ST-LinkUpgrade可以識(shí)別到且可以更新固件,為什么?
為什么會(huì)報(bào)錯(cuò)Could not determine GDB version using command: arm-none-eabi-gdb --version?
rs232-hs讀取idcode的時(shí)候出現(xiàn)0xffffffff的情況,怎么處理?
AN-724: ADuC70xx串行下載協(xié)議

評(píng)論