add tutorial for GDB debug process
This commit is contained in:
parent
1a13992391
commit
613939fe23
|
@ -108,6 +108,10 @@ C语言代码由固定的词汇(关键字)按照固定的格式(语法)
|
|||
|
||||
> 在CubeMX初始化的时候,Project mananger标签页下有一个Linker Setting的选项,这里是设置最小堆内存和栈内存的地方。如果你的程序里写了大规模的数组,或使用`malloc()`等分配了大量的空间,可能出现栈溢出或堆挤占栈空间的情况。需要根据MCU的资源大小,设置合适的stack size和heap size。
|
||||
|
||||
RTOS创建任务的时候也会为每个任务分配一定的栈空间,它会替代MCU的硬件裸机进行内存的分配。可以在CubeMX中设置。如果一个任务里定义了大量的变量,可能导致实时系统运行异常,请增大栈空间。
|
||||
|
||||
> 开发板C型使用F407IG芯片,片上RAM的大小为1MB。
|
||||
|
||||
### C language标准和编译器
|
||||
|
||||
不同的C语言标准(一般以年份作代号)支持的语法特性和关键字不同,拥有的功能也不同。一般来说语言标准都是向前兼容的,在更新之后仍然会保存前代的基本功能支持(legacy support)。不过,为了程序能够正常运行,我们还需要一些硬件或平台支持的组件。比如`malloc()`这个函数,在linux平台和windows平台上的具体实现就相去甚远,跟单片机更是差了不止一点。前两者一般和对应的操作系统有关,后者在裸机上则是直接通过硬件或ST公司提供的硬件抽象层代码实现。
|
||||
|
@ -132,6 +136,16 @@ ITM是instrument trace macrocell指令追踪宏单元的缩写,它用于提供
|
|||
|
||||
以上三个模块都需要通过TPIU(trace port interface unit)和外部调试器(j-link等)进行连接,TPIU会将三个模块发来的数据进行封装并通过DWT记录时间,发送给上位机。
|
||||
|
||||
### GDB调试MCU原理
|
||||
|
||||
![image-20221117121323757](assets/image-20221117121323757.png)
|
||||
|
||||
不论使用MDK(KEIL)还是VSCode还是Ozone,实际上背后的流程相同。首先GDB会建立TCP/IP端口并提供接口,调试服务器(Server)作为硬件调试器和GDB软件的桥梁,将硬件调试器的相关功能(也就是DBG外设支持的那些功能)映射到GDB的接口上(通过连接到GDB建立的端口)。之后启动调试,将可执行文件下载到目标MCU上,然后从main开始执行
|
||||
|
||||
> 当然你也可以选择从其他启动点开始执行,调试器开始执行的位置叫做**entry point**。同样,在MCU已经正在运行程序的时候,可以**attach**到程序上开始监控(attach=附加,贴上;很形象了)。
|
||||
|
||||
> 而对于直接运行在电脑上的程序(.exe),就不需要GDBserver和物理调试器,GDB程序可以直接访问电脑上运行的程序和CPU的寄存器等。
|
||||
|
||||
## 环境配置
|
||||
|
||||
- ***所有需要编辑的配置文件都已经在basic_framework的仓库中提供,如果不会写,照猫画虎。***
|
||||
|
|
Binary file not shown.
After Width: | Height: | Size: 152 KiB |
Loading…
Reference in New Issue