1. 前言2. 常用断点存在的问题3. IAR支持的断点类型和使用方法3.1. 代码断点3.2 条件代码断点3.3 读写访问的数据断点3.4 数据日志断点3.5 日志断点3.6 电源断点4. 总结：5. 经验交流:1. 前言在产品开发中，调试工具是不可或缺的开发利器，除了日常常见的ARM的CMSIS-DAP/ULINK，IAR的I-JET，P&E的U-multilink/Cyclone, 各个半导体厂商自定义的XX-LINK（例如LPC-link, ST-Link,等）之外，还有两个是神一样的存在，一个是SEGGER的J-LINK，支持与IAR/KEIL等各种编译环境无缝衔接，性能稳如老狗, 价格低廉, 所以在嵌入式工程师中的普及率非常高，被称为居家旅行匮赠好友之佳品。
另外一个是一听名字就感觉高大上的劳特巴赫Lauterbach，作为专业第三方调试工具厂商，以其强大的TRACE32开发调试工具享誉全球，TRACE32开发工具拥有非常丰富和强大的功能，包括基本调试配置、RTOS、多核系统、虚拟目标调试、能耗分析以及强大的脚本语言等，而且可以支持市场中使用的80多种常见的微处理架构。
当然Lauterbach性能的强大，对应的代价就是价格也比JLINK多出一个数量级，但是对于大部分嵌入式开发者来说，最常用的还是基本的调试功能，包括断点，寄存器查看，内存/Flash的查看，本文从断点使用的角度讲解如何使用JLINK配合IAR支持的各种断点用出点劳德巴赫的一些强大功能。
2. 常用断点存在的问题断点的概念非常简单，目的简单来说就是在指定指令或者代码行中断程序的执行，实现上可以是硬件断点(通过编程FPB实现)也可以是软件断点(通过插入BKPT断点指令实现 )，具体二者的底层实现这里不展开讨论。
常规的断点调试(本质上是代码断点)是在想观察哪里的问题时就在对应的代码地址双击设置断点，并且一旦运行到断点位置会让程序自动暂停运行，然后观察感兴趣的变量，内存或者寄存器，这种断点调试功能能帮助开发者解决大部分的问题，但是其也有很大的局限性。
因为很多时候我们只想知道某段代码是否运行过，而不能让程序停下来，譬如说调试BLE协议栈，无法去单步运行，否则会打断BLE主机和从机之间的通讯时序，而导致整个系统功能出现问题。
还有中断处理函数的调试，程序一旦停下了也就失去了其他所有中断的后续响应，再比如两个设备通信，一旦一方采用常规断点的方式调试，可能会打断正常的通信过程。
所以通常的做法是添加串口打印或者ITM半主机打印输出log信息到显示屏，但是这种方式会带来额外的软硬件开销(对于串口打印来说是两个UART pin脚+UART驱动函数，对于ITM打印输出是一个SWO+ITM驱动)，甚至因为引入新的代码导致程序出错。
除此之外，还有3种场景是这种普通断点无法满足的，第一个是同一段循环体运行N次才停下来，第二个是当变量被写入新的数据或者被读取时停下来，第三个是实时记录断点所在行某个特定变量或者地址的值，并在时间轴上以图形的形式显示出来，方便分析和对比。
以上这些功能在这些功能在劳德巴赫中是最基本功能，同样在IAR中也提供了不同形式的断点类型和组合，只是日常习惯了只用了其代码断点的功能，没能充分发挥IAR的强大断点功能，针对以上4种问题在IAR中可以分别用日志断点、条件断点、读写权限的数据断点、数据日志断点逐个击破，从而避免了额外添加代码的繁琐，也能为解决隐藏bug提供更加灵活的手段。
尤其是其中的读写权限的数据断点，笔者曾经就是使用这种办法帮客户解决了两个埋藏的很深大bug，其中一个是查找某个关键变量在哪里被意外修改，通过设置条件断点+stack callback迅速定位到了肇事代码段，另一种是客户代码意外堆栈溢出调查，当时的做法是在堆栈大小的90%地址靠近栈顶处设置一个写触发的数据断点，当某层调用过程中堆栈接近溢出时，设置的数据断点会被触发而停止应用程序，从而迅速找到堆栈是在哪层调用溢出的，从而解决问题。
嵌入式物联网需要学的东西真的非常多，千万不要学错了路线和内容，导致工资要不上去。

无偿分享大家一个资料包，差不多150多G。
里面学习内容、面经、项目都比较新也比较全。

