This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] LAUNCHXL-F280049C:TRM SCIFFRX 寄存器 INT 位6-7

Guru**** 2466550 points


请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1486509/launchxl-f280049c-trm-sciffrx-register-int-bits-6-7

器件型号:LAUNCHXL-F280049C

工具与软件:

尊敬的组:

当位6为 R/W 时、将只读位7清零、TRM SCIFFRX 寄存器的描述字段好像有误码? 位零在以10为底的位置是实数、不考虑位1、一个拼写错误?

用于读/写的定义 SCIFFRx 中断状态和清除似乎不正确、在 FIFFO 级别中断模式下无法读取清除正确的位。 SCI_O_RXST 寄存器中的异常可疑 SCI_RXST_BRKDT 返回在 FIFO 级别模式下使用的状态、仅通过 interruptStatus |= SCI_INT_RXRDY 驱动 RXISR。

考虑调试 GEL 寄存器命名位字段(RXWAKE)标志位根本不是 PIE /CPU 中断状态标志? 也许在阻塞模式下、一些 C2KWare 状态和清除调用会正确工作、以便通过读取缓冲区清除阻塞标志。 此外、对于 FIFO 级别模式中断、TRM 状态会将 RX 缓冲区溢出错误检测例程放置在 ISR 中、并启用 BRKDT 中断以早期错误检测。 然而、在进入 SCIRXFFE ISR 之后、通过调用 SCI_clearInterruptStatus ()来清除接收器标志 OE、PE、FE 状态标志。  

看似 C2Kware 需要将 TX/RX 缓冲区读取模式 ISR 和 SCIFRX/TX 中断状态以及中断清除功能 FIFO 级别模式分开。 C2KWare 驱动程序库将两种 ISR 模式分别强制使用一个功能、并在要将 RX 错误软件复位放入 RXISR 中时强制执行 RX 错误软件复位。 库混乱的结果;未清除 SCIFFRx 中断存在随机 OE 错误、为 SCIFFRx 寄存器定义了错误的位(sci.h)、如下所示。

SCI_clearInterruptStatus():

if((HWREGH(base + SCI_O_FFRX) & SCI_FFRX_RXFFINT) == SCI_FFRX_RXFFINT)
{
    interruptStatus |= SCI_INT_RXFF;  // 0x10U ??
}

SCI_getInterupt Status()

