[参考译文] TM4C129XNCZAD：使用优化时出现硬件CRC错误

您好 ，Matthieu，

 阅读CRC模块操作的数据表，我不确定为什么不从CRCSEED寄存器读取CRC校验和。 在您的初始化过程中，我没有看到您选择任何 后处理功能。 您只能选择CRC_CFG_INIT_1 | CRC_CFG_SIZE _8位|CRC_CFG_TYPE_P1021。 如果您阅读的是CRCSEED注册而不是CRCRCRSLTPP，该怎么办？ 您是否看到正确的校验和结果或它是否也受到-o2优化的影响？

12.2 1 CRC初始化和配置
CRC引擎在推送模式下工作，这意味着它可以处理流数据。 本节
介绍了初始化CRC模块的步骤：

1.通过在CRC模块(RCCGCCM)寄存器系统控制中设置R0位来启用CRC
偏移0x674。

2.配置所需的CRC数据大小，位顺序，端点配置和CRC类型
编程CRC控制(CRCCTRL)寄存器，偏移0x400。

3.如果尚未使用CRCCTRL中的INIT字段将CRC值初始化为全部0或全部1
在CRC种子/上下文(CRCSEED)寄存器中注册初始值，偏移0x410。

4.在CRC数据输入(CRCDIN)寄存器中重复写入数据字段，偏移0x414。 如果
CRCCTRL寄存器中的大小位设置为SELECT字节，CRC引擎以字节为单位运行
模式，并且只有最低有效字节用于CRC计算。

5.完成CRC后，阅读CRCSEED注册表以获得最终结果。 如果使用后处理，
原始CRC结果存储在CRCSEED寄存器中，最终的后处理结果CAN中
从CRC后处理结果(CRCRSLTPP)寄存器读取，偏移0x418。
后处理选项可通过CRCCTRL寄存器的OBR和OLNV位进行选择

这是否不正确？ 读取 CRC后处理结果(CRCRSLTPP)寄存器时是否存在未记录的计时？ CRC计算如何能用一个周期而不是XOR或位反向？[/QUOT][QUOTE userid="25.857万" url="~/support/pmspectors/arm-based mspectors/group/arm-based -byte/f/arm-based -forum-forum/108.3956万/tm4c129xnczad-hardware-crc-error-mspectors"我们在微控制器和NOP之间添加了最后一个工作后处理优化结果后添加了优化。 [/引述]

 我无法查看CRC模块的实际电路。 计算出的校验和可能先存储到CRCSEED寄存器，然后在将后处理数据捕获到 CRCRSLTPP寄存器之前进行后处理。 这可能导致CRCSEED和CRCRSLTPP之间的一个周期差。  我不是编译器专家。 我认为-o2可以改变顺序。 实施NOP是正确的做法。

我尝试 用 CCM_O_CRCSEED替换CCM_O_CRCRSLTPP，并观察到相同的行为。 因此，这建议使用多个时钟周期来执行与数据表中所述相反的操作。 您能在您身边检查一下吗？ 在读取寄存器中的正确值之前，我们必须知道读取时间是如何的，这一点很重要。

此外，我们检查后处理寄存器而不是种子寄存器的原因是为了有一个更好的可移植代码，这样，如果我们决定更改控制寄存器中的配置，其余的计算将保持不变。

您好，

 我认为CRC计算校验和不需要多个周期。 看起来，优化器似乎正在重新排列读取顺序。 您能否显示汇编代码？

 另请参阅下面有关内存障碍的文章。 如上所述，Cortex-M4F基于Armv7E-M架构，允许处理器进行顺序外存储器操作。 就处理器而言，写入CRCDIN和从CRCRCRSLTPP读取是两种不同的内存传输。 读取不取决于要完成的写入。  在我看来，添加记忆障碍指令或类似您对NOP所做的操作是正确的补救措施。 另请尝试声明变量volatile。  

https://www.sciencedirect.com/topics/engineering/memory-barrier-instruction

您好，

注册表访问权限已声明为易失性：

//! \brief Access a peripheral hardware register
#define M_HWPRegister(peripheral, reg)     (*(reinterpret_cast<volatile uint32*>(static_cast<uint32>(peripheral) + static_cast<uint32>(reg))))

代码未重新排列，说明按正确的顺序执行，您可以在下面的屏幕截图中查看。 您甚至可以注意到，在STR至CRCDIN寄存器和LDR至CRCSEED寄存器之间执行BNE指令。 由于在BNE和LDR指令之间添加NOP指令似乎可以解决问题，DSB指令 很可能会更好地工作，但这与数据表中提到的内容仍有矛盾：

要正确解决问题，首先需要了解问题，这就是为什么我们希望得到合理的硬件解释，以确保执行正确的修复。

此致，

Matthieu Tardivon

您好，Matthieu，

 正如我在刚才的答复中所说，由于设计是在相当一段时间前完成的，所以我不能看到设计的情况。 话虽如此，我看了TivaWare API CRCDataProcesses()如何返回处理过的数据，很明显，它最后调用了CRCResultRead()。 通过调用 CRCResultRead，它 显然会引入延迟，其效果与NOP相似。 可能是在API开发过程中故意执行的，当他们遇到您所面临的相同问题时，就会进行另一个函数调用来延迟校验和的读取。  我认为，如果您使用TivaWare读出数据，您不会遇到问题。 您是否可以尝试使用TivaWare？ 如果您仍想保留自己的代码(DRM样式)，添加NOP是正确的做法。

uint32_t
CRCDataProcess(uint32_t ui32Base, uint32_t *pui32DataIn,
               uint32_t ui32DataLength, bool bPPResult)
{
    uint8_t *pui8DataIn;

    //
    // Check the arguments.
    //
    ASSERT(ui32Base == CCM0_BASE);

    //
    // See if the CRC is operating in 8-bit or 32-bit mode.
    //
    if(HWREG(ui32Base + CCM_O_CRCCTRL) & CCM_CRCCTRL_SIZE)
    {
        //
        // The CRC is operating in 8-bit mode, so create an 8-bit pointer to
        // the data.
        //
        pui8DataIn = (uint8_t *)pui32DataIn;

        //
        // Loop through the input data.
        //
        while(ui32DataLength--)
        {
            //
            // Write the next data byte.
            //
            HWREG(ui32Base + CCM_O_CRCDIN) = *pui8DataIn++;
        }
    }
    else
    {
        //
        // The CRC is operating in 32-bit mode, so loop through the input data.
        //
        while(ui32DataLength--)
        {
            //
            // Write the next data word.
            //
            HWREG(ui32Base + CCM_O_CRCDIN) = *pui32DataIn++;
        }
    }

    //
    // Return the result.
    //
    return(CRCResultRead(ui32Base, bPPResult));

您好，Matthieu，

 很抱歉，我无法提供您正在寻找的答案。 这款MCU的芯片设计 是近10年前完成的。 芯片的设计数据库库已在磁带存档中。 即使可以检索设计数据库，我也不确定打开和模拟数据库的障碍是什么，因为EDA工具在10年的时间内会发生变化。 最后，我是一名应用工程师，在过去几年中选择了此MCU支持，现在已经没有具备此MCU相关知识的设计工程师可以模拟数据库。 我知道您可能不会接受我的答案，但很遗憾，这是我能给出的最好解释。   

您好，Ralph，

感谢您的详细回答。 如果您无法在运行中的服务器上访问任何最新设计的实时版本来完成您的工作， 这是一个遗憾，我希望您的管理层将来会考虑这件事，以便最终使您的团队和客户受益

关于技术细节，我想CRC HW计算是通过结合多种方式完成的，主要是异步门和一级同步门/翻转，这将解释数据表中的“单周期”和“在一个时钟中组合计算”语句。 因此，限制来自Charles链接中的陈述："但是，由于处理器具有写入缓冲区(如6.9 部分中所述 )，需要多个时钟周期的数据写入可能与后续操作的执行并行进行。" 这也是为什么我认为使用DSB指令可能是最可靠的解决方案，我们将坚持使用，因为它应该易于测试。 如果我们再次遇到一些类似问题，我们将按照您的建议行事，如TivaWare，并添加NOP说明。

此致，
Matthieu Tardivon