[参考译文] 编译器/CC430F5137：如何在一个&quot 之后分析堆栈；运行到文件中&quot；

您好！

我不太熟悉 CC430系列器件、因此我不能完全确定它支持哪些类型的高级调试功能、但下一页中提供了一些资源、可帮助您调试这种事后剖析方案。  

http://processors.wiki.ti.com/index.php/MSP430_Advanced_Debugging_using_CCSv5 

我会将此主题推迟到器件专家处、因为他们将更加熟悉这些器件。  

希望这对您有所帮助、

拉斐尔

您好！

我已检查 CC430F5137器件勘误表(修订版 AA)、 CPU18存在与 PC/SR 寄存器损坏相关的错误。

因为您已确认 没有堆栈溢出。 可能是由于错误。 请检查此错误。

您好、冬季、

非常感谢您的回复！

所描述的 CPU18行为似乎与我在此期间获得的附加信息非常相关。

在我的一侧、我进一步进行了调试、我将问题缩小到了 I2C 驱动器、该驱动器精确地使用 LPM 模式来极化 I2C 协议的某些事件。 例如、生成 I2C 启动条件、然后处理器进入 LPM0睡眠模式、直到 ISR 收到事件中断、然后再次唤醒处理器。 我正是这段代码导致了这种损坏、当我更换它和显式轮询循环(例如使用 while ()-loop)时、我不再遇到问题。

但是、这还不能完全解决问题、因为根据代码、以前的开发人员(不再在这里工作)似乎确实意识到了这个硬件错误、而且似乎仍然出现了问题。 勘误编译器标志也已在 CCS 中设置。

下面给出了一些示例代码

在前台 I2C 驱动程序中生成起始条件：

_generateStartCondition ()；

//输入 LPM0、启用中断
_nop ()；
__bis_SR_register (LPM0_Bits + GIE)；
_nop ()；

在发送完所有字节后的 ISR 中：

UCB0CTL1 |= UCTXSTP； // I2C 停止条件
UCB0IFG &=~UCTXIFG； //清除 USCI_B0 TX int 标志
__BIC_SR_REGISTER_ON_EXIT (LPM0_Bits)；//退出 LPM0 

因此，我有两个问题：

1) 1)这是否是针对 I2C 驱动器的 CPU18权变措施的正确用法？ 如果没有、您能给我一个很好的用法示例吗？

2) 2)实现 I2C 总线同步的首选方法是什么？ 如前所述、我在没有针对轮询的 LPM 模式的情况下成功地使其工作、并且看起来工作正常。 我只是不确定这是否会对功耗产生重大影响。 我们只有一个单线程系统、并且我们不使用 I2C 总线进行扩展数据传输、可能每个周期小于~100字节。

提前感谢！