[参考译文] LAUNCHXL-F280049C：CPU 如何读取 SCI 外设寄存器&amp；IER / IFR 标志

奇怪 的是、HWREGH 似乎正在解析 RXFFST 并忽略热悬停宏弹出窗口中的偏移。 在 while 循环中 HWREGH 的测试挂起时、在 C 文件中使用类似的语法。 无论如何解析32位 HWREG、甚至16位 HWREGH、都不起作用。 十六进 制计算器最终以12h 作为最终产品、并且 H 文件调用不会返回 FIFO 不断变化的字节计数、因为它使用阻塞调用将数据移出到 my (for)循环中的 CPU。  

只有几个字节的 RX-FIFO 通过阻塞宏、然后使 FIFO 死锁。   

静态内联 SCI_RxFIFOLevel
SCI_getRxFIFOStatus (uint32_t base)

return ((SCI_RxFIFOLevel)((HWREGH (base + SCI_O_FFRX)& SCI_FFRX_FFST_M)>>
SCI_FFRX_RXFFST_S)；

===================================================================================================================================================

无论解析如何、重析上述阻塞函数都不会在何时进行。

while ((((HWREGH (SCIB_BASE + SCI_O_FFRX)& SCI_FFRX_RXFFST_M)>>
SCI_FFRX_RXFFST_S)！= SCI_FIFO_TX16)｛｝

电机控制 SDK 4.01中的 IER 和 IFR 标志使用_cregister 符号命名为 extern。 它不会在宽松 ANSI/ISO 编译器模式下解析 IER、这与编译器文本状态在严格中的工作方式相反。

对于从 CCSv9.3复制的工程、我必须将宽松 ANSI 的名称更改为(cregister)、并使 f2800x49c_device.h 与 CCSv11.2中的 cpu.h 相同。 奇怪的是、CCS9.3具有相同的编译器 v21.6.LTS、并解析了符号__cresgister、但 CCSv11.2拒绝了

怀疑 ADCC1存在 PIE 问题、全局组优先级为 SCIB RXISR。 因此、尝试仅针对通过 RXFFST 的离线传输禁用 IER/IFR DINT 的原因：

MyFunc (int agrc、char * argv[]){}

TRM 会保留有关何时 清除相对于字计数(RXFFST)的 INT 触发器(RXFFIL)的关键详细信息。  当 RXFFIL 设置为触发电平1时、当波特率时钟移位与每个单字的 FIFO 中的<=(RXFFST)匹配时清零？ 然而、当字计数(RXFFST = 1)时、下一个移位字匹配<=(RXFFIL)是否会触发另一个外设 INT 并清除 RXFFST 位？   

匹配触发 RXFFIL INT 事件后、RXFFST 似乎不会自动清零、如果不是 R1S 型寄存器、则无法通过读取 RXFFST 来进行阻断。 多个 TM4C 外设寄存器为 RW1C、只需读取内容即可在每个 CPU 读取周期后清除相应的位。

RXFFST 是否必须由 SW 清零？

下面的 TRM 文本是指 TXFFST 和 TXFFIL、并假定 RXFFST 和 RXFFIL 中断触发器的行为相同。

9.可编程中断级别。 发送和接收 FIFO 都可以产生 CPU 中断。 只要发送 FIFO 状态位 TXFFST (位12−8)与中断触发级别位 TXFFIL (位4−0)匹配(小于或等于)、就会产生中断触发。 这为 SCI 的发送和接收部分提供了一个可编程中断触发器。 对于接收 FIFO、这些触发级别位的默认值分别为0x11111和0x00000。

另一个问题似乎是与器件相关的勘误表。 RXST 状态寄存器错误 INT 位是包括溢出条件在内的所有状态标志的 OR。  FIFO 溢出是一个溢出错误、它们是相同的错误条件。 FIFO 溢出通常是由 FIFO 上的输入溢出造成的。 WA 将在寄存器文本声明时检查 RXINT 处理程序中的 SCIRXFIFO RXFFOVF 状态位。 没有人知道这一点、除非审查了寄存器、因为 TRM 文本未详细说明器件具有勘误条件/s

* RXWAKE 标志设置似乎与 RXFFOVF 标志一致、看起来调试 GEL 文件状态位名称与 RXERROR 状态位交叉。 FIFO 被配置 为增强 型 FIFO 模式、并且通常在 RXFFOVF 标志的 RXISR 中断错误状态检查期间置位 RXOE。 我将溢出标志的检查移动到 RXISR 主路径中、但这在其他 TI UART 中并不常见、因为这些 UART 实际上会针对溢出或溢出情况产生异常 ISR。   

与此问题相关的与 SCISXT RXRDY 标志相关的 RXFFOVF 新的相关帖子。  

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1187665/launchxl-f280049c-rxbuf-rxrdy-flag-not-being-set

器件型号：LAUNCHXL-F280049C

您好！

TRM 图图图23-2显示了 FIFO 空进入 SCIRXBUF 接收数据缓冲区的情况、RXRDY 标志是一个 SCISTX 寄存器位。  

当 FIFO 数据被传输到 RX 缓冲区时、为什么 RXRDY 标志不置位、这样应用程序就可以轮询 RXRDY 标志而不会使 FIFO 发生溢出？

用于检查 FIFO 填充数据计数 的 driverlib (sci.h)调用不能阻止 SYSCLK 应用循环读取 RX 缓冲器并使用异步输入数据来保持时间。

似乎 SCI 需要通过阻止来为 SYSCLK 读取 RX 缓冲器计时、直到应用程序发送到 CPU 的每个异步字符的 RXRDY 标志置位/清零。  

奇怪的是、图23-2中未显示任何会禁止设置 RXRDY 标志的逻辑。 然而 、RXRDY 和 RXERROR 标志位从未被置位、只有 RXWAKE 被置位。 在我的上一篇文章中注意到了这些标志在调试 GEL 文件寄存器布局中被交叉参考的情况。

以下为未 启用功能增强型 FIFO 的 SCI 标志位的建议 WA。

几个月前、我不得不设置 RX TX ISR 处理程序的较低外设内核原始顺序以嵌入组1.3、从而优先于组9.3和9.4、这与嵌套规则的状态相反、这些状态根本不起作用、如文档所述。 嵌套 HTML 需要更新、因为它会给人一种印象、即无法在非组成员 ISR 处理程序中修改其他组 IER。 但是、更高外设内核顺序组 INT1.3首先由 CPU-INT 1.3提供服务。 因此、这不是在 组9.3 ISR 内将组1 IER1.3置为有效的嵌套违反、因为无论如何处理它的时间很晚。

点是 RX ISR INT9.3在清除 ACK 组9后可重入、因为 FIFO INT 级别设置为8、ISR 缓冲32个字。 ISR 再次触发、在单个 ISR 事件中缓冲32个字、并在 ISR 处理程序中导致 RXFFOVF 错误。 要使单个 ISR 事件加载32个缓冲字、必须将 FIFO 级别 ISR 事件设置为 NO >8个字。 我执行了相同的32个字 TM4C1294、因为 UART 可以在15个计数时监视 FIFO 空标志、以便在任何给定的 ISR 事件中继续缓冲大于16个字。

如何在 SCI_clearInterruptStatus()已清除 RX ISR 中断后立即停止其换行？

和 (sci.h) Clear ISR 函数不能由 CCS 11.2通过 CTRL +单击函数名称来跟踪源 C 文件。 STIL 需要 RXRDY 标志在增强型 FIFO 模式下工作、而不仅仅是 RX 缓冲模式。 修复 RX ISR 以在清除 ACK 后停止重入、这似乎也有助于停止 RXFFOVF 标志。  

 一旦 SCI RXD ISR PIEIER 标志被置位、即使在清除 ACK 组9后清除 PIEIFR、也很难清除 CPU 中的该标志。 DINT/INTM 不会清除 CPU 中的 IER9.3全局屏蔽位、与图3-2相反、显示一旦 IER9.3位被清除、它可以清除 IER9.3全局屏蔽位。 HWREG 甚至清除了在调试寄存器视图中观察到的错误 IFR 位、有一次它在下次清除 IFR9.4时清除了 IFR9.3。  

 /*清除 IER / IFR 寄存器标志会阻止第二个 FIFO INT 触发器*/
HWREGH (PIECTRL_BASE + PIE_O_IFR9)&= PIE_IFR9_INTX3；
HWREGH (PIECTRL_BASE + PIE_O_IER9)&= PIE_IER9_INTX3；  

尊敬的 GL：

[合并的主题帖、请不要为类似主题创建多个主题帖、谢谢]

RXRDY 标志的定义如 TRM 的寄存器部分所示。 该功能被确定为大多数应用的最佳操作方案。

此致、

Vince

尊敬的 Vince：

 由于我没有启用 CPU IER 9、但 TX/RX FIFO 触发 CPU IER 3、4、9、因此发生了更多情况。 曾相信 SCIB 多路复用至 IER INT 3.4第9组。 这似乎是在 CPU INT IER 3 / 4中启用错误？  

然而、TRM 矢量表3.5.6组9矢量标头状态使用 CPU IER 9。  RX FIFO 随时进入 OVF、> 8个字进入 RX 缓冲区、因为 FIFO INT 触发点设置为8个字。 停止清除 ACK 组9秒 ISR 事件和 RXOVF 的唯一方法是禁用 RX ISR 内的 PIEIER1.3 ADCC1并禁用 PIEIER 9.3、然后在100ns 延迟后启用它。

奇数部分是 IER3是 ePWMx、IER4是针对 eCAPx、如图3.5.6矢量表 TRM 3.4.4所示。

SCI FIFO 中断级别如何在 CPU INT (IER 标志) 9中不使用且自动启用 CPU 寄存器的情况下工作？

即使是16字节、RX FIFO 也会在 EXIT 附近清除 ACK 组9后立即重新进入 RX-ISR、如何停止 THA？ 组1 ADCC1在退出时通过每个 DINT 在 TX/RX-FIFO ISR 中都具有优先级。 似乎应该仅在 RX/TX FFIFO 中断正在发出时禁用 ADCC1 ISR、对吗？  通过 f280049device.h 设置编译器、在宽松 ANSI/ISO 模式下为 IER 事件设置 extern cregister。 IER 不会在任何一个 ISR 中解析、但编译时没有警告或错误。 奇怪的是 、即使在工作场所或项目中禁用了代码分析、__cregister 也不会在 CCS 的后一版本中编译。

这是 C2000 CPU 如何读取外设寄存器 LSB-MSB 或 MSB-LSB 的灯串吗？ 掩码中的寄存器移位发生在<<或>>的方式很重要、并且看起来奇怪地放置在 sci.h 阻止调用中。 在清除 ACK 组9后、当 HID 仅发送28个字时、重新进入 RX ISR 并不是很明显。 RXBUFF 在前 16个字后将它们静噪、锁定 RXFIFO、软件复位不会清除 RXFFOVF 状态。

RXFFOVRCLR 清零不应包含在清零中断调用中(sci.h)。 他甚至希望在 TRM 状态下执行签入用户代码时执行此操作。 在我的 ISR 代码能够读取 RXFFOVF 寄存器之前、它正在清除异常。 我们通常不会在底部清除 ISR、因为这样 会发生可重入的 ISR 事件。 尽管我已经看到、这是一些 C2000示例、但没有提供建议文本来说明原因。 也许应该已经添加了清除 RXFFOVRCLR 标志的原因来调用下面的内容？ 我没有时间研究明显的 C2000 driverlib 调用、大多数调用都是典型的语法其他 TI driverlib MCU 类、并且预计清晰的 ISR 事件中会存在一定的一致性。

  SCI_clearInterruptStatus (SCIB_BASE、ui32IntStatus)；

对 sci.h 的某些调用似乎  不起作用、例如 SIFFRX 字计数 RXFFST <= RXFFIL 中断触发点、从不将值返回到 HWREG。 在阻塞循环挂起 RXFIFO 时、使用 HWREG 读取中的字计数。 可能在清除 ACK 组9后重新进入 RX ISR。 循环缓冲区未命中每个字>16、因为根本没有分块可能导致 RXOVF 标志事件。 第二个 ISR 会在 RXFFOVF 置位标志期间将缓冲区写入0x0、并忽略所有大于16个字的 HID 数据。 令人兴奋的是、仍然是8个字没有问题、但这是具有1个字缓冲器的16字 RX。

RXOVF 不会出现在 TM4C UART 中、并发现它有奇怪的行为 、因为 for 循环会非常高速地将 RxBuffer 清空到 myBuff[i]中。 CPU 和 PIE 应继续优先于任何新的 IER 标志挂起、直到它收到清除 ACK 组9。 似乎 PIE 正在堆叠 IER 挂起事件、并在应丢弃(抢占)任何新的挂起时将 FIFO 触发 INT 置为有效、直到发出清除 ACK 确认、因此我的疯狂会挤占更多 CPU IER 标志、堆栈后的挂起似乎来自 EPIE、在清除 ACK 组9后将 FIFO 泛洪。

CPU IER 位从未由 SW 配置或甚至启用。 SCI TX/RX FIFO 似乎需要3个 CPU IER、或者它们不能正常工作。 CPU IER 标志9的组 INT 多路复用器9未图示 TRM 中断3.5.3图3-2。 这将有助于说明组也需要配置 CPU IER 标志位。

另一点是 IER/IFR 标志的(cregister)关键字未在源文件中解析。 CCS 代码分析认为关键字_cregister 是语法错误。 在 WA 以下以解析 SCI 源代码(全局变量)中的 IER/IFR，即使使用[#include "F28004x_device.h"]最新的 LTS 编译器也不会发出警告_cregister 在 SCI 模块中不会解析，只会对语法提出疑问。 问题是 编译器是否实际注册了这些标志。

cregister volatile unsigned int IFR；
cregister volatile unsigned int IER；

我认为这个问题的一部分与 sci.h INT 将 RX_RXRDY_BRKDT 组合中断定义为1位有关。 即使在增强型 FIFO 模式下、它们也是单独的 INT 源 SCIRXST、即使 SCICTRL2.1 BRKDT 位未置位也是如此。 下面是单独的 INT 位。 否则、下一个软件复位会在其他奇数行为中挂起 FIFO。 可能是由于 HWREG 在 RXISR 中清除 RXFFOVF。 RXRDY 标志 与 BRKDT 分开、因为 RXRDY 并不是 RXERROR 标志位的特定错误条件、并且表示 RXBUFF 有数据。

#define SCI_INT_RXERR 0x01U //！< RXERR 中断
#define SCI_INT_RXRDY 0x02U //！< RXRDY 中断
#define SCI_INT_BRKDT 0x03U //！< BRKDT 中断

GL、

好建议、将 BRKDT 和 RXRDY 分开是一个好的解决方案。

此致、

Vince

尊敬的 Vince：

奇怪的是、有时由于 BRKDT INT 条件、SCIRXST 错误标志不会被触发、尽管 RXRDY 具有相同的 INT 源。  将 sci.h 中的标志分开并不困难。 也许 SDK 应该使用 C：\ti\c2000ware_4.01库来减少冗余、并通过更新版本的 driverlib 更轻松地升级到 SDK 项目构建中。 如果我们引用 C2000ware_4.01、则编译器会发出隐藏警告、并且 SDK 包含类似或修改过的文件。

删除 SDK 工程包括 c2000ware 文件、清理重建索引以引用 C2000ware_4.01 driverlib 会中断工程。 即使将 C2000ware_4.01 driverlib 导入到 IDE 中、也无法在添加的引用中解析库符号的包含路径、例如 GPIO.h、HW_GPIO.h 在修改 sci.h 以分离上述中断源后、这会带来很大的问题。 为了更好地衡量、还在 c2000ware_4.01中删除了修改后的 sci.h 文件。

IER 无法在我的模块中通过(#include f28004x_device.h)解析并与(cpu.h __cregister)冲突的原因必须完全匹配。 在符号 f28004x_device.h 下添加了注释、也在 cpu.h 中解析了 IER 为什么 C2000 SDK 项目中有这么多不同的 MCU 类驱动程序？ C2000 CPU 指令集是否如此不同？  
//#ifndef __TMS320C28XX__
#define __cregister
//#endif //_TMS320C28xx__

上面的帖子使我感到困惑的是 TRM 3.5.5正在思考组标志行、在本例中、INT9.3和 INT9.4 仅表示 PIE 组标志的9和 INT-3的列、INT4是显示为3.5.2.3的 CPU IER 标志。 我启用 CPU IER 标志3、4并且未启用 CPU IER 9的原因。 尽管它在触发 CPU 寄存器标志9、并且在清除 ACK 后重新进入 ISR。 在 TXD 之后每16字节在 HID 数据流中添加200ms 延迟并为两个 FIFO 级别中断启用 CPU IER 9后、这似乎停止。

如果 ISR 未执行，SCITX FIFO INT (INT 级别8)往往会占用 CPU 时间；1. 在传输前检查 IFR 标志、例如(SYSCLK)到异步 GPIO、2. 在从异步 GPIO 端口发送数据之前、调节 FIFO (填充级别)。 奇怪的是、RXFFIL 电平位似乎对控制 FIFO ISR 事件没有任何影响、仅对 INT 触发电平没有影响。 IFR 轮询对于防止 ADC CPU INT1在 CCS 调试或运行时 ADC 中断在未初始化的部分代码上跳过而言至关重要。

我实现了16位外设寄存器通过并行总线被读取到 CPU 累加器中。 然而、具有屏蔽功能的 HWREG 右移数据(>>)似乎表明 ROM 嵌入式 CLANG 解释器读取正在以相反的顺序(MSB-LSB)进行序列化、这是正确的吗？ 我没有研究过 CPU 达到该级别、只是在 HWREG 宏看起来不像定义的那样工作之前、必须存在已接受的纳米爬虫程序(LOL)。

是否有一个 TI 网络链接来解释和说明如何量化 HWREG 宏？   

尊敬的 GL：

我认为这是为了向后兼容。

我将联系编译器专家回答这两个问题

此致、

Vince

您好！

C28数据总线为32位宽。 HWREG 是一个32位数据读取、只需一个脉冲即可完成。

此致。

Veena

我已经知道、为什么寄存器掩码中的右移位与左移位比较正确？ 您能不能看一下 sci.h 中的 RX 阻塞调用它们锁定 FIFO、或者 SCIFFRx 寄存器的 RXFFST 位没有变化。 这就是为什么我怀疑宏 RW 功能正在读回掩码移位的原因、无论 c.lib 或嵌入式 ROM 中存在哪个位置。 桌面数学计算器附带0x12、但这不是 RXFFST 位的偏移量。

您是指这段代码吗？

您好、Veena、

是的、RX FIFO 通过 HWREG 锁定在一个 while 环路中、或者只调用 sci.h 中的现有 HWREG 它不关心掩码是如何移位的<<或>>有相同的锁定问题。

您的意思是、在此代码片段中、您可以在"Registers"视图窗口中看到寄存器位 RXFFT 设置为 RX16 (我相信您是指 RX16)、但它仍然不会从循环中退出？

此致、

Veena

TX FIFO 水平检查功能正常、即使在阻塞循环工作时 TX ISR 也是如此。 RXFFST 偏移量看起来是奇数屏蔽 shft 0x8U、或者对于 RXFFST 位、如果 CPU 拒绝 IER、则不会改变。 C 代码仅在电平接近满或<=某个值后读取 FIFO 到 C 缓冲区。 在 if ()测试内部使用 SCIFFST 字位似乎有效果、但不清楚在多大程度上。 我假设 CPU 正在处理 FIFO、但这可能是在 RX FIFO 模式下使用 while 循环的 chicken 和 egg 方案。

我的逻辑是 CPU 处理的前17个字、因此 SCIFFST 中的字数应减少、而环路检查允许接收更多字。 在这种情况下、FIFO 为空而不是满、因此 C 代码可以再次缓冲16个字、尽管我当时正在尝试缓冲32个字。

/*阻塞检查 FIFO 空间已填充0-15=16个字*/
while (SCI_getRxFIFOStatus (SCIB_BASE)！= SCI_FIFO_RX15)

尊敬的 GL：

/*阻塞检查 FIFO 空间已填充0-15=16个字*/
while (SCI_getRxFIFOStatus (SCIB_BASE)！= SCI_FIFO_RX15)

理论上、只要16字数据包之间的空间足够、该操作就可以接收任意数量的字节。

此致、

Vince

尊敬的 Vince：

它只暂停 RX FIFO、使用 C 代码从 ISR 调用的16字4循环缓冲中读取 FIFO。 鸡肉在蛋前或之后，在缓冲26-28个字时似乎有某种相关性。 当 CPU 无法读取 RX 缓冲器时、OE 标志跳闸、对吧？  

尊敬的 GL：

OE 在"一个字符在 CPU 或 DMAC 完全读取前被传输到寄存器 SCIRXEMU 和 SCIRXBUF 中时特别跳闸。" 因此、在这种情况下、SCI 听起来好像在数据包之间没有足够的时间(中断在停止位之后需要7/8位时间才触发)。 如果数据是1个停止位、并且中断在1/8位时间内未完成、则会发生 OE (以及可能的其他错误)。

此致、

Vince

尊敬的 Vince：

由于供应商对影响类似串行代码的操作系统进行了大量修改、我不得不同时编写 SCI 并调试另一个 UART 问题。 我下周将尝试返回这里、进行任何 SCI 更新。  

一种停止 OE 的想法是在 char buffer[i]之后放置 while｛｝分块、以便它可以清除第16个字的 RX 缓冲区。

尊敬的 Vince：

任何 RXFF 阻塞都会导致 RX 缓冲器被锁定在滚动 SW 复位中的更多问题。 我在清除 ACK 组9的上方添加了额外的清除 RXISR 在清除 ACK 后停止 IFR 标志卡住。 在 C 代码4循环处理前15个字后、从 RXISR 中删除 ADCC1优先级不会停止重新进入。 因此、第二个 ISR 清除可能是针对虚假跳变 OE 和 OVF 标志的 WA。

奇怪的是、4循环中足够的语法(I < 16)不会将0作为实数计数、应在15而不是14停止循环。 还有其他奇怪的问题似乎会影响基本的 c.lib clang 函数、因为在 ARM CPU 上工作的其他代码无法通过类似的调试步进在 x49c 上工作。   

尊敬的 GL：

其中的一个调试路径是确保为 C2000器件正确移植库函数(如果不是来自 TI 的 C2000库)。 C2000器件是16位寻址存储器、而 ARM 是8位寻址。 可以肯定地看到8位和16位代码之间的端口存在问题。

此致、

Vince

尊敬的 Vince：

我还使用的 ARM Cortex M4具有32位寄存器、因此它可以将一个 gulp 中的32个字移入16字 FIFO。 尽管 XDS110调试探针步进仿真器的运行不正常、但由于 RXFFIO 4循环中的计数值减少了1、因此15个计数为16个字。 我打开了一个案例来报告一些 C lib 基本函数在 x49c CPU 调试仿真器或运行时无法正常工作。 我发现(uint16_t char)字长有两个前导零、在调试仿真器中没有显示这些前导零、它们传递到被调用的函数头文件中。 因此、0xC8实际上是0x00C8、它会中断在 ARM cortex M4上正常工作的 C lib 函数。  

RX FIFO 不能为软件复位、也不能处于软件复位环路中。 我 对此感到困惑 、尽管它似乎是 TX FIFO 的外设内核优先级时序问题。 当 RX FIFO 字计数超过16时 、即使在16个字的组之间有20ms-200ms 的延迟、也会随机卡在 SW 复位循环中。  

必须想知道上述内容是否会导致软件复位循环读取 RX FIFO uint16_t (char)。 因为它还通过 char*将16字 gulps 传递到命令解释器函数头。 RX FIFO 调试字与 RX 缓冲区的长度为0x00、在 char*调试后、在具有(int argc、* argv[])头的函数中看到0x0000、并存储随机导致 OE、OVF 的 RX FIFO 数据、同时将 RX 字存储到多个 C lib 数组[n]单元格中。