if((HWREGH(base + SCI_O_FFRX) & SCI_FFRX_RXFFINT) == SCI_FFRX_RXFFINT)
{
    interruptStatus |= SCI_INT_RXFF;  // 0x40U ??
}
 

  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    因为我不知道为什么,我就不能和她做爱了。"

    我想快速指出的是、您发布的图片来自器件 TRM 的过时版本(版本-d)。 理想情况下、请参考最新文档(当前版本-h)

    继续讨论您的问题、首先、如果"类型"列将某个位称为只读或只写、而"说明"列描述了 R/W 行为、则该位仍然是只读位或只写位。 如果您尝试使用错误的操作、"说明"列通常只是解释行为。

    其次、我不确定您指的是与位6和位7相关的拼写错误是什么意思。 位7 [RXFFINT]是只读标志、而位6 [RXFFINTCLR]是只写清除位、用于清除 RXFFINT。

    对于 SCI_clearInterruptStatus()、您发布的摘录与 Driverlib 中定义的行为不匹配、显示正确。 恐怕我不明白您要传达的信息是什么?

    此致、
    Jason Osborn

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Jason:

    其次、我不确定您在提及位6和位7相关的拼写错误时的意思。 位7 [RXFFINT]是只读标志、而位6 [RXFFINTCLR]是只写清除位、用于清除 RXFFINT。[/QUOT]

    RIGHT 必须是旧版本、用于位6和位7注意事项(在位7中)。 和调试 GEL 文件布局与 TRM 中所示的位位置不同。 在解码 XDS110仿真器返回到调试仿真器时、GEL 解码会忽略保留位。 每次深吸卡时、不要忘记。   

    对于 SCI_clearInterruptStatus()、您发布的摘录与 Driverlib 中定义的行为不匹配、显示正确。 恐怕我不明白您要传达什么信息?

    奇怪的是 、驱动程序库调用无法清除 RXFIFO 溢出条件、而不能清除 OE 标志。 问题在于、这些调用无法先清除 FIFO 溢出位、然后是中断标志、从而将 FIFO 数据释放到应用程序读取缓冲区中、而不会停止 RXISR 并锁定 RXFIFO。 我们只能在调试寄存器中手动清除条件、只有按照上述顺序、RXFIFO 才会响应标志位更改。 应用程序无法清除溢出 FIFO 标志或中断、即使在继续运行的 TXFIFO 调用中也是如此。 已经解决了这个溢出问题很长时间、并且不完全了解出现了什么问题。

    上述中断标志与在调试暂停和切换到编辑器视图时将鼠标悬停在中断上时可能会看到的十六进制地址不同。 跟踪反向源中断十六进制地址不像 TRM 寄存器视图那样容易。 使用驱动程序库调用中断清除函数的方式、CCS 编辑器没有暴露实际的 PIE 标志地址、因此很难通过偏移地址和目标位转换为 R/W 来在 TRM 寄存器中执行故障排除  

    为什么下面的代码 snip 无法清除调试运行中的手动位切换可轻松执行以下 snip 功能的 RXFIFO 溢出情况?    

      

    [/quote]
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Jason:

    一旦将 RXFFINT 标志设置为高电平、识别出的问题 SCIB RXFIFO 电平检查就不会返回电平状态。 该电平检查始终在 RXISR 函数调用处理传入数据后进行。 当置于 RX 数据处理程序调试中时、以下代码尖峰(FIFO 级别状态)会在始终设置 RXFIFO 溢出标志且设置 RXFFINT 标志的情况下暂停电平检查尖峰、未设置 RX 错误标志、例如 OE、FE、PE。

    为使事情变得更复杂、ADCC 在 SCIB TX/RX FIFO ISR 处理程序中具有最高组中断优先级(1.3)。 这原本位于 MCSDK 21µs ISR 中、因此怀疑 UMCSDK 大致相同的 ISR 时序。

     即使 RXFIFO 上一次 RXFFINT 标志挂起溢出至 ePIE、SCIB TXFIFO 也会继续中断。 可疑 FIFO 级别检查(HWREG)、即使当本地放置在没有堆栈功能(推送/弹出地址)的 RX 处理程序内部(代码 snip)时、也使用易失性 CPU 指令解码。 因此通常会冻结 PIE SCIB RXFFINT 到 CPU 的中断。 RXFIFO RXFFINT 标志永久锁定为高电平状态、需要调试 CPU 复位才能清除锁定的 ePIE 标志。  

    /* Timeout MAX count for getting RXD FIFO bytes */
    for(Timeout = 0; Timeout < timeout; Timeout++)
    {
    	/* Load RX data elements */
    	for(i = 0; i <= 31; i++)//<= 15-31
    	{
    		/* Blocking checks FIFO space filled 0-15=16 words */
    		//while(SCI_getRxFIFOStatus(SCIB_BASE) == SCI_FIFO_RX16)
    
            /* Check RXFIFO OVF flag */
            if(i >= 32)
            {
                /* Check SCIFFRX register FIFO has overflowed */
                if(SCI_getOverflowStatus(SCIB_BASE) == SCI_FFRX_RXFFOVF)
                {
                   if(((HWREGH(SCIB_BASE + SCI_O_FFRX) &= SCI_FFRX_RXFFOVF) &&
                           (HWREGH(SCIB_BASE + SCI_O_FFRX) &= SCI_FFRX_RXFFINT)))
                   {
                       /* Clear Rx overflow status */
                       while(HWREGH(SCIB_BASE + SCI_O_FFRX) &= SCI_FFRX_RXFFOVF)
                       {
                           /* clear SCIFFRX RXFFOVF SCIB */
                           HWREGH(SCIB_BASE + SCI_O_FFRX) |= SCI_FFRX_RXFFOVRCLR;
                       }
                       while(HWREGH(SCIB_BASE + SCI_O_FFRX) &= SCI_FFRX_RXFFINTCLR)
                       {
                           /* clear SCIFFRX RXFINT SCIB */
                           HWREGH(SCIB_BASE + SCI_O_FFRX) |= SCI_FFRX_RXFFINTCLR;
                       }
                    }
                 }
    
                /* Stop OVF FIFO loading */
                return(0);
            }
    
            CcRxBuff[i] = (HWREG(SCIB_BASE + SCI_O_RXBUF) & SCI_RXBUF_SAR_M); 
            
                    /* If the RX FIFO FULL status wait until it empties */
             while(((HWREG(SCIB_BASE + SCI_O_FFRX) &SCI_FFRX_RXFFST_M) >>
                                      SCI_FFRX_RXFFST_S) >= SCI_FIFO_RX8{}
            
            }
            
        }
    }    

      

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    如果 RXFFFOVF 和 RXFFINT 标志无法在 ISR 处理程序或应用中清除、则为长话短说。 TXFFINT ISR 或被调用函数更有可能导致 RXFFFOVF 中出现故障情况。 通过(for /while)循环在数据输入之后战略性地放置 TXFIFO 电平检查、可以阻止设置 RXFFOVF 随机标志。

    在数据输出引起随机 RXFFOVF 标志设置之前进行 FIFO 阻塞电平测试很奇怪。 RX/TX FIFO 中断级别之间的高速循环数据处理需要特定的应用程序处理来避免 RXFFOVF。 由于不会针对 RX/TX-FFINT 清除 ACK 后出现的 RXFFVF RXFFINT 标志设置设置 RXERROR 标志。 不确定将 CLEAR ACK 放置在两个 ISR 的顶部附近会停止问题、因为 ADCC ISR 在两个 TX/RX FIFO 中断中都获得了优先级。  

    看似问题描述了竞态条件和器件修改有助于停止随机的 RXFFOVF 标志条件。