工具/软件：
尊敬的 Jagadish：
我在测试过程中观察到了一些东西。 我使用不同的值调用了 CRC 计算 API 两次、首先是 35、然后是 0。 第一个呼叫的预期结果为 160（十进制）、第二个呼叫的预期结果为 161。
这是因为在我的例子中、对于第一个调用、我期望初始值为 0；对于第二个调用、初始值应该是第一个调用的 CRC 结果。 由于我将根据数据 ID、计数器和 CAN 数据等各种因素累加计算最终 CRC、因此之前生成的 CRC 应用作下一次调用的初始值 — 前提是两者之间不会发生复位。
但我注意到、对于每次 CRC 调用、初始值始终设置为 0。
我使用 MCRC 时观察到的结果为 160 和 0。
尊敬的 Sravya：
每当我们调用“SDL_MCRC_FULL_CPU_TEST" API“ API 时、顺序如下：
1、首先它复位现有的 CRC 计算值、这意味着签名寄存器将变为零。
2.在这里,它再次为新的 CRC 生成配置大小和算法。
3.在这里它将计算您的新输入的 CRC。
因此、如果您每次调用“SDL_MCRC_FULL_CPU_TEST"，“，此、此函数都会在 CRC 变为零时多次、然后再次根据初始值（即零）计算 CRC。 如果您要多次调用该 API 并希望每次保留这些值、请创建另一个 API 来进行 CRC 计算、并仅保留“SDL_MCRC_computeSignCPUmode" API“ API、并在复位后仅调用一次复位和初始化 API。 现在、您可以调用 SDL_MCRC_computeSignCPUmode API 来保留旧值、然后再次向之前生成的签名添加更多数据。 只要您需要、在 CRC 计算完成后、就可以执行此操作、然后尝试调用“SDL_MCRC_channelReset"以“以复位现有 CRC 并重新启动 CRC 生成。
--
此致、
Jagadish。
尊敬的 Jagadish：
我尝试了你上面提到的相同方法,但我得到了错误的结果第二次调用 MCRC 函数SDL_MCRC_computeSignCPUmode. 要了解 MCRC 的确切作用、我想检查其寄存器值。 然而、正如我之前提到的、我在调试期间只能看到几个寄存器。 如何查看一组完整的 MCRC 寄存器值？
具体情况如下：
多项式值= 0x1D
数据位大小= 8 位
尺寸= 1
pMCRCData= 35
对于第一个调用、我得到了 160 的输出sectSigVal.L、这是正确的。
对于第二个调用、我提供pMCRCData= 0。 预期的输出是 161、但可以得到 188 个。 
尊敬的 Sravya：
具体情况如下：
多项式值= 0x1D
数据位大小= 8 位
尺寸= 1
pMCRCData= 35对于第一个调用、我得到了 160 的输出
[/报价]sectSigVal.L、这是正确的。
对于第二个调用、我提供pMCRCData= 0。 预期的输出是 161、但可以得到 188 个。实际上、188 是预期结果、
该器件中可能的最小数据宽度大小为 16 位：
我们在代码中也进行了相同的配置：
这意味着实际上、即使我们只写入 8 位数据、在后台、也会获取 16 位（每个输入字节都附加 0x00）数据来生成 CRC。
因此、当我们给出两个字节 0x23 和 0x00 时、这意味着实际的 CRC 生成将如下所示：
CRC 生成所需的数据为 0x00 0x23 0x00 和 0x00。
因此、您可以看到生成的 CRC 为 0xBC（即 188）。 这就是你得到 188 结果的原因。
--
此致、
Jagadish。
尊敬的 Sravya：
它会丢弃 3 字节输入的最后一个字节、还是会在开头添加一个额外的字节以使其为 4 字节（2 的倍数）、然后执行计算？
我们输入数据的每个字节都将附加一个虚拟字节 0x00。
例如、考虑以下输入数据：
这里可以看到、我的输入数据是 3 个字节、即 0xF2、0x01 和 0x83。 然后、我将它们移动到我们的 32 位缓冲区中、如上所示。
现在、对于这种类型的输入数据、CRC 将按以下 16 位顺序生成：0x00F2、0x0001 和 0x0083。 这将是 CRC 生成器的输入。
我们是否可以将 CRC 长度更改为 8 位？？ 因为在我的例子中、它应该将输入数据视为 23 00、而不是 00 23 00
对于此器件、似乎无法实现。
如您所见、TRM 中没有 8 位字长的配置、最小大小仅为 16 位：
--
此致、
Jagadish。
尊敬的 Jagadish：
根据您的解释、只有在执行一次 CRC 计算、然后在下一次使用前复位 MCRC 时、16 位的 CRC 长度才适用于 8 位数据大小。 但是、当您调用 CRC 函数两次时、在字节数据之前添加一个零（就像在本例中那样，而不是 23）00 23 00 00 00是一个重大错误。 我认为 8 位 CRC 长度选项更适合这种情况。 但没关系。
我还有一个疑问。 使用时：
crcType = SDL_MCRC_CTRL0_CH1_CRC_SEL_E2EProfile4
crc length = 32 bits
data size = 32 bits
我的数据为 16 个字节： 00 00 00 00 00 00 00 00 18 00 00 0A 0B 0C 0D 00
我将整个数据分组到pmcrc缓冲区中、如下所示：
pmcrc[0] = 0x00000000
pmcrc[1] = 0x00000000
pmcrc[2] = 0x1800000A
pmcrc[3] = 0x0B0C0D00
CRC 输出值将是多少？ 我的主要目的是了解如何在内部对数据进行分组。
尊敬的 Sravya：
我从您的解释中了解到、只有在执行一次 CRC 计算、然后在下一次使用前重置 MCRC 时、16 位的 CRC 长度才适用于 8 位数据大小。 但是、当您调用 CRC 函数两次时、在字节数据之前添加一个零（就像在本例中那样，而不是 23）00 23 00 0000是一个重大错误。 我认为 8 位 CRC 长度选项更适合这种情况。 但没关系。
你的理解是完全正确的。
[报价 userid=“655195" url="“ url="~“~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1526263/am2634-doubts-in-mcrc-code/5873394 #5873394“]我还有一个疑问。 使用时：
crcType = SDL_MCRC_CTRL0_CH1_CRC_SEL_E2EProfile4
crc length = 32 bits
data size = 32 bits
我的数据为 16 个字节： 00 00 00 00 00 00 00 00 18 00 00 0A 0B 0C 0D 00
我将整个数据分组到pmcrc缓冲区中、如下所示：
在这种情况下、我们的缓冲区数据只会类型化为 32_bit 指针、如下面的屏幕截图所示、然后数据将写入较低的 PSA 签名寄存器中。
因此、CRC 生成器的输入数据为 0x00000000、 0x00000000、 0x1800000A 和 0x0B0C0D00。
对于该输入、CRC 应如下所示在 E2E 配置文件 4 CRC 生成器中：
您可以看到我的控制器也提供了相同的输出：
--
此致、
Jagadish。
尊敬的 Jagadish：
我发现还有一个与选择 32 位数据位大小相关的问题。 情况如下：
crcType = SDL_MCRC_CTRL0_CH1_CRC_SEL_E2EProfile4
CRC 长度= 32 位
数据大小= 32 位
mcrcData.size = 1
我的数据仅为 1 个字节： 0x01
所以、 pmcrcData[0] = 1;
在这种情况下、CRC 输出将是什么？
我观察到的是输出值 0 。 这似乎是因为只有当大小为 4 的倍数时、数据才会加载到 API 内的 MCRC 寄存器中。
还有更多的疑问,
这是您之前作为参考提供的在线计算器,在此它显示的结果与您上面提到的结果不同。 
尊敬的 Sravya：
我观察到的是输出值 0 。 这似乎是因为只有当大小为 4 的倍数时、数据才会加载到 API 内的 MCRC 寄存器中。
[/报价]
- 这可能是一个限制、因为即使对于小于 4 字节的数据大小、通常也需要进行 CRC 计算
您的观察结果正确。 我的意思是、我们将数据大小选择为 32 位：
因此、API 预计数据计数仅为 4 的倍数。
但是、即使对于单字节、也可以将字节数保留为 4、如下所示：
这将只提供正确的结果、因为无论如何、我们数据的较高字节仅为 0x00、对吧？
所以,我想传达的是,如果你的数据不是 4 的倍数,那么给出下一个 4 的倍数。
例如、对于大小为 5、6、7 或 8 的数据字节、我们需要给出字节数、如 8。
--
此致、
Jagadish。
尊敬的 Sravya：
您能为我提供一个标准文件作为参考吗？ 以便我可以认为该值的输出是正确的并与结果进行比较。
没有一个标准的所有多项式,因为我发现,一些多项式工作良好的一些在线工具。
这是您之前作为参考提供的在线计算器、在这里它显示的结果与您上面提到的结果不同
此处它给出了错误的结果、因为如果您将此工具中的多项式与 TRM 中的 E2E 配置文件 4 中的实际多项式进行比较：
您可以看到、中没有 x32 E2E 配置文件 4、 但这个工具是添加 x32 和我尝试了许多方法来删除这个 x32 但这是不工作的。
因此、我建议在此 E2E 资料中使用以下工具 4.
--
此致、
Jagadish。
尊敬的 Sravya：
您能否为我提供 E2E Profile 5（其中 CRC 多项式类型为）的在线参考计算器SDL_MCRC_CTRL0_CH1_CRC_SEL_16bit？
我在支持的多项式中看不到 E2E 配置文件 5：
您能否澄清一下以提供进一步支持？
--
此致、
Jagadish。
尊敬的 Jagadish：
在 前一个 E2E 查询中,我提到了关于 CRC-16 位多项式。
您能告诉我在计算 CRC-16bit 时考虑的多项式值是什么吗? 是 0x1021 还是 0x011021？？ 因为在 TRM 文件中提到 x^16、但对于 16 位多项式、将有 x^15。
然后提供相关的参考在线计算器链接。 
尊敬的 Jagadish：
由于这是我第一次使用 MCRC 模块、我仍在努力清楚地了解它的行为、在这一过程中我有一些疑问。
下面是一个这样的例子：我正在尝试计算输入数据23 00 10 00 00 00 00 00 00的 CRC、其中总输入长度为 9 个字节。
您可以在下面看到、我将该数据加载到 temp_data_buffer 字符数组中。
我使用的 CRC 配置如下：
CRC 类型：SAE J1850
CRC 长度：16 位
数据位大小：16 位（如果数据位大小为00 8 位、我选择 16 位模式以避免 MCRC 模块在每个输入字节前插入一个额外的字节）。
此外、由于该模块在 16 位模式下仅考虑偶数字节计数、因此我已相应地将输入大小更新为 10 个字节。 
以下是输入数据的结构：
pMCRCData[0]= 0x0023
pMCRCData[1]= 0x0010
pMCRCData[2]= 0x0000
pMCRCData[3]= 0x0000
pMCRCData[4]= 0x0000
根据预期的行为、CRC 结果应该是0x2A、但我始终会得到0x50。
为了调试此问题、我尝试检查实际如何将输入数据加载到 MCRC 模块的寄存器中、但我找不到可以验证这些数据的特定寄存器或地址。 您能告诉我应该检查哪个寄存器或存储器位置来跟踪这个吗？
尊敬的 Sravya：
根据预期的行为、CRC 结果应该是0x2A、但我始终会得到0x50。
我提供了与您提到的相同数据、我得到了正确的结果、即 0x2A。
我正在附加我的工程供您参考、请进行一次检查：
--
此致、
Jagadish。
尊敬的 Sravya：
我的问题是您为什么以相反的顺序向 pmcrc 提供数据？？ 而不是 0x23001000 到 pmcrc[0]？？？
实际上、这不是相反的顺序。
我正在尝试计算输入数据的 CRC23 00 10 00 00 00 00 00 00
您在上面提到了您的输入顺序、对吧？ 这意味着应根据您的要求先处理 0x23、这时应仅将 0x23 用作低字节、因为该器件是小端字节序器件。
这意味着低位字节将存储在低位地址中、那么您要处理的任何数据都应始终位于低位字节？
--
此致、
Jagadish。
尊敬的 Jagadish：
感谢前面的回答、但是
我使用的 CRC 配置如下：
CRC 类型：SAE J1850
CRC 长度：16 位
数据位大小：16 位
长度：10
输入数据：00 23 00 10 00 00 00 00 00 00。
在之前的 e2e 回复中、您已尝试使用数据库大小 32 位。 那么,请解释一下它是如何在*pData?中实际加载数据的? 如果我的输入数据如下所示。 
这是我在过去 4 天里提出的问题。
谢谢
尊敬的 Sravya：
我分享给您的示例还基于 16 位的数据总大小：
因此、我使用 16 位而不是 32 位的数据位大小进行了测试。
这里、我的输入缓冲区是 32 位、但没关系、因为在数据写入函数中、我们的数据将类型转换为 16 位指针、仅访问 16 位数据。
如果您按如下方式进行输入：
这将按以下字节顺序存储在存储器中？
如您所见、键入 cast 后、数据将如下所示：
例如、现在、一旦我们将前 16 位数据 0x2300 写入寄存器、则将按 0x23 0x00 字节对数据进行逐字节压缩。 因此、如果我们写入存储在 pMCRCData 缓冲区中的所有 20 个字节、则压缩结果将如下所示。
因此、您将获得超过 20 个字节的最终压缩 CRC 为“0x1E"：“：
--
此致、
Jagadish。
尊敬的 Jagadish：
现在我明白了、无论数据是 16 位、8 位还是 32 位、我们始终会将数据分组为 4 字节块、并pMCRCData以小端字节序的顺序将其加载到中。 这就是为什么、在下面显示的循环中、它总是执行到mcrcDataSize / 4。
通常,如果我们有类似的数据0x100023并将其类型转换为 16 位,它只会考虑0x0023. 但在这里,它将值拆分为0x0010和0x0023,将它们放入不同的位置。 这是我最初感到困惑的地方。
谢谢你。
尊敬的 Jagadish：
考虑与上述相同的数据输入、CRC 数据总大小为 32 位而不是 16 位。 然后、在将类型转换为 32 位后、它将如何考虑最终的输入数据。
对于 16 位类型转换、它将形成如下所述的输入。它将如何形成 32 位类型转换的输入数据？？
CRC 多项式类型= CRC 32 位
CRC 长度=32 位
CRC databitsize=32 位
尊敬的 Sravya：
[引用 userid=“655195" url="“ url="~“~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1526263/am2634-doubts-in-mcrc-code/5890813 #5890813“] 我还有一个疑问. 对于具有多项式值 0x1021 的 16 位多项式 CRC、它是否在末尾执行与 0xFFFF 异或？ 因为我在 CRC 寄存器中获取我的预期值 0xFFFF 的输出在我的测试中、我没有看到与 0xFFFF 执行异或运算。
我的结果仅与以下配置匹配：
初始值 0x0000、输出 XOR 值也为 0x0000。
--
此致、
Jagadish。
尊敬的 Jagadish：
考虑与上述相同的数据输入、CRC 数据总大小为 32 位而不是 16 位。 然后、在将类型转换为 32 位后、它将如何考虑最终的输入数据。
对于 16 位类型转换、它将形成如下所述的输入。它将如何形成 32 位类型转换的输入数据？？
CRC 多项式类型= CRC 32 位
CRC 长度=32 位
CRC databitsize=32 位
尊敬的 Sravya：
32 位多项式的配置设置应如下所示：
正如您现在所看到的、我得到了正确的签名：
请尝试以下操作并告诉我：
--
此致、
Jagadish。
尊敬的 Sravya：
对于 E2E 规范 4、请使用以下在线工具：
这是因为、如果我们 在其他工具中输入多项式 0xF4ACFB13、他们考虑使用 X32、如下所示：
但事实是、它的多项式中没有 X32：
如果使用合适的工具、则它将与生成的 CRC 相匹配：
--
此致、
Jagadish。
尊敬的 Jagadish：
到目前为止、我们不要关注哪一个给出了正确的结果、因为根据您的 MCRC 模块、这个在线计算器 在线计算链接 会产生您预期的结果。 但是、根据 E2E Profile 4 的 AUTOSAR 标准、MCRC 模块显示的结果不符合 AUTOSAR 标准。
即使我在软件中设置初始值、以反映开始时的输入数据、将输出与 0xFFFFFFFF 进行异或运算并最终反映输出数据、结果仍然与 AUTOSAR 标准不匹配。
此外、我正在使用另一个在线计算器获得预期结果。 我相信他们没有考虑 x^32 、因为如果是这样、多项式长度将变为 33 位、这与标准 CRC-32 配置不一致。
之所以强调这一点、是因为您提到了 E2E 规范 4、并且大多数实施都遵循基于 AUTOSAR 的标准。
您能否再次验证我们是否可以生成符合 AUTOSAR 标准的输出？
尊敬的 Sravya：
此外、我正在使用另一个在线计算器获得预期结果。 我相信他们没有考虑 x^32 ,因为如果是这样,多项式长度将变为 33 位,这与标准的 CRC-32 配置不一致。
实际上、他们考虑的是 X^32。 我知道它是多项式的第 33 位。 但是、一些也使用该位的多项式。
如您所见、所有这些多项式也有一个额外位（大于其长度）。
让我在实践中展示一下：
假设我正在以以下配置给出 0xAABBCCDD 数据、您可以看到、我得到的 CRC 为 0x66B24705（请注意，此处 x^32 在生成过程中存在）
现在我在没有 X^32 的情况下也是如此、得到的结果是 0x3F04047C：
在同一个工具中、我包括 x^32、正如您现在所看到的、我得到的结果是 0x66B24705。
因此、该位很重要、它会影响生成的 CRC 结果。
但是、根据 E2E Profile 4 的 AUTOSAR 标准、MCRC 模块显示的结果不符合 AUTOSAR 标准。
根据我的测试、我同意大家的意见、我的测试还表明多项式 E2E 配置文件 4 不符合 AUTOSAR 标准。
由于以下差异：
根据标准、此多项式应具有以下配置：
初始值：0xFFFFFFFF、最终值： 0xFFFFFFFF、输入 数据反射：是、结果数据反射：是。
更重要的是、多项式应为： x32 + x31 + x30 + x29 + x28 + x26 + x23 + x21 + x19 + x18 + x15 + x14 + x13 + x12 + x11 + x9 + x8 + x4 + x + 1
但在我的测试中、我发现该器件具有以下 E2E 配置文件 4 配置：
初始值：0x00000000、最终值：0x00000000、输入数据反射：否、 结果 数据反射：否
更重要的是、多项式为： x31 + x30 + x29 + x28 + x26 + x23 + x21 + x19 + x18 + x15 + x14 + x13 + x12 + x11 + x9 + x8 + x4 + x + 1
我认为我们可以在代码中更改初始值、最终值、输入数据反射和输出数据反射、但我认为不能更改多项式。
不管怎样、我想与内部团队进行一次检查。 我想和他们讨论这个问题,我想知道他们对此的想法。
--
此致、
Jagadish。
尊敬的 Sravya：
我们的设计团队积极研发这款 e2e 配置文件 4 多项式、旨在验证其为何不符合 AUTOSAR 标准。 我的理解是、即使他们确认它不符合 AUTOSAR 标准、也不会有任何软件权变措施、因为它是多项式位的偏差。
那么、我的建议是、为什么我们不继续使用我在下面突出显示的 CRC32 多项式？
Autosar CRC 规范文档中也提供了此多项式
您能否检查此多项式是否满足您的要求？
--
此致、
Jagadish。
尊敬的 Jagadish：
CRC 32 位多项式也被定义为 AUTOSAR 标准的一部分。
降低到 40% E2E 配置文件 4 根据该标准、所使用的 CRC 多项式应该是为指定的多项式 E2E 配置文件 4 、即0xF4ACFB13。
此致、
K.Sravya.