某鱼上买估计至少要好几十。
点击这里找小助理0元领取：嵌入式物联网学习资料（头条）3. IAR支持的断点类型和使用方法总结下来，在 IAR 中，主要有以下几种断点，下面逐一介绍。
代码断点条件断点读写访问权限的数据断点数据日志断点日志断点电源断点3.1. 代码断点这种断点就是前面提到的最常用的断点，也是最简单的断点。
开发则只需要在反汇编窗口中选择C行或ASM指令并切换断点。
一旦遇到断点，用户应用程序将停止。
这时候可以查看变量、标志和寄存器的值。
换句话说，开发者拥有完全的控制权。
对于这种普通代码断点，其数量受限于硬件断点的数量，例如对于 Arm Cortex-M，通常有6-8个硬件断点，但如果使用软件断点或在RAM中运行应用程序，则可以不受限制。
使用时只需选择显示View -> Breakpoints 窗口，就可以启用或禁用断点。
默认情况下，IDE 将设置代码断点，而且是auto类型，可以通过Option->Debugger->JLINK/JTrace->Breakpoint去设置硬件断点还是软件断点。
如果开发者有 I-jet，可以在右键单击代码行时明确选择一个 flash断点。
注意断点符号中的“F”。
Flash 断点功能在适用于 Arm 的IAR7.60 或更高版本中可用。
3.2 条件代码断点条件断点是代码断点与某些标志或变量作为条件的组合。
设置断点后，同样可以再次使用View -> Breakpoints 窗口查看所有断点，也可以通过右键单击并选择Edit option来设置额外参数。
设置断点条件所使用的语法类似于C语法，可以使用 ==、>= 和 <=。
例如，如果您希望应用程序在计数器等于 10 时在断点处停止，您可以使用“counter==10”。
这在中断例程中需要断点时非常有用。
如果没有设置条件，应用程序就会一直被停止，影响到系统的正常工作，使用标志或变量作为条件使事情变得容易得多。
甚至用户还可以使用跳过计数器和条件检查（如true或changed）来实现更复杂的断点停止条件设置。
该方法可以解决上面提到的第二种问题。
3.3 读写访问的数据断点与其他断点相比，数据断点有点不同，因为是对特定内存地址、标志、变量或寄存器的读写访问的监控。
使用时只需右键单击标志或变量并选择选项Set data Breakpoint。
默认情况下，对该变量，特定地址，寄存器的任何读取和写入访问都会触发断点。
如果你想添加额外的设置，你可以通过View->Breakpoints 窗口和Edit 选项来完成. 除了读写访问之外，还可以监控数据是否匹配来作为断点的触发条件，这意味着写或读访问只会在数据匹配时触发暂停。
另外，通过选择编辑按钮，开发者还可以打开一个额外的窗口，可以选择绝对地址甚至源代码所在行。
对于变量或标志，建议使用自动大小。
如果需要监控更大的范围，则应手动设置监控的地址范围或者变量范围，譬如说监控一个结构体的数据变化，使用这种数据断点也是可以实现的，但需要用户正确设置变量，特定地址，寄存器等监控对象的Size。
使用这种方法可以解决前文提到的第三种问题。
此处需要特别提一下，数据断点对于调试被应用程序破坏的标志和变量非常有用。
笔者曾经就是使用这种办法在客户解决了两个埋藏的很深大bug，其中一个是查找某个关键变量在哪里被意外修改，通过设置条件断点+stack callback迅速定位到了肇事代码段，另一种是客户端的意外堆栈溢出调查，当时的做法是在堆栈大小的90%地址靠近栈顶处设置一个数据断点，当堆栈溢出接近时，设置的数据断点会被触发而停止应用程序，从而迅速找到问题的根源，至于如何设置，此处暂不展开。
3.4 数据日志断点除了具有读写访问权限的数据断点外，开发者还可以使用数据日志断点。
这种断点的好处在于可以在时间线中监视和以图形方式绘制内存中特定变量或地址的值，使显示更加直观，用户还可以在同一个时间轴上显示和比较两个或多个变量，从而在逻辑上排查问题。
设置的方法就是View->Breakpoints 窗口和Edit 选项，然后选择set Data Log Breakpoint for counter即可，使用这种方法可以解决前文提到的第四种问题。
时间线以及附加数据日志和数据日志摘要可在探针选项下找到，例如如下面的屏幕截图所示。
3.5 日志断点除了代码和数据断点之外，还有一种日志断点，这是一个特殊的断点，因为它只会临时暂时停止应用程序以打印消息，然后继续代码的运行。
一旦运行到设置的日志断点，它会显示如下用户预先设定的消息，告知用户某个函数事件被触发。
这种方式的好处在于，无需额外添加串口打印或者ITM半主机打印输出log信息到显示屏，无需额外的软硬件开销，便可实现基本的信息打印，方便开发者跟踪程序的执行流程。
如下图所示，每次断点命中时，调试日志窗口中都会显示一条消息。
添加的计数器可以了解应用程序通过该部分源代码的次数。
通过这种办法可以解决前面提到的第一个问题，即不停止代码又能获知感兴趣的代码段是否被执行过，以及执行的次数，兵不血刃，无需添加任何额外的代码。
3.6 电源断点除了代码的调试，IAR还支持先进的电源调试技术，可以监控功耗，并将其与源代码相关联。
这也使得添加电源断点成为可能，可以设置一个阈值，如 25mA，一旦能量高于该值，调试器将被触发停止。
设置阈值非常简单, 只需要打开J-Link->PowerLog 窗口，然后设置值和所需选项，如上图或下图所示。
通过这种分析，可以直观的看出代码执行过程中的功耗值，下面的时间线窗口不是必需的，但它可以为提供正在使用的能量提供一个时间参考。
4. 总结：至此，介绍完了IAR支持的6种不同的断点类型和使用方法，也顺带针对性的解决了前文中提到的日常调试遇到的四个问题。
如果在日常调试过程中灵活运用以上的这几种断点，对于日常调试提高开发速度和解决一些深藏的bug(例如前文提到的大型程序中变量被莫名修改，堆栈溢出追踪等) 很有帮助。
当然劳特巴赫之所以卖的这么贵，必然有其强大之处，尤其是强大的脚本编程，多核系统，能耗分析以及对芯片内部操作的开放度，能给开发者最大的操作灵活度。
但就日常的断点调试看，IAR+JLINK的组合也基本能满足大部分的需求，毕竟就地取材最方便。
原文链接：https://mp.weixin.qq.com/s/3b2dsi6Gh05nS4Gfo9lHgQ文章转载自：痞子衡嵌入式文章来源于：如何使用JLINK配合IAR的断点功能用出点劳德巴赫的感觉原文链接：如何使用JLINK配合IAR的断点功能用出点劳德巴赫的感觉版权声明：本文来源于网络，免费传达知识，版权归原作者所有，如涉及作品版权问题，请联系我进行删除