循环执行了很多次，断点却一次也没停；把条件删掉，程序又立即停住。这时通常已经能确认代码会经过断点，接下来应查表达式使用的语法、变量在停机位置是否有效，以及条件是在指令执行前还是执行后检查。TRACE32还支持命中计数，但计数与条件混在一起设置时，排查会更复杂。建议分别验证，再组合使用。

　　一、Trace32怎样设置条件断点与命中次数

　　下面使用TRACE32 PowerView的断点设置窗口说明。断点类型和硬件计数能力取决于目标处理器。

　　1、设置变量条件

　　①在命令行输入Break.Set打开设置窗口，在【address】中填写目标函数或地址，选择【Program】。

　　②点击【advanced】，勾选条件输入框前的【HLL】，在【CONDition】中填写表达式，例如state==3。

　　③点击【set】，运行程序；通过命令Break.List打开列表，核对生成的断点。

　　也可以直接输入Break.Set MyFunc/Program/VarCONDition(state==3)。其中MyFunc和state需要替换成项目中的实际符号。

　　HLL条件按高级语言表达式求值；取消HLL后，条件使用TRACE32表达式语法，对应命令选项也由VarCONDition变为CONDition。两种写法不能只换变量名而忽略语法差别。

　　2、设置命中次数

　　①打开断点设置窗口，在【COUNT】中输入10.，暂时清空【CONDition】，点击【set】。

　　②运行程序，打开【Break.List】，观察计数及停止情况。

　　命令行示例为Break.Set MyFunc/Program/COUNT 10.，表示在第10次命中时停止。这里数字后的点用于明确十进制，避免受调试器数字解释方式影响。

　　计数统计的是所设断点事件。如果地址位于循环体，统计的可能是循环经过次数；设在函数入口时，才适合按入口命中次数理解。调试过程中重新开始测试前，还应确认计数是否已经复位。

　　二、Trace32断点未按预期触发时条件表达式如何排查

　　保留原断点配置，先把问题缩小到“地址有没有命中”和“命中时条件为何不成立”。

　　1、去掉附加条件验证地址

　　①在【Break.List】中打开目标断点的设置，清空【CONDition】，将【COUNT】恢复为1.。

　　②检查【DISable】是否被选中，确认后点击【set】，重新运行。

　　③检查列表中是否出现红色断点或配置错误提示。

　　无条件断点也不触发时，应先核对下载程序、符号文件及实际执行地址。内联函数可能没有唯一入口，不能照普通函数入口设置。若出现硬件断点类型不支持的提示，应按处理器能力调整，不能继续靠改条件解决。

　　2、核对表达式语法和数值

　　①打开断点设置的【advanced】，核对【HLL】是否符合当前表达式写法。

　　②暂停在目标位置，通过命令Var.Watch state查看变量，再用Var.VALUE(state==3)检查比较结果。

　　③将复合条件拆为单项，分别填入【CONDition】测试。

　　高级语言条件可以写成x==10&&y==11；TRACE32条件则可使用Var.Value(x)==10.&&Var.Value(y)==11.。不要混用赋值与比较符号，也要核对有符号数、枚举及位掩码的含义。

　　单项成立、组合不成立时，再检查括号和逻辑运算。表达式出错或变量无法读取，不能当成普通的“条件为假”处理。

　　3、检查变量在当前位置是否有效

　　①无条件停在目标地址后，打开【Var.Watch】，查看条件引用的局部变量或结构体成员。

　　②在【Break.List】中打开目标断点，核对【TASK】和【CORE】等限制。

　　局部变量要在所属函数的有效范围内才能可靠求值。高优化代码中，变量可能尚未初始化、已结束生命周期，或没有可供调试器读取的位置。此时应结合实际指令找有效停机点，不能把源码窗口显示的行号等同于变量已经就绪。

　　多任务或多核项目还需确认停下的是预期执行上下文。同名局部变量也应结合当前调用帧核对。

　　4、确认条件检查发生在写入前还是写入后

　　①对数据写断点打开【advanced】，查看【AfterStep】设置。

　　②若目标处理器在写指令执行前停止，而条件需要检查写入后的值，可启用【AfterStep】，再用简单测试验证。

　　AfterStep会先执行一条汇编指令，再检查条件。它适用于相应的停机时机问题，不能当作所有条件失效时的通用修复。源代码一行可能对应多条指令，必须确认这一步实际完成了哪次访问。

　　三、Trace32条件断点配置完成后怎样复测

　　可以准备一段执行次数明确的测试，让变量按固定顺序变化。停止位置能够事先确定，才容易发现计数或条件设置中的偏差。

　　1、分别验证条件和计数

　　①在断点设置窗口中，将【COUNT】设为1.，只保留【CONDition】，点击【set】后运行。

　　②清空【CONDition】，在【COUNT】中填写需要验证的次数，再次测试。

　　例如让变量依次取0、1、2，先检查条件能否在指定值处停住，再单独验证第几次经过地址时停止。两项分别正确后再组合，避免一次改动多个选项，无法判断是哪项起了作用。

　　2、检查命中后是否自动继续

　　①通过命令Break.List打开断点列表，进入目标断点设置，检查【CMD】和【RESUME】。

　　②暂时取消【RESUME】，移除排查时不需要执行的【CMD】内容。

　　③执行Break.Init复位计数，从相同程序状态重新运行。

　　如果断点命中后执行的脚本包含Go命令，程序仍会继续运行。此时应检查脚本内容。另有些断点带有命中后禁用的设置，也应核对【DISableHIT】，避免重复测试时误以为条件失效。

　　3、核实断点对运行时序的影响

　　①在【Break.List】中禁用不参与本次验证的断点，只保留目标断点。

　　②如需尝试硬件实现，在设置窗口选择【Onchip】，检查是否出现资源不足或类型不支持的提示。

　　选择Onchip并不代表高级语言条件能够由硬件直接判断，条件求值仍可能需要停机。若通信超时、任务竞争等现象只在设置断点后改变，应结合目标支持的Trace功能继续观察，保留无断点运行时的表现作对照。

　　总结

　　调试偶发问题时，“这次没有停住”能说明的事情很有限：代码可能没有经过目标地址，也可能命中过，却因条件或附加动作继续运行。把一次可重复的测试跑通，记下预期停止位置，后面再换复杂场景，判断会容易一些。固件更新后也值得重新核对，尤其是函数内联、变量位置和任务配置发生变化时，旧断点未必仍然适用。希望这些方法能帮到大家，减少反复修改表达式却找不到原因的情况。如有相关需求，也欢迎联系咨询。