TMAG5273: CRC calculation - odd behaviour

Hi Steve,

Thank you for posting to the Sensors forum!

For the command byte, if the 8-bit I2C address is 0x6B, then I would also expect the command byte to be 0x6B. 

Just as a quick test, would you be able to put the device into the 1-byte, 8-bit read mode? The calculation for this mode is the same as the 16-bit mode, just with less bits. This way we can hopefully narrow down what may be going on.

Also do you happen to have another A2 variant on hand that you can try this out on to see if it also experiences this behavior?

Best,

~Alicia

Hi Alicia. Thank you for the quick response. In reply:

For the command byte, if the 8-bit I2C address is 0x6B, then I would also expect the command byte to be 0x6B. 

Agreed; that was what I tried initially, but it didn't work.

Just as a quick test, would you be able to put the device into the 1-byte, 8-bit read mode? The calculation for this mode is the same as the 16-bit mode, just with less bits. This way we can hopefully narrow down what may be going on.

I tried that, with the same outcome for both:

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

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

As before, 0xBC works with A, and 0x45 works with B.

Also do you happen to have another A2 variant on hand that you can try this out on to see if it also experiences this behavior?

I don't, but a colleague might; will respond another time.

Some more results:

I enabled the temperature sensor for both chips, keeping other settings the same - including the CRC calculation. This too works fine.

As an experiment, for the data used in CRC calculation, I once again changed byte 0 of sensor A to 0x6B; and as before, the CRC calculation failed every time.

I got a colleague to run the working code on their device (with and without the temperature sensors enabled), and they saw no CRC faults.

Any ideas? Do you have an A2 sensor you could try this on (or a simulation thereof)?

Steve,

Alicia is out of office today, and should be back tomorrow.  

thanks,

Scott

Hi Steve,

Steve Melnikoff said:

I got a colleague to run the working code on their device (with and without the temperature sensors enabled), and they saw no CRC faults.

To clarify, with the device that your colleague had, were they able to calculate the CRC using the expected 0x6B value or did they also have to use the 0xBC value?

Are you able to share the your register settings so that I can use try this out on a TMAG5273A2 EVM that I have?

Also, something else that I would be curious about is what the results would be if you were to use the I2C_Address register of the device to change the I2C address and see if you are able to get the expected CRC results with the new I2C address.

Best,

~Alicia

Hi Alicia. Thank you for your reply.

To clarify, with the device that your colleague had, were they able to calculate the CRC using the expected 0x6B value or did they also have to use the 0xBC value?

Sorry: they were using exactly the same code as me, which used 0xBC.

Are you able to share the your register settings so that I can use try this out on a TMAG5273A2 EVM that I have?

Using our own #defines, which are hopefully self-explanatory:

  {REG_CONV_STATUS,     REG_CONV_STATUS_POWER_ON_RESET}, // Clear POR by writing 1 to it.
  {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_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},

Incidentally, because we're using the 32x averaging, which takes a little time, we send a message with the conversion trigger set, consisting of a dummy write to CONV_STATUS: 0x98 0x00. We then delay for 3-4 ms, then read the result. This has proven to be very reliable.

Also, something else that I would be curious about is what the results would be if you were to use the I2C_Address register of the device to change the I2C address and see if you are able to get the expected CRC results with the new I2C address.

I'll try that and report back.

So I changed the address of sensor A to a couple of different values, and used the same CRC-related code as before to find what value of byte 0 was required to get the correct CRC:

So the behaviour is consistently unexpected!

<Actual byte> = <expected byte> XOR 0xD7

Where did the 0xD7 come from?

Hi Steve,

Do happen to know the REV of the TMAG5273A2 device that you are currently working with? It should be listed on the label of the bag/box that it came in (if you still have it).

When you read back the data with CRC, is it the case that after every conversion, 0xBC needs to be used or does it change?

For example, if you were to do the following sequence upon powering up the device:

1. Configure device (as normal)
2. Trigger conversion and wait for it to complete
3. Read back data + CRC
4. Trigger another conversion and wait for it to complete
5. Read back data + CRC
   1. Is it the case that 0xBC works in place of the command bite, or does it change?
6. Repeat steps 4-5 a few times

Best,

~Alicia

Hi Alicia.

Alicia Rosenberger said:

When you read back the data with CRC, is it the case that after every conversion, 0xBC needs to be used or does it change?

It's always 0xBC (and likewise, when I tried the other addresses in the table above, the actual byte 0 was similarly constant).

Alicia Rosenberger said:

Is it the case that 0xBC works in place of the command bite, or does it change?

It's constant. Here are the relevant bits of code, updated with the findings from above:

// 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;

Alicia Rosenberger said:

Do happen to know the REV of the TMAG5273A2 device that you are currently working with?

I will check.

Thanks,

Steve.

Alicia Rosenberger said:

Do happen to know the REV of the TMAG5273A2 device that you are currently working with? It should be listed on the label of the bag/box that it came in (if you still have it).

No, it doesn't appear so. We're using these chips on PCBs we had built, and the company that built the PCBs bought the parts.

Hi Steve,

I was able to try this out with an A2 that I had on hand (using the same register settings as you), however, for the CRC calculation, I was able to get what the device was reporting out using the expected 0x6B.

Additionally, I ended up ordering some new TMAG5273A2 devices to see if I can observe the issue with one of them. Once they get delivered, I will let you know what results that I get.

Could you share an image of the date code on top of the device package?

Best,

~Alicia

Here's a photo:

Hi Steve,

Thank you for the image of the device. I plan on using it to determine when the device was made to see if we can pinpoint why the command byte isn't what it is expected to be for the A2 variant.

Best,

~Alicia

Hi Steve,

Apologies for the delayed response, but I was able to finally get samples in that should be the same revision as the A2 devices that you have. Unfortunately, I was not able to reproduce the issue that you are seeing, where 0xD7 needs to be XOR'd to the command byte in order to calculate the CRC that the device reports out. With the A2 devices that I have, I was able to correctly calculate the CRC with 0x6B being the command byte.

Do you happen to know who your TI FAE is? If so, would you mind reaching out to them about starting an FA analysis of one of the A2 devices where the command byte isn't as expected so we can try to further analysis what may be going on with the device?

Best,

~Alicia