代码调试跟踪与优化（二）--- 如何调试嵌入式代码？

最新推荐文章于 2024-06-13 18:59:26 发布

流云IoT

最新推荐文章于 2024-06-13 18:59:26 发布

阅读量5.3k

点赞数 9

分类专栏：流云的博客开发工具嵌入式调试跟踪文章标签： Debug and Trace ARM CoreSight JTAG/SWD/SWO Cortex-Debug SystemView

本文链接：https://blog.csdn.net/m0_37621078/article/details/114918430

版权

本文深入探讨嵌入式系统调试，介绍ARM CoreSight调试和跟踪原理，包括Debug和Trace模型，以及硬件调试工具如J-LINK、VS Code Cortex-Debug、Ozone和SystemView的使用。通过实例解析，揭示如何调试嵌入式芯片的底层代码，助力提升开发效率。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

文章目录

前言：
一、嵌入式系统调试原理
- 1.1 嵌入式系统调试模型
- 1.2 ARM CoreSight (Debug and Trace) 简介
二、嵌入式系统调试工具
更多文章：

前言：

前文介绍了GDB 调试原理，我们在进行嵌入式开发调试时，受限于嵌入式芯片资源和性能，一般采用远程调试。

GDB 远程调试需要在目标机上运行gdbserver 程序，对于裸机或RTOS 来说，gdbserver 占用的资源太多。而且在gdbserver 进程启动之前，我们无法对其进行调试，也就是说系统或驱动等底层代码的调试，单靠gdbserver 就无能为力了。我们如何调试嵌入式系统的底层代码呢？

有过嵌入式底层开发经验的朋友，都用过J-LINK、ST-LINK、CMSIS-DAP 等硬件调试器，借助这些硬件调试器可以访问嵌入式芯片的指令数据、内存数据、系统及外设寄存器等，而不要求目标芯片上提前执行什么代码。硬件调试器既然不依赖目标芯片的软件环境，自然是目标芯片在硬件上能处理这些调试跟踪信号，以ARM Cortex 架构芯片为例，目标芯片是如何处理这些调试跟踪信号的呢？

一、嵌入式系统调试原理

1.1 嵌入式系统调试模型

我们在GDB 远程调试模型的基础上，增加一个硬件调试器层级，得到嵌入式系统底层代码的调试模型如下：
嵌入式远程调试模型

嵌入式开发的目标芯片主流是ARM Cortex，本文以ARM Cortex 架构芯片为例简单介绍其调试模型：

GDB 调试工具：ARM Cortex 架构使用ARM GNU 工具链，又可细分为两类，Cortex -M/R 架构常用arm-none-eabi-gdb 调试工具，Cortex-A 架构常用arm-none-linux-eabihf-gdb 调试工具，可从ARM 开发者网站下载；
GDB Server 调试工具：这里的GDB Server 不是运行在目标机内的，也是运行在调试机内的程序（可以和GDB 调试工具运行在不同的调试机内，两个调试机通过网线相连），作为GDB 程序与硬件调试器之间沟通的桥梁，解释来自GDB 程序的调试命令和硬件调试器返回的调试数据。该程序通常与硬件调试器驱动程序一起发布，比如J-LINK 驱动程序包含的J-LINK GDB Server（仅支持J-LINK 调试器）；也有一些开源的，比如OpenOCD(Open On-Chip Debugger) (可以支持多种硬件调试器，比如对ST-LINK 的支持更友好) 包含的OpenOCD GDB Server；
硬件调试器：是一个内部烧录好程序的独立硬件设备，作为GDB Server 与目标芯片之间沟通的桥梁，翻译来自GDB Server 的调试命令和目标芯片返回的调试跟踪信号。硬件调试器需要配合相应的驱动程序使用，且不同调试器支持的目标芯片型号不同，常见的硬件调试器有J-LINK、ST-LINK、CMSIS-DAP 等；
目标芯片：目标芯片为了方便开发人员调试代码，一般内部都集成了调试跟踪模块，比如ARM Cortex 架构集成了ARM CoreSight 调试跟踪组件，对内可以控制并访问几乎所有系统及外设存储空间，对外提供统一的Debug Port（支持SWD 和JTAG），开发者可借助硬件调试器对目标芯片进行调试跟踪。

GDB 和GDB Server 的调试原理在前篇博文已经介绍过了，这里简单介绍后两部分。我们进行软件开发调试的基础是目标芯片，硬件调试器应该选择支持目标芯片的型号，因此从目标芯片的调试跟踪模块及其接口介绍。

1.2 ARM CoreSight (Debug and Trace) 简介

目前在嵌入式领域ARM 架构是主流，RISC-V 架构是新锐（MIPS 架构也转投RISC-V 阵营），ARM Cortex 架构使用的调试跟踪系统是ARM CoreSight。

我们做嵌入式开发调试，只需要简单了解调试跟踪系统的大概组成结构和基本工作原理，帮助我们能善加利用这个强大的调试跟踪系统，可以大幅加快程序开发调试效率。硬件调试器配合调试软件已经帮我们封装了大量的细节，因此我们并不需要了解其过多的细节，下面以比较简单的单核Cortex-M3/M4 为例，展示ARM CoreSight 概貌。

在博文：ARM 代码烧录方案与原理详解中已经介绍过ARM Cortex 提供的Debug Port，下图中颜色较深的模块都是ARM CoreSight 的组成部分，对外提供了Debug 和Trace 两个接口：
Cortex-M4 框图

ARM Cortex-M 调试跟踪模块主要包含以下几个部分：

FPB(Flash Patch and Breakpoint) Unit：闪存地址重载指的是将Code空间的指令或字面量重载到SRAM 中，断点单元可以产生断点事件，从而使处理器进入调试模式（暂停处理器模式或者调试监视器异常模式，后者不暂停处理器而是执行异常处理程序）；
DWT(Data Watchpoint and Trace) Unit：数据观察点单元可以产生数据观察点事件，让处理器进入调试模式（halting mode or