[参考译文] TMAG5273：CRC 计算 — 奇数行为

您好 Steve、

感谢您发布到传感器论坛！

对于命令字节、如果 8 位 I2C 地址为 0x6B、则我还期望命令字节为 0x6B。  

作为快速测试、您是否能够将器件置于 1 字节、8 位读取模式？ 该模式的计算与 16 位模式相同、只是位数较少。 这样我们就有望缩小可能发生的事情的范围。

另外、您是否碰巧有另一个 A2 型号、您可以尝试一下、看看它是否也会遇到这种行为？

此致、

~Alicia

嗨、Alicia。 感谢您的快速答复。 答复：

对于命令字节、如果 8 位 I2C 地址为 0x6B、则我还期望命令字节为 0x6B。  

同意；这是我最初尝试过的、但它不起作用。

作为快速测试、您是否能够将器件置于 1 字节、8 位读取模式？ 该模式的计算与 16 位模式相同、只是位数较少。 这样我们就有望缩小可能发生的事情的范围。

我尝试了这一点、但两者的结果相同：

Sensor A: 0x00 0xFF 0x00 0xE1 0xEC

Sensor B: 0x00 0x00 0x00 0xC1 0x55

与之前一样、0xBC 与 A 一起使用、0x45 与 B 一起使用

另外、您是否碰巧有另一个 A2 型号、您可以尝试一下、看看它是否也会遇到这种行为？

我不会、但同事可能会这样做；会再回应一次。

更多结果：

我启用了两个芯片的温度传感器，并保持其他设置相同 — 包括 CRC 计算。 这也可以正常工作。

作为实验、对于 CRC 计算中使用的数据、我再次将传感器 A 的字节 0 更改为 0x6B；与之前一样、CRC 计算每次都失败。

我有一位同事在他们的器件上运行工作代码（无论是否启用温度传感器）、他们都没有发现 CRC 故障。

有什么想法吗？ 您是否有可以试用（或模拟）的 A2 传感器？

Steve、

今天,艾丽西亚已经下班了,明天应该回来。   

谢谢、

Scott

您好 Steve、

我让一位同事在他们的器件上运行工作代码（启用和不启用温度传感器）、他们没有发现 CRC 故障。

为了澄清、使用同事拥有的器件、他们是否能够使用预期的 0x6B 值计算 CRC、还是还必须使用 0xBC 值？

您是否能够共享寄存器设置、以便我可以在我的 TMAG5273A2 EVM 上试用该设置？

此外、我还想知道的另一件事是、如果您使用器件的 I2C_Address 寄存器来更改 I2C 地址、看看是否能够使用新的 I2C 地址获得预期的 CRC 结果。

此致、

~Alicia

嗨、Alicia。 感谢您的答复。

为了澄清、使用同事拥有的器件、他们是否能够使用预期的 0x6B 值计算 CRC、还是还必须使用 0xBC 值？

抱歉：他们使用的代码与我完全相同、使用的是 0xBC。

您是否能够共享寄存器设置、以便我可以在我的 TMAG5273A2 EVM 上试用该设置？

使用我们自己的#defines、希望其一目了然：

 ｛REG_CONV_STATUS、   REG_CONV_STATUS_POWER_ON_RESET｝、//通过向其写入 1 来清除 POR。 
 ｛REG_DEVICE_CONFIG_1、REG_DEVICE_CONFIG_1_CRC_ENABLED | REG_DEVICE_CONFIG_1_CONV_AVG_32X | REG_DEVICE_CONFIG_1_I2C_RD_1_BYTE_16_BIT｝、 
 ｛REG_SENSOR_CONFIG_1、REG_SENSOR_1_MAG_CH_EN_XYZ｝、 
 ｛REG_SENSOR_CONFIG_2、REG_SENSOR_CONFIG_2_X_Y_RANGE_A2_133_mT | REG_SENSOR_CONFIG_2_Z_RANGE_A2_133_mT｝ 
 ｛REG_T_CONFIG、     REG_T_CONFIG_T_CH_EN｝、 
 ｛REG_INT_CONFIG_1、  REG_INT_CONFIG_1_MASK_INTB_DISABLE_INT_PIN｝、 

顺便说一下、由于我们使用 32 倍取平均值方法、这需要一些时间、我们发送一条包含转换触发设置的消息、其中包括对 CONV_STATUS：0x98 0x00 的虚拟写入。 然后、我们延迟 3-4 ms、然后读取结果。 事实证明、这是非常可靠的。

此外、我还想知道的另一件事是、如果您使用器件的 I2C_Address 寄存器来更改 I2C 地址、看看是否能够使用新的 I2C 地址获得预期的 CRC 结果。

我会尝试返回并进行报告。

因此、我将传感器 A 的地址更改为几个不同的值、并使用与之前相同的 CRC 相关代码来查找获得正确的 CRC 所需的字节 0 值：

因此、行为始终是意料之外的！

= 异或 0xD7

0xD7 从何而来？ μ s

嗨、Alicia。

当您用 CRC 读回数据时、是否每次转换后都需要使用 0xBC、或者它是否会发生变化？

它始终为 0xBC（同样，当我尝试上表中的其他地址时，实际字节 0 也是类似的常量）。

0xBC 是否可以代替命令咬合、还是更改了？

它是常数。 以下是使用上述结果进行更新的相关代码位：

// CRC byte 0 = address + read bit.
#define CRC_BYTE_0_A  ((I2C_ADDRESS_A | 0x01) ^ 0xD7)  // Where did 0xD7 come from?
#define CRC_BYTE_0_B  (I2C_ADDRESS_B | 0x01)  

//...

crc_calc_data[0] = !is_sensor_b ? CRC_BYTE_0_A : CRC_BYTE_0_B;

是否碰巧知道您当前使用的 TMAG5273A2 器件的修订版？

我会检查一下。

谢谢、

Steve。

是否碰巧知道您当前使用的 TMAG5273A2 器件的修订版？ 它应列在包装袋/包装盒的标签上（如果您仍有的话）。

不、看起来并不是这样。 我们在制造的 PCB 上使用这些芯片、制造 PCB 的公司购买了零件。

您好 Steve、

我可以使用现有的 A2 来尝试这种情况（使用与您相同的寄存器设置）、但对于 CRC 计算、我可以使用预期的 0x6B 获取器件报告的内容。

此外、我最终订购了一些新的 TMAG5273A2 器件、看看其中一个器件是否可以观察到问题。 交付后、我会告诉您我得到了什么结果。

您能否在器件封装顶部分享生产日期代码的图像？

此致、

~Alicia

以下是一张照片：

您好 Steve、

感谢您查看器件的图像。 我计划利用它来确定器件何时制作、以便了解我们是否可以确定命令字节与 A2 型号的预期字节不符的原因。

此致、

~Alicia

您好 Steve、

对延迟的响应表示歉意、但我终于得到了中的样片、其版本应与您的 A2 器件相同。 遗憾的是、我无法重现您看到的问题、其中 0xD7 需要与命令字节进行异或运算才能计算器件报告的 CRC。 使用我拥有的 A2 器件、我能够正确计算 CRC、其中 0x6B 是命令字节。

您恰好知道您的 TI FAE 是谁吗？ 如果是、您是否想联系他们、让他们开始对命令字节不符合预期的其中一个 A2 器件进行 FA 分析、以便我们尝试进一步分析该器件的情况？

此致、

~Alicia