[参考译文] MSP430FR6922：在水表大规模生产中 MSP430FR6922上的[紧急] UART 通信冻结

高格雷

感谢您的提问。 请查看下面的回答：

1. 故障率：
   目前、故障率约为2 0% 。

2. 电源复位后的重现性：
   电源复位后、该问题会出现 不会 立即重新出现。 通常需要一些时间或特定条件才能再次发生。

3. RESET 引脚行为：
   我们尚未通过测试恢复 硬件复位引脚 信号。 我们将对此进行检查并确认。

4. 确认其他功能工作：
   我们正在开发 水表 。 即使 UART 无响应、也是如此 流量传感器继续检测变化 和 LCD 显示屏会相应更新 。 这表示除 UART 之外、MCU 仍能正常运行。

5. UART 时钟源和初始化：
   大小 ACLK (32.768kHz) 作为 UART 时钟源。
   以下是初始化代码：

   if (mode == 0)

   { UCA0IE = 0; // Disable UART interrupt

   P4SEL0 |= bit_RXD; // Enable RXD

   P4SEL0 &= ~bit_TXD; // Set TXD 驱动至低电平

   UCA0CTLW0 = UCSWRST；//将 eUSCI 置于复位状态

   UCA0CTLW0 |= UCSSEL__ACLK; // Select ACLK as clock source

   UCA0BR0 = 27; // 1200 baud

   UCA0BR1 = 0;

   UCA0MCTLW |= 0x2500; // Modulation settings

   UCA0CTL1 &= ~UCSWRST; // Initialize eUSCI

   buf[0] = UCA0RXBUF;

   buf[0] = 0x00;

   bufcnt = 0;

   UCA0TXBUF = 0x00;

   UCA0IE |= UCRXIE; // Enable RX interrupt }

6. UART 中断处理和功耗模式：
   是的、我们使用 UART 中断。
   我们系统的运行环境 LPM3 (低功耗模式3) 具有以下行为：

   • a. 看门狗计时器 触发于 1.9ms/51.2ms 检查叶轮状态并可能唤醒系统的时间间隔。

   • UART Rx 中断 将 MCU 从 LPM3唤醒以处理传入数据。

   • UART Tx 通过中断进行处理 传动器中。

7. 地点：
   我们所在的位置 韩国 。

如果您需要更多信息、请告诉我。

此致、
徐基锡

Unknown 说：

故障率约为2. 0% .

剂量该产品是在生产中设计的新产品？

ACLK、内部时钟或外部晶体的时钟源是什么？

顺便说一下、要调试这种问题、当问题发生时、读取内部寄存器状态会非常有用。 如果您通过 CCS 创建工程、也可以加载符号来 直接调试该工程。

以下是如何在不复位器件的情况下读取寄存器的指南。

e2e.ti.com/.../3005.Read-MSP430-PC-counter-and-register.pdf

您可以读取 UART 的寄存器以查看寄存器是否正确配置。

是的、本产品是今年早些时候开发的新设计型号、目前处于早期生产阶段。
ACLK 的时钟源是外部32.768kHz 晶体。
我们已经使用带有符号加载的 CCS 测试了几个正常样本、并能够成功读取寄存器值。
您能否告知在问题发生时、哪些特定与 UART 相关的寄存器有助于捕捉？

Unknown 说：

ACLK 的时钟源是外部32.768kHz 晶体

不知道如果它与外部晶体相关、是否知道您的工程中是否有任何其他模块同时使用 ACLK 或外部晶体？ 如果是、剂量是否有效？

您还可以尝试通过示波器测量 XOUT 和 XIN 之间的信号、以查看器件发生故障时是否起作用。(还可以与良好的电路板进行比较)

顺便说一下、您为 LFXT 配置的驱动电平是多少？

Unknown 说：

我们已经使用带有符号加载的 CCS 测试了几个正常样本、并成功读取了寄存器值。

您是指在失败时对其进行测试吗？ 如果是、您可以在 UART ISR 接收数据部分放置一个断点、看看当数据到来时它是否可以进入 ISR。

感谢您的持续支持。

在查看我们的时钟配置后、我确认了这一点 ACLK 确实正在使用外部32.768kHz 晶体(LFXT) 。

以下是我们工程中当前使用的时钟配置代码：

CSCTL0_H = CSKEY >> 8；//解锁 CS 寄存器
CSCTL1 = DCOFSEL 6；//将 DCO 设置为8MHz
CSCTL2 = SELA_LFXTCLK | ELS_DCOCLK | SELM_DCOCLK；// ACLK = LFXT、MCLK/SMCLK = DCO
CSCTL3 = DIVA__1 | DIVS__1 | DIVM_1；//所有分频器= 1

CSCTL4且=~LFXTOFF；//启用 LFXT
执行｛
CSCTL5 &&~LFXTOFFG；//清除故障标志
SFRIFG1 &=~OFIFG；
} while (SFRIFG1 & OFIFG)；//等待振荡器稳定

CSCTL4 |= VLOOFF；//禁用 VLO
CSCTL6 = 0；//无额外的时钟请求
CSCTL0_H = 0；//锁定 CS 寄存器

至于您有关的问题 LFXT 驱动电平 、我们当前使用的是默认配置CSCTL6 = 0()。
如果建议使用特定的驱动强度来确保稳定性、请提供建议、我们可以相应地进行更新。

我们还将继续 使用示波器测量 XOUT 和 XIN 信号 、并按照您的建议、比较故障设备和良好设备之间的行为。

请告知我们、在该测试期间是否需要重点关注任何特定寄存器或信号模式。

如果您完成了测试、请告诉我测试结果

UART 不会自发停止工作。 这是间歇性的、最糟糕的是要跟踪。 可能是一系列触发软件错误的罕见事件。

或硬件问题。 如果 LFXT 发生故障(EMC 问题？)  则时钟系统会回到另一个源。 可以用于非关键应用、但 UART 比特率发生器不会满意。

对于 UART 而言、作为初始化序列一部分包含的软件复位位将对其进行复位。 不知道为什么在 UCOS16=1中不使用推荐的设置。 我对初始化代码还有其他问题。

P4SEL0 |= bit_RXD; // Enable RXD
P4SEL0 &= ~bit_TXD; // Set TXD low

对于相关的 P4SEL0位、TXD 和 RXD 的正确设置都设置为"1"。 (表6-24)清除 TXD 位。 也许您将其设置在其他位置。如果没有、则无输出数据。 这将更有意义：

P4SEL0 |= bit_RXD | bit_TXD;
P4SEL1 &= ~(bit_RXD | bit_TXD);

向 TXBUF 写入0会立即发送该信息。 您是否确实需要一个早期的空字节、或者您是否期望该字节来清除 TXIFG？

我们特意设置UCOS16为0、因为按照我的理解、建议在低波特率下使用此设置。 我们的通信速度为1200bps、因此我们遵循了该指南。

此外、我们还从出现问题的单元捕获了寄存器值。 请参阅随附的屏幕截图。

从寄存器转储中、我们观察到以下情况：

• UCRXIE = 0→RX 中断未启用

• UCTXIFG = 1→TX 缓冲器已就绪

• UCRXIFG = 0→未收到数据

• UCA1CTLW0 = 0x0001→软件复位位仍被置位

我们想问：

如果UCA1CTLW0 = 0x0001设置了软件复位位()、是否会阻止UCRXIE启用 RX 中断()？
在我们的例子中、UART 似乎保持在复位状态、并且接收中断似乎不会处于活动状态。

此外、您建议检查是否有任何其他寄存器以帮助确定此问题的根本原因？

如果您能深入了解这种行为是否是预期行为、或者是否是我们初始化序列中的某种原因导致的、我们将不胜感激。

谢谢你。

Unknown 说：

我们特意设置UCOS16为0、因为据我所知、对于低波特率、建议这样做。 我们的通信速度为1200bps、因此我们遵循了这一准则。

根据指南："如果 N 等于或大于16、TI 建议通过设置 UCOS16使用过采样波特率生成模式。"

该指南(30.3.1)非常清楚、可以在从复位中释放 UART 后设置 UCA0IE 中的位。

再次查看您的代码、我看到您在设置/清除软件复位时使用两个不同的寄存器名称。 总是可能与之混淆。 选择一个并坚持它。 字版本通常是最好的、因为其中各种位字段的符号用于字版本。 字节版本可能包含一些额外的符号。 例如 UCSWRST_L、用于 UCA0CTL1。

在本例中、UCA0CTL0指 UCA0CTLW0的高半部分。 RESET 位位于低半部分。 因此 UART 绝不会从复位状态释放。

设置 UCSWRST 会清除 IE 位、但不会清除其他位、例如 BRW 或 MCTLW。

您发布的寄存器转储包含 复位值、就像您遇到 PUC 复位但没有(还有？) 重新初始化 UART。 这种顺序是可能的吗？

[编辑：如果您尚未阅读、SYSRSTIV 可能会告诉您一些信息。]