[参考译文] TMS320F28384S：CM-UART 问题

此外、当接收到一个字符并触发 ISR 时、UARTRIS / UARTMIS 寄存器中不会设置 RXRIS / RXMIS。

谢谢！

Carlo。

您好、Carlo。

感谢您的提问。 您是否正在使用 FIFO？ 否则、RXFE 位的功能发生变化、请参见下面 TRM 寄存器字段。 如果预期的是 FIFO 内容、与接收保持寄存器相比、这种功能变化可能是问题的罪魁祸首：

此致、

Vince

谢谢 Vince，

是的、为了简化操作、我禁用了 FIFO。

因此,如果 FIFO 被禁用,我似乎无法使用任何读取 API (UART_isDataAvailable()、UART_readCharNonBlocking ()、UART_readChar ())、任何写入 API (UART_iswritAvailable()、UART_SpaceChar ())。
第一个字节检查 RXFE 标志状态、如果 FIFO 被禁用(空 RXFIFO)、此值始终为1；第二个字节检查 TXFF 标志状态、如果 FIFO 被禁用(完整 TXFIFO)、此值始终为1。

如果是这样、由于没有 driverlib_cm 支持、也没有 cm bitfield 寄存器支持、唯一的解决方案似乎是基于 HW_REG ()来直接访问数据寄存器 UARTDR。

#define UART_ReadCharNonFIFO ()(HWREG (UART0_BASE + UART_O_DR)
#define UART_WriteCharNonFIFO (c)(HWREG (UART0_BASE + UART_O_DR)= c)

对吗？

另外奇怪的是我已经注意到、每次 UART 中断处理程序被触发时、从 UART_getInterruptStatus()返回的中断状态都是正确的：接收时为0x010、传输时为0x020。
在接收的情况下，如果我在观察窗口中读出 UARTRIS/UARTMIS 寄存器，RXRIS/RXMIS 标志就会置位为0，即使在调用 UART_clearInterruptStatus ()或读取接收到的字符之前也是如此。
传输不存在问题、而是。

原因可能是什么？

谢谢！
Carlo

您好、Carlo。

您是否能够确认数据实际上是在该引脚上接收到的？ 这可能是引脚配置问题(可能无法正确设置 RX 引脚 GPIO 多路复用器设置)。

这里、RX 的示波器捕获可以提供一些帮助。

此致、

Vince

您好 Vince、
定义 UART_ReadCharNonFIFO()和 UART_WriteCharNonFIFO(c)宏后，如上一篇文章所述，我正确接收和重新发送字符。 因此不可能是引脚多路复用问题。

下图是一个字符接收事件。
UART 中断处理程序被正确触发、UART_getInterruptStatus ()正确返回0x010、但手表中的 RXRIS / RXMIS 标志为0。

谢谢！
Carlo

您好、Carlo。

感谢您的澄清！ 如果您参考的是 UARTRIS.RXRIS 位、这就是预期的行为。 当读取 FIFO (适用于 FIFO 模式)或读取单个字节(适用于非 FIFO 模式)时、该位将被清除。 在这种情况下、您创建的自定义 ReadChar 函数将同时读取该字节并清除 RXRIS 位。

此致、

Vince

您好 Vince、

问题是我还没有读过这个角色。
我在调用 UART_getInterruptStatus()以获取中断原因之后被停在一个断点上。

我还注意到，即使在执行 UART_getInterruptStatus()之前停止，问题也会出现。  在这种情况下，UART_getInterruptStatus()也失败，并且返回0。

谢谢！

Carlo

您好、Vince。

是的、我确认在自由运行时没有问题。

这似乎是一个调试器问题、不是吗？  

您好、Carlo。

正确、这似乎是一个与调试器如何中断 SCI 模块有关的问题。 理论上可以使用 SCIRXEMU 寄存器来修改 SCI 对断点的反应方式。 请让我知道这是否适用于该特定问题。 如果不能、我可以联系调试器专家、他们可能可以帮助解决这个问题。

此致、

Vince

您好、Vince。  

SCIRXEMU 是 C28 SCI 外设寄存器、而不是 CM UART 寄存器。

我 找不到类似的 CM UART 寄存器。

不管怎样、这个问题的原因可能是  RXRIS/RXMIS 标志被清零、这是因为 Rx 数据寄存器由仿真器读取以更新观察窗口。

我不知道。。。 无论如何、这似乎是一个调试器问题、而不是硬件/软件问题。

谢谢！

Carlo。

您好、Carlo。

我会联系我们的调试器专家、并让他们对此进行回复、请等待1-2个工作日的回复。

此致、

Vince