您好！
我正在尝试使用器件的 CRC DIN 功能、即设置 MODE > RX_CRC_EN 位、并在每个 NULL 命令响应时检查状态> CRC_ERR 位。 我一直在使用 Saleae 逻辑分析仪来仔细检查我发送的所有数据、尤其是在使用 CRC 功能时。 我当前还清除了 MODE > CRC_TYPE 位、这意味着我正在使用数据表中称为"CCITT"的信息(尽管有些人将其称为"CCITT-false")。
使用该算法、当我发送 NULL 命令时、我发送以下帧(24b 字长)：0x 000000 1D0F00 000000 000000 000000 000000 000000 000000 000000、该帧在命令后立即对齐 CRC MSB (如数据表中所指定)。 我认为"0x1D0F"是正确的 CRC-CCITT (种子0xFFFF)、但在后续帧中对此的响应似乎始终设置了 SPI_CRC_ERR 位。 这对我来说尤其令人困惑、因为之前的 WREG 命令使用形式0b 010A AAAA ammm MMmm 进行正确响应、而不是使用状态寄存器(如果 CRC 不正确的话)进行正确响应。 因此、我非常有信心、我的 CRC 算法(使用已知工作的库、在测试系统中内置的 FastCRC 库)能够正常工作、而且器件的输入 CRC 校验也能正常工作。 我还通过 CRC 引擎运行了测试值(['1'、'2'、'3'、'4'、'5'、'6'、'7'、'8'、'9'])并获得了正确答案(0x29B1)。 我当时想、可能设备的内部 CRC 引擎在每次检查后都没有重新播种、但由于连续的许多写入都是成功的、我认为情况不是这样。
我已经附加了一个由四个帧组成的序列-一个 WREG、一个 WREG、一个 NULL 和一个 NULL -这些帧表明了器件按照预期的方式对 WREG (具有正确的 CRC)做出响应、但在最后一个帧中、对之前的 NULL 的响应为0x3107、 它表示设置了 CRC_ERR 位、这意味着先前的命令(0x000、CRC 为0x1D04)是错误的。
您能否提供有关此处可能出现的问题的任何见解、或我可以尝试诊断的一些测试？
谢谢。
本
