[参考译文] MSP430FR5964：为一个源代码行生成多个断点

尊敬的 Andrew：

您能否提供可重现的测试案例？ 我可以尝试在 FR59x 目标上运行什么？ 它不必是您的实际项目、只是可以重现问题的简单方法(越简单越好)。 我至少需要*。out 和源文件。 如果您不想在此公共论坛上分享、请与我开始私人 E2E 对话。

谢谢

Ki

您好 Ki、

我将会看到我是否可以将其简化为简单的内容-但我对这些问题的跟踪记录似乎是由于简化屏蔽或解决问题。

我确实有一个正在运行的测试用例、该测试用例旨在验证连接到 MLX 温度传感器的某些逻辑、该逻辑确实会出现问题(并且不应依赖于连接物理 MLX)。 这确实包括一个包含 MSPWare 的构建堆栈、以及我们自己的许多低级逻辑。 欢迎您参加、但您更愿意为您提供更容易理解的内容！ 请给我几天时间、我将了解我是否可以用更简单的方法重现此内容。

Andrew

[引用 userid="265677" URL"~/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1028754/msp430fr5964-multiple-breakpoints-being-generated-for-a-source-line/3804449 #3804449"]但会让您更容易理解！ 请给我几天时间、我将了解我是否可以用更简单的方法重现此内容。

谢谢 Andrew。 我只能访问 FR59x LaunchPad、因此如果应用程序尽可能简单、通用、这将是理想之选。 我甚至不需要完全运行应用程序、我只需要一个位置来重现断点问题、就是这样。

[引用 userid="265677" URL"~/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1028754/msp430fr5964-multiple-breakpoints-being-generated-for-a-source-line ]CCS 10.4上的 GCC 工具链和 MSP430目标。 该代码直接来自 CCS 9环境、不记得以前看到过这种情况。

使用显示问题的示例、在 CCS 9和 CCS 10.4中、您可以打开脚本控制台(CCS 菜单视图->脚本控制台)并从运行中发布输出：

eval("DEBUG_DumpBreakpoints()")

这会导致 CCS 调试器转储已设置的断点。

使用 CCS 10.4、GNU v9.3.1.11和 MSP430FR5994时、我尝试创建一个示例、该示例显示了在一个源代码行上设置两个断点的相同问题、但失败了。

[引用 userid="265677" URL"~/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1028754/msp430fr5964-multiple-breakpoints-being-generated-for-a-source-line ]我不会假装了解这里发生的情况、但似乎已将207源代码行关联到存储器列表中的两个位置(0x4710、0x471C)、并且正在设法中断这两个源代码

我认为这是问题的关键、我尝试创建一些执行同样操作的示例代码失败了。

编译器优化有时会发生这种情况。 您还能显示使用的编译器选项吗？

我尝试了一些简单的简化，但自然不想玩球，因为问题立即消失了！

但有一件有趣的事情出现在灯上。 我在不同的可执行文件中发现了两种情况、它们表现出了这种情况、但两者都调用了相同的函数。 我用一个新名称创建了函数的一个深灰色副本、并且调用该函数也显示了问题。 这(可能)表示它以某种方式与函数的签名或其处理堆栈相关、尽管我的基本简化使用了相同的函数调用、但没有问题。 同一库中签名几乎相同的函数不会显示问题。

任何代码都不会以任何优化方式运行(在所有情况下均为-O0)。

现在我们来看看断点转储。 我还包括了断点所在的源代码行、以及围绕该源代码的反汇编。 我只使一个断点处于活动状态以尝试降低噪声。 下面的行很有意思、因为它似乎显示了源代码行219的两个硬件地址、它们与反汇编代码显示的地址相匹配。 添加另一个断点仅显示单个地址。  

MSP430：断点管理器转储：位置：./trunk/MLX_Test.c、第219行("C：\Data\Projects\Software\Micro\Common_Tests\MLX_Test\MLX_Test.Out")(0x46f4)(0x4700)

Andrew

MSP430：断点管理器转储：分配的逻辑断点总数：12.

MSP430：断点管理器转储：分配的软件物理断点总数：6.

MSP430：断点管理器转储：分配的旧硬件物理断点总数：0

MSP430：断点管理器转储：总共分配的55个硬件物理断点：0

MSP430：断点管理器转储：分配的线程物理断点总数：0

MSP430：断点管理器转储：

MSP430：断点管理器转储：启用：2.

MSP430：断点管理器转储：

MSP430：断点管理器转储：硬件配置

MSP430：断点管理器转储：位置："c$$IO$$$"(0xcc4a)

MSP430：断点管理器转储：调试器响应

MSP430：断点管理器转储：条件：

MSP430：断点管理器转储：跳过计数：0

MSP430：断点管理器转储：当前计数：0

MSP430：断点管理器转储：操作：处理 CIO

MSP430：断点管理器转储：其他

MSP430：断点管理器转储：组：默认组

MSP430：断点管理器转储：名称：

MSP430：断点管理器转储：由系统设置的断点

MSP430：断点管理器转储：

MSP430：断点管理器转储：硬件配置

MSP430：断点管理器转储：类型：简单

MSP430：断点管理器转储：操作：停止目标

MSP430：断点管理器转储：触发0：存储器地址总线

MSP430：断点管理器转储：位置：./trunk/MLX_Test.c、第219行("C：\Data\Projects\Software\Micro\Common_Tests\MLX_Test\MLX_Test.Out")(0x46f4)(0x4700)

MSP430：断点管理器转储：屏蔽：1048575

MSP430：断点管理器转储：运算符：=

MSP430：断点管理器转储：访问：取指令

MSP430：断点管理器转储：触发1：无

MSP430：断点管理器转储：调试器响应

MSP430：断点管理器转储：条件：

MSP430：断点管理器转储：跳过计数：0

MSP430：断点管理器转储：当前计数：0

MSP430：断点管理器转储：操作：保持暂停

MSP430：断点管理器转储：其他

MSP430：断点管理器转储：组：默认组

MSP430：断点管理器转储：名称：断点

MSP430：断点管理器转储：用户设置的断点

MSP430：断点管理器转储：

MSP430：断点管理器转储：禁用：3.

MSP430：断点管理器转储：

MSP430：断点管理器转储：硬件配置

MSP430：断点管理器转储：位置："c$EXITE"

MSP430：断点管理器转储：调试器响应

MSP430：断点管理器转储：条件：

MSP430：断点管理器转储：跳过计数：0

MSP430：断点管理器转储：当前计数：0

MSP430：断点管理器转储：操作：终止程序执行

MSP430：断点管理器转储：其他

MSP430：断点管理器转储：组：默认组

MSP430：断点管理器转储：名称：

MSP430：断点管理器转储：由系统设置的断点

MSP430：断点管理器转储：

MSP430：断点管理器转储：硬件配置

MSP430：断点管理器转储：位置："c$$exit"

MSP430：断点管理器转储：调试器响应

MSP430：断点管理器转储：条件：

MSP430：断点管理器转储：跳过计数：0

MSP430：断点管理器转储：当前计数：0

MSP430：断点管理器转储：操作：终止程序执行

MSP430：断点管理器转储：其他

MSP430：断点管理器转储：组：默认组

MSP430：断点管理器转储：名称：

MSP430：断点管理器转储：由系统设置的断点

MSP430：断点管理器转储：

MSP430：断点管理器转储：硬件配置

MSP430：断点管理器转储：位置："c$$IOE$$$"

MSP430：断点管理器转储：调试器响应

MSP430：断点管理器转储：条件：

MSP430：断点管理器转储：跳过计数：0

MSP430：断点管理器转储：当前计数：0

MSP430：断点管理器转储：操作：处理 CIO

MSP430：断点管理器转储：其他

MSP430：断点管理器转储：组：默认组

MSP430：断点管理器转储：名称：

MSP430：断点管理器转储：由系统设置的断点

//断点所在的源代码行

(219) status = MLX_Read (&ctx->mlx_context、request_address、request、

&ctx->Read_data、

&_nextTest、

CTX)；

//反汇编第219行

0046f2：2019 JNE (0x4726)

219 status = MLX_Read (&ctx->mlx_context、request_address、request、

0046f4：013C 0016 MOVA 0x0016 (SP)、R12

0046f8：00ac 000a Adda #0x0000a、R12

220 &ctx->Read_data、

0046fc：013E 0016 MOVA 0x0016 (SP)、R14

219 status = MLX_Read (&ctx->mlx_context、request_address、request、

004700：1800 41D1 0016 0004 MOVX.A 0x00016 (SP)、0x00004 (SP)

004708：1800 40F1 462C 0000 MOVX.A #0x0462c、0x00000 (SP)

004710：0ECF MOVA R14、R15

[引用 userid="265677" URL"~/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1028754/msp430fr5964-multiple-breakpoints-being-generated-for-a-source-line/3806016 #3806016"]任何代码都不会以任何优化方式运行(在所有情况下为-O0)。

请注意、0级优化仍然是一些优化。 任何优化都不会 是-Ooff。 您是否可以尝试不进行优化？

[引用 userid="265677" URL"~/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1028754/msp430fr5964-multiple-breakpoints-being-generated-for-a-source-line/3807432 #3807432"]10.4附带的 GCC 9.3.1编译器肯定不支持-Ooff。 CCS 优化属性窗口将-O0标记为"无"。 我尝试将任何编译选项保留为关闭(这些选项应与-O0相同)、但没有更改。

啊、你完全正确。 抱歉、我是在想 TI 编译器、而不是 GCC

[引用 userid="265677" URL"~/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1028754/msp430fr5964-multiple-breakpoints-being-generated-for-a-source-line/3807432 #3807432"]听起来像我在任何情况下都应该使用的代码、因此将完整的编译树切换到了这种模式、并解决了问题。 我猜测-O0处抑制的一些调试信息是导致调试器混淆的原因？

是的，这种情况确实是如此。  

[报价 userid="265677" URL"~/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1028754/msp430fr5964-multiple-breakpoints-being-generated-for-a-source-line/3807432 #3807432"]我不知道这是否表示存在任何潜在问题

我也不确定。 我需要对此进行探讨。 我了解 调试与优化之间的权衡、但我不希望 看到您所看到的调试行为、尤其是在使用相同的优化级别构建同一项目时、在较旧的 CCS 版本上不会发生这种情况...

谢谢 Ki。

我可以做更多的事情来帮助解决这个问题、还是应该将其关闭？

Andrew