arm的软断点和硬断点

近期我们有个同事遇到个问题，通过iar下载的程序好像断点的信息会保留在程序里，并且程序也被修改了，掉电重启后也会存在。同时运行时会停在断点的地方。

后来我查了查这个问题，今天写个博客，记录一下。

Breakpoints在iar里面默认是Auto的其实大多数情况下就是Software的，软断点。

软件断点则是通过在代码中设置特征值的方式来实现的。当需要在某地址代码处设置软件断点的时候，仿真器会先将此处代码进行备份保护，

然后将预先设定好的断点特征值写入此地址，覆盖原来的代码数据（包括rom flash）。当程序运行到此特征值所在的地址时，

仿真器识别出此处是一个软断点，便会产生中断。当取消断点时，之前受保护的代码信息会被自动恢复。并且软断点理论上可以无穷多个。

因为我们同事他的断点是软断点，并且调试的时候，没有按stop debug 控件，直接关电源停止调试，这样的结果就是修改过的断点指令一直在flash rom里面也就是程序被修改了。

如果按iar上面的stop debug控件，iar是会恢复程序的，再次断点重启时就不会出现程序中断的情况。

 

解决软件断点的方法其实可以使用硬件断点：

硬件断点需要目标CPU的硬件支持，当前流行的ARM7/9内部硬件设计提供两组寄存器用来存贮断点信息，所以ARM7/9内核最多支持两个硬件断点，而ARM11则可以支持到8个硬件断点。这与调试器无关。

M3，M4支持6个。发现st-link调试器的断点是硬断点，m3，m4只能打6个断点。jlink调试器是支持软硬断点的。

但是弊端是断点的数量会受到限制。

 

结论：

软件断点是会在程序的断点处修改原有指令，使其运行到此处时进入异常停下来，而通过jtag发出继续运行指令时，会恢复程序的原有指令，并且跳出异常继续运行，这样如果操作iar很随意，比如调试的

时候直接关电源而没有按iar上面的stop debug控件，就会改变程序的二进制代码，会使程序保留断点指令。硬件断点的局限性是断点数的限制，但是不会破坏程序。

 

 

这个让我联想到我平时调试linux内核使用的kgdb和调试用的gdbserver是打断点，其实他们都是使用的软中断的原理，修改程序的代码，使其进入异常，等待串口或者网口发出的继续运行指令，跳出异常并且

恢复断点位置的处的程序指令。

                                   单片机                                       linux

ide                               keil/iar                                     eclipse CDT/clion

调试协议传输接口        jtag/swd                                   串口/网口

调试工具                       ide自带                                  arm-linux-gdb