[参考译文] TMS320F28375D：关于 CRC32的计算结果

大家好，我将深入了解这一点，并在明天回来。

谢谢
Sira

大家好、我生病了、将在办公室外工作2天。 我将在周一之前再次与您进行讨论。

希望这可以。

Sira

您好、Sira。

我知道。 我正在等待您的回答。

Kento

您好！

您能否提供一些其他详细信息？ CRC_run32BitPoly1和 CRC_run32BitPoly1反射结果是否相互匹配？ 当您说它们与预期值不匹配时、您从哪里获得"预期值"？

根据我的经验、在这些情况下、首先要检查字节顺序。

谢谢、
Sira

您好！

我从 Wireshark 获得了预期值。

Wireshark 会将 CRC 计算为帧校验序列。 我们在 Linux 上执行了 Wireshark。

(Wireshark 指出 FCS 不正确、但符合规格。

 https://www.wireshark.org/faq.html#q10.1)

 

 

我们通过三个程序计算了数据字节序列(实际以太网数据包)的 CRC。

[A] TI 参考板上的"controlSUITE\libs\DSP\VCU\v2_10_00_00\examples\crc\2837x_vcu2_crc_32"

[B] C 程序 calcrc.c 来自

http://kozos.jp/fpga/spartan3a_ether_tx.html

(抱歉、日语页面)

[C]中的 C 程序

https://blog.goo.ne.jp/masaki_goo_2006/e/69c68a18c872338e8c2751d662706f46

(抱歉、日语页面)

 

CRC 值为[A]=[C]和[B]= Wireshark。

这就是我认为它是一种算法差异的原因。

Kento

您好 Kento、

感谢您提供信息。 因此、您基本上可以将 TI 生成的 CRC 与多个其他 CRC 生成机制进行比较。 至少有一种外部方法与 TI 的 CRC 匹配是很好的。 我不确定 Wireshark 值为何不同。 到目前为止、我只能假设大小、正如我之前说过的、通常是字节的顺序造成了差异。 您能否尝试一下、让我知道您找到的内容？

谢谢、
Sira

您好 Sira、

例如、我在下面输入这些字节数据。

Wireshark 计算的 CRC-32值为预期值。

随附了 TI 参考板的程序[C]。

e2e.ti.com/.../5287.main.c

该程序与进行了一些更改

"controlSUITE\libs\DSP\VCU\v2_10_00_00\examples\crc\2837x_vcu2_crc_32"。

 

[输入数据字节](长度：0x5E 八位位组)(ICMP 数据包)

0000  关断关断 FF 08 00 27 7f 07 af 08 00 45 00

0010  00 54 00 40 00 40 01 21 9c 0A 00 02 0f 0A 00

0020  02 ff 08 00 F9 1D CF 00 01 D9 ce 03 5c 00

0030  00 3b 8a 09 00 00 00 00 00 10 11 12 13 14 15

0040  16 17 18 19 1a 1b 1d 1e 1f 20 21 22 23 24 25

0050  26 27 28 29 2a 2b 2c 2D 2e 2f 30 31 32 33

 

[预期值]

0xf63b3068

 

 

[b] Linux 上的 C 程序 calcrc.c

0xf63b3068

->符合预期的值！！！

 

[A] Linux 上的 C 程序

0x70df6905

->与预期值不匹配

 

字节序交换(下面3个模式)

→也与预期值不匹配

 

[A'-1] A 的输入数据端交换1 (0xAABBCCDD→0xDDCCBBAA)

0x3568f093

 

[A'-2] A 的输入数据端交换2 (0xAABBCCDD→0xCCDDAABB)

0xd7b2bd7d

 

[A'-3]输入数据端交换 A 的3 (0xAABBCCDD→0xBBAADDCC)

0xce394a9a

 

[c]

(假设 CRC 的初始值应在 IEEE802.3中为0xFFFF、

它从采样源更改。)

#define SWAP_TYPE SWAP_TYPE_0

crcResultVcu_1：0xD7B2BD7D

CrcResultC_1：  0xD7B2BD7D

CrcResultVcu_1：0xEAE0CA5C

CrcResultC_1：  0xEAE0CA5C

 

[c'-1]输入数据端交换1 of C (0xAABB、0xCCDD→0xCCDD、0xAABB)

#define SWAP_TYPE SWAP_TYPE_1

crcResultVcu_1：0x3568F093

crcResultC_1：  0x3568F093

→与[A'-1]相同！！

 

crcResultVcu_1：0xFAF09106

crcResultC_1：  0xFAF09106

 

[c'-2]输入数据端交换2 of C (0xAABB、0xCCDD→0xBBAA、0xDDCC)

#define SWAP_TYPE SWAP_TYPE_2

CrcResultVcu_1：0x0DBA7B59

CrcResultC_1：  0x0DBA7B59

crcResultVcu_1：0xD66F973A

CrcResultC_1：  0xD66F973A

 

[c'-3]输入数据端交换 C 中的3 (0xAABB、0xCCDD→0xDDCC、0xBBAA)

#define SWAP_TYPE SWAP_TYPE_3

crcResultVcu_1：0x6D69A3D1

CrcResultC_1：  0x6D69A3D1

crcResultVcu_1：0xF9C6F089

CrcResultC_1：  0xF9C6F089

我期待您的回复。

Kento

Kento、

感谢您的回复。 我确实认识到 CRC 计算有许多不同的方法和程序、我们很难跟踪和维护所有这些方法。

但是、我们为 TI CRC 库提供的功能是能够灵活地计算 CRC、并按照您希望的方式计算 CRC。 为此，我们有以下选项：
奇偶校验、即字节序。 此设置允许您确定 CRC 计算的第一个字节是数据缓冲区16位字的 LSB (偶校验)还是 MSB (奇校验)。
2、位顺序、即使用"反射"选项。 此设置允许您确定用于 CRC 计算的数据字节是正常取值、即字节=位(7：0)(CRCMSGFLIP = 0)还是翻转、即字节=位(0：7)(CRCMSGFLIP = 1)。

我鼓励您了解预期 CRC 的确切生成方式、即使用上面的配置值。 如果已知、您可以在 TI CRC 库中设置相同的设置并生成 CRC。 否则、它将成为一个猜测的游戏、您必须尝试各种不同的东西。

对您的代码进行一些注释：
1.我看到了一个#if swap_type == swap_type_1 || swap_type == swap_type_3部分以及一个#if swap_type == swap_type_2 || swap_type == swap_type_3部分。 因此、似乎 SWAP_TYPE_3出现在两个位置。 不确定目标是什么。
2.在第一组中、您好像正在交换存储器中的16位字。 不确定您为什么这么做。
使用第二组、它看起来像是一个错误-您将16位值复制到一个临时变量、然后将存储器值分配给 MSB、然后使用 LSB 对其进行 ORing。 因此、看起来您正在破坏这些值。

谢谢、
Sira

您好、Sira。

感谢您的回复。
正如您所说的、有许多不同的方法可以计算 CRC。
对我来说最大的问题是、在这种变化中没有统一的术语或符号、
这是因为我们无法唯一确定它是哪种方法。

当然、我们不希望"猜中的游戏"、
我知道 IEEE 802.3所需的算法。

[IEEE-802.3 CRC32以太网标准]
发生器多项式0x04C11DB7 (* 1)
初始值0xFFFFFFFF (*2)
最终 XOR 值0xFFFFFFFF (*3)
位顺序 LSB 优先(* 4)
输出位顺序 LSB 优先(*5)

如何设置(*1)-(*5)？
我认为如下。
(*1)我明白了。 我必须调用 crc_run32BitPoly1()或 crc_run32BitPoly1Reflected()；
(*2)我也理解。 我必须调用 crc_run32bitXXX()，其中 fedValue = 0xFFFFFFFF。
(* 3)我认为 TI 库不支持最终 XOR。 但我可以计算 crcResult 的 XOR、不能吗？
(* 4)(* 5)您可以通过调用 CRC_run32BitPoly1 ()或 CRC_run32BitPoly1Reflected ()进行更改。
我认为 CRC_run32BitPoly1Reflected ()匹配。

我的最终愿望是、我只希望 VCU-II 采样程序符合 IEEE 802.3标准。
我认为 IEEE802.3是使用最广泛的 CRC-32位示例之一、因此我认为它对其他 TI 用户很有用。

谢谢、
Kento

Kento、

3.可以、您可以计算 TI CRC 结果的异或运算。

我建议您计算4个 TI CRC：
偶校验和 CRC_run32BitPoly1 ()
奇数奇偶校验和 CRC_run32BitPoly1 ()
3.偶校验和 CRC_run32BitPoly1Reflected()
奇数奇偶校验和 CRC_run32BitPoly1Reflected()

在每种情况下、记录结果 CRC 和结果 CRC 的异或。

此外、您是否确定 Wireshark 和其他与 Wireshark 匹配的方法使用所有数据字节进行 CRC 计算？

我还建议删除数据缓冲区末尾的虚拟数据字、即让数据缓冲区为静态 uint16_t testInput[NWORDS]而不是静态 uint16_t testInput[NWORDS + 1]

谢谢、
Sira

您好、Sira。
感谢您的建议。

我花了一点时间做了一个实验。
遗憾的是、结果都不匹配。

首先、为了简化问题、我将输入数据设置为4个八位位组的倍数。
因此、"NWORDS + 1"变为"NWORDS"

[输入数据](添加0x0000、总共96个八位位组)
FFFFFFFF ff0800 277f07af 08004500
00540000 40004001 219c0a00 020f0a00
02ff0800 f9a71dcf 0001d9ce 035c0000
00003b8a 09000000 00001011 12131415
16171819 1a1b1c1d 1e1f2021 22232425
26272829 2a2b2c2d 2e2f3031 32330000

[预期值](由 calcrc.c [B]计算)
d0d534b2

偶校验和 CRC_run32BitPoly1 ()

结果：        0xED95E7AD
ResultXOR：0x126A1852

奇数奇偶校验和 CRC_run32BitPoly1 ()

结果：        0x5F63D2EE
ResultXOR：0xA09C2D11

3.偶校验和 CRC_run32BitPoly1Reflected()

结果：        0xC62679D6
ResultXOR：0x39D98629

奇数奇偶校验和 CRC_run32BitPoly1Reflected()

结果：        0x358CE2A7
ResultXOR：0xCA731D58

我认为 VCU - II 不能支持 IEEE 802.11。 没有太多根据、但我想原因可能是位顺序或端字节序关系。

TI 的示例程序是比较 VCU - II 和表方法、该算法很难理解。 如果存在不是表方法的简单 C 语言实现、您能否提供？

谢谢、
Kento

您好、Kento、

感谢您尝试我的建议、遗憾的是、结果仍然与预期结果不相符。

有一个 C 参考实现不是基于表、但我不确定它是否适合您的需求。 我已附加它。

我认为我们的参考汇编例程在满足所有客户用例方面存在一定差距、这就是我们的方法向前发展的原因(可能在2019年第3季度末) 为客户提供内在函数、客户可以使用这些内在函数轻松地在 C 语言中编写定制 CRC 算法。很遗憾、即使多项式是相同的、您尝试生成的 CRC 也与 TI CRC 不匹配、 但这并不是很奇怪-因为其他用户过去也遇到过类似的问题(使用不匹配的 CRC)。 这就是我们修改方法的原因。

现在、您能否将此问题标记为已解决？

谢谢、

Sirae2e.ti.com/.../F28335_5F00_Modbus_5F00_CRC_5F00_140905.zip

你好，Sira。

感谢您多次回复我们并提供代码。
遗憾的是、代码实现了 table 方法。

main()@main.c
   结果= CRC16_calc (accum、nbytes、奇偶校验、(uint16_t *)&crcTable[0]、(uint16_t *)&msg[0])；
 ↓μ A
CRC16_calc ()@CRC16.asm
;\param tablePtr   XAR4  指向 CRC 查找表的指针

 参数"crcTable"是 CRC 查找表。

VCU-II 非常快、极具吸引力、令人遗憾的是我们无法使用它、我想澄清为什么不能使用它。
我们将进一步考虑、但如果可能、您能否提供表示 VCU - II CRC 32算法的代码、这不是表法？

谢谢、
Kento

您好、Kento、

很高兴听到您想要使用 VCU-II 我将与另一位专家联系、了解我们的汇编算法是否有参考模型(应该有)。

同时、我希望得到澄清和一些额外的信息-在您的第一条消息中、您提到了 IEEE 802.3、在您的前一条消息中、您提到了 IEEE 802.11。 您能澄清一下吗？ 此外、您能否提供一些与您要计算的 IEEE 标准关联的 CRC 链接？

谢谢、
Sira

您好、Kento、

我与之交谈的专家告诉我、汇编 CRC 例程没有 C 或 MATLAB 模型。 有用于基于表的例程的 C/MATLAB 模型、并且通过将结果与基于表的例程进行比较来验证汇编例程。

在 CRC 不匹配问题上、我们为什么不简化 CRC 并尝试使其与单个数据字或字节匹配？ 例如、使用0x01 (或如果要使用16位字0x0001)并生成带 Wireshark 的 CRC、 对于 TI CRC (如有必要、使用我们讨论过的各种 TI 配置设置组合、可能还使用数据、例如0x1000等)、看看我们是否可以获得匹配。  

谢谢、

Sira

您好、Kento、

我在查找与给定 CRC32实现相匹配的适当 VCU 参数时遇到类似的问题。

这与我得到的结果一样接近：

给定数据字节｛0x12、0x34、0x56、0x78、...｝ 将它们存储为 uint16_t 数组｛0x3412、0x7856、...｝

使用

uint32_t VCU_CRC32反射(uint16_t *数据、 uint32_t len、uint32_t init、uint32_t final_XOR)｛
   CRC.seedValue   =初始化；
   crc.nMsgBytes   = len；
   crc.parity      = crc_parity；
   crc.crcResult   = 0；
   crc.pMsgBuffer  =数据；
   crc.pCrcTable   =空；
   CRC.init        =(void (*)(void *)) crc_init32Bit；
   CRC.run         =(void (*)(void *)) crc_run32BitPoly1Reflected；

   CRC.init(&CRC);
   CRC.run(&CRC);
   返回 crc.crcResult^final_XOR；
｝

当 init = final_XOR = 0xffff 为您发布的数据计算校验和时、我将得到0x6FDC0C16、这是上述函数的结果。

这是0x68303bf6的反向位、它的字节与预期的字节相反。

如果您在此期间找到了更好的解决方案、请告诉我。

此致、

Johannes

 

Johannes、您好！

感谢您花时间分享您的调查结果。 很高兴知道存在相关性(尽管这是一个复杂的相关性！) 您能否分享您的 uint16_t 数据数组以及您过去获得上述结果的"len"值？

谢谢、
Sira

您好，Sira，

下面是我用于测试的代码：

const uint16_t test_data2[47]=｛
0xFFFF、0xFFFF、0xFFFF、0x0008、0x7f27、 0xaf07、0x0008、0x0045、
0x5400、0x0000、 0x0040、0x0140、0x9c21、0x000A、0x0f02、 0x000a、
0x0x02、0x0008、0xa7f9、0xcf1d、 0x0100、0xced9、0x5c03、0x0000、
0x0000、 0x8a3b、0x0009、0x0000、0x0000、0x1110、 0x1312、0x1514、
0x1716、0x1918、0x1b1a、 0x1d1c、0x1f1e、0x2120、0x2322、0x2524、
0x2726、0x2928、0x2b2a、0x2d2c、0x2f2e、 0x3130、0x3332｝；


const uint16_t test_data3[48]=｛
0xFFFF、0xFFFF、0xFFFF、0x0008、0x7f27、 0xaf07、0x0008、0x0045、
0x5400、0x0000、 0x0040、0x0140、0x9c21、0x000A、0x0f02、 0x000a、
0x0x02、0x0008、0xa7f9、0xcf1d、 0x0100、0xced9、0x5c03、0x0000、
0x0000、 0x8a3b、0x0009、0x0000、0x0000、0x1110、 0x1312、0x1514、
0x1716、0x1918、0x1b1a、 0x1d1c、0x1f1e、0x2120、0x2322、0x2524、
0x2726、0x2928、0x2b2a、0x2d2c、0x2f2e、 0x3130、0x3332、0x0000｝；


uint32_t VCU_CRC32_TEST (uint16_t *数据、uint32_t len、 uint32_t init、uint32_t final_XOR)｛
CRC_Obj CRC；
CRC.seedValue =初始化；
crc.nMsgBytes = len；
crc.parity = CRC_奇 偶校验；
crc.crcResult = 0；
crc.pMsgBuffer =数据；
crc.pCrcTable =空；

crc_init32Bit (&CRC)；
crc_run32BitPoly1Reflected (&CRC)；
返回 crc_bitReflect (crc.crcResult^final_XOR、32)；
｝


uint32_t CRC32_VCU；

void crc_test (void)｛
CRC32_VCU = VCU_CRC32_TEST ((uint16_t *) test_data2、2
* sizeof (test_test_udefff)、3 * 0xffffff_datasffff (v3_test_dataset_32)；
｝

使用 test_data2、我将获得 CRC32_value = 0x68303bf6、这是我在响应帖子中提到的结果。

使用 test_data3、我将获得 CRC32_value = 0xB234D0、这是与预期值0xd0d534b2相反的字节。

此致、Johannes

Johannes、

是的、我曾要求 Kento 在讨论中途附加一个0x0000。

我重复了您的测试、并能够使用 test_data2重新生成0x6FDC0C16、但是使用 test_data3、我得到的结果是0x0BAB2C4D。

您能检查一下吗？

谢谢、
Sira

Johannes、

测试结果0x6FDC0C16、当逐字节进行位反转时、会产生与 Kento 的参考预期值相匹配的0xF63B3068 (正如您指出的那样)。 如果不了解该网站参考的功能、就很难知道结果为何不能直接匹配。 您是否使用过任何其他参考网站进行比较？

谢谢、
Sira

[引用 user="Sira Rao80">我重复了您的测试、并能够使用 test_data2复制0x6FDC0C16、但使用 test_data3、我得到的结果是0x0BAB24D。

您可以检查吗？

我已检查、TEST_data3的结果保持为0xB234D5D0。  

我正在 LAUNCHXL-F28379D 上进行测试、但我不希望这会产生任何影响...

此致、Johannes

我尝试匹配 ZIP 计算的 CRC。 我使用 Perl 脚本进行了测试：

！/usr/bin/perl
使用严格；
使用警告；
使用存档：：：Zip；
我的$data = pack ('s*'、0xc0ff、0xc01a、0x1122、0x3344、 0x5566、0x7788)；
printf "%08X\n"、存档：：：Zip：：：computeCRC32 ($data)；

它打印259D4336。 为了使用 VCU 获得相同的结果、我必须执行以下操作：

const uint16_t test_data4[]=｛0xc0ff、0xc01a、0x1122、0x3344、0x5566、 0x7788｝；

uint32_t VCU_CRC32_TEST (uint16_t *数据、uint32_t len、uint32_t init、uint32_t final_XOR)｛
CRC_Obj CRC；
CRC.seedValue =初始化；
crc.nMsgBytes = len；
crc.parity = CRC_奇 偶校验；
crc.crcResult = 0；
crc.pMsgBuffer =数据；
crc.pCrcTable =空；

crc_init32Bit (&CRC)；
crc_run32BitPoly1Reflected (&CRC)；
返回 crc_bitReflect (crc.crcResult^final_XOR、32)；
｝

CRC32_vcu4 = VCU_CRC32_TEST (((uint16_t *) test_data4、2 * sizeof (test_data4)、0xffffffff、ffffff)；

但愿这对您有所帮助。 不幸的是，我没有解释为什么这样做是有效的。

此致、Johannes

Johannes、

我想详细了解您对 CRC 的具体应用。 CRC 的具体用途是什么？ 详细信息、即您的应用程序在计算数据块上的 CRC 时是否正常？ 需要哪些多项式？ 用户可配置的多项式更可取、还是标准多项式就足够了？ 请告诉我。

谢谢、
Sira

[引用 user="Sira Rao80"]您将 CRC 确切用于什么？

我们将其用作通信协议的一部分来检测传输错误。 由于我们的许多器件都使用通信协议、因此我必须通过一个不满意的试错过程来找到匹配的 CRC 参数。 在通信协议中、校验和通常在大约10个字内计算。 在这种情况下、对 CRCrun32BitPoly1输出进行位反转的要求降低了一些性能优势(与基于表的实现方案相比)。

另一种用途是检查外部存储器(例如串行闪存)中的数据完整性。 在这里、CRC 参数并不那么重要。 由于串行闪存较慢、因此基于 VCU 的 CRC 计算的性能优势不太重要。

[引用 user="Sira Rao80">需要哪些多项式？ 用户可配置的多项式更可取、还是标准多项式就足够了？ [/报价]

我对标准多项式很满意。 如果有更多的选择，就更难找到与特定实施(IMHO)相匹配的东西。

此致、Johannes

Johannes、

我方面迟迟未作出答复，对此表示歉意。 感谢您的用例说明！

那么、基本上、消息中有一个嵌入式 CRC、您要通过让 VCU 计算 CRC 来进行匹配？ (假设嵌入式 CRC 本身未损坏)。

在存储器案例中会怎么样？ CRC 要与什么匹配？

的确，BitReflect()性能受到了不幸的影响。 Spru514用户指南具有一个内在函数__flor32()，它的功能与我认为的相同。 您能否检查并查看您是否可以使用它来降低性能影响？

谢谢、

Sira