[参考译文] TMS320F28075：加电后 SCI 疾病

这是我想说的一点。

目前、在客户代码中、他们在将下一个字节写入 TXBUF 之前检查 TXRDY：

xxxx (UCHAR uC_SendData)

｛

if (m_ptrSciRegs->SCICT2.bit.TXRDY)

｛

uC_SendData = uC_SendData & 0xFF；

m_ptrSciRegs->SCITXBUF.all = uC_SendData；

｝

｝ 

但是、当我查看我们的 driverlib 代码时、不检查 TXRDY、而是检查 TXFFST：

SCI_writeCharArray：

对于(i = 0U；i < length；i++)
｛
//
//等待发送 FIFO 中有可用空间。
//
while (SCI_getTxFIFOStatus (base)=SCI_FIFO_TX15)
{
}

//
//发送字符。
//
HWREGH (base + SCI_O_TXBUF)=数组[i]；
｝ 

因此、我想知道何时启用 FIFO、TXRDY 是否仍然有意义？  我想、如果在 FIFO 模式下检查 TXRDY、会导致溢出等错误？

此致、

Brian  

您好 Brian、

我在文档中找不到专门支持这一点的东西、但我的理解是、在非 FIFO 模式下、TXRDY 用于确定何时发送、而在 FIFO 模式 下、TXFFST 将被使用。  当然、如果您使用 FIFO、那么值得尝试遵循 driverlib 代码示例、或者使用现有方法将模块交替设置为非 FIFO 模式。

系统中是否还有任何其他与传输恢复到预期状态的8秒时间相对应的内容？  是否有一个 ISR 正在存储调用 SEND 数据函数的任何代码？  

是否确定始终使用参数"0x0D"调用 SEND 数据函数？ (您可以添加一个检查+断点来检测意外数据)。  

当在 SEND DATA 函数中执行'If'语句时、您还可以添加其他 GPIO 的切换；这将让您知道数据是否以比发送更快的速度填充到 TX 缓冲区。

您好 Devin、

感谢您的建议。 通过从 USB 电源切换到直流电源、问题得到了解决。 我们不知道有什么区别、但它最终起作用。

通过解决 此问题、我们 已转向真正的问题、这与  我们在已发货产品中观察到的问题相同。

在产品中、加电后、F28075开始向另一个 MCU 发送数据：

数据：AA 2B 01 00 07 00 00 00 00 00 00 00 33 0D

通常、数据将成功传输：

 但是、对于第一个或第二个发送。 最后一个数据(0x0D)将不会成功发送。

在发送前1-2次后、一切都正常。

我建议客户检查 FIFO 状态、而不是 TXRDY、它不是固定的。

此致、

Brian

您好 Brian、

由于该问题似乎与电源有关、因此您是否在 SCI 运行期间测量了3.3V 和1.2V 电源轨或对其进行了限定？  

收发器(如果使用)是由3.3V 电源轨还是另一个电源轨供电？  您是否在运行期间测量过该电源轨或对其进行了范围划分？

您是否在客户系统和 TI EVM 上都看到了此问题、或者仅在客户系统中出现此问题？   

您好 Devin、

为了找出问题、我建议客户移除外部连接并直接测量 F28075上的信号。 但问题仍然存在。

我建议客户稍后在 EVM 上进行测试、以确保它不受 H/D 的影响

BTW、现在有什么28075 EVM？ 我现在在网站上找不到任何 LaunchPad。

此致、

Brian

您好 Brian、

F2807x 的 EVM 是 F28379D controlCARD 或 LaunchPad、因为 F2807x 系列器件是 F2837x 系列中引脚兼容的有意削减。   

我仍然认为研究电源轨是一个很好的实验。  您还可以尝试查看是否由于使用 USB 供电而出现过压或欠压情况而向任何 IO 引脚注入电流。    

Devin、

谢谢！

正如我在上次答覆中所说，他们的产品亦出现类似的问题。 这就是他们进行单板实验的原因。 因此、此问题肯定不是由 USB 电源引起的。

此致、

Brian

您好 Brian、

我对您使用哪个(些)板进行调试有点困惑、但似乎您遇到了相同的问题(0x0D 未正确发送)、这是通过更改电源解决的？  即使电路板不同、我也认为调查电源是一个很好的第一步。

当此代码运行时、代码/系统中是否有其他内容？ 如果是、如果关闭系统的其他组件、问题是否可以解决？

如果您启动系统但延迟了第一个 SCI 传输、则错误是否仍然出现在前1-2个传输中？ 相反、您能否更早地启动 SCI 传输并查看问题是否在更长的时间内发生？