• State TI Thinks Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 283 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMAG5170-Q1: TMAG5170-Q1

Rajath Rao
Prodigy 10 points
Part Number: TMAG5170-Q1

Hi,

I am Trying to use the TMAG5170-Q1 Hall sensor with a Cypress Microcontroller, I am Facing a issue while reading the data across the SPI lines

Reading 84 0000 0E where E is the CRC calculated as per the datasheet. The data output expected is 00 7D83 00 but I am reading E0 0000 8B

Which I understand  there is PRE_CRC_STAT, ALRT_STATUS1 and CFG_RESET bits set to high, As per the calculations and several debugging 

I assume there is no error wrt CRC bits, Is there any key aspects that I am missing to employ or to lookout for ?

The CRC calculator that is being used here is as below:

char *MakeCRC(char *BitString)
{
static char Res[5]; // CRC Result
char CRC[4];
int i;
char DoInvert;


for (i=0; i<4; ++i) CRC[i] = 1; // Init before calculation

for (i=0; i<strlen(BitString); ++i)
{
DoInvert = ('1'==BitString[i]) ^ CRC[3]; // XOR required?

CRC[3] = CRC[2];
CRC[2] = CRC[1];
CRC[1] = CRC[0] ^ DoInvert;
CRC[0] = DoInvert;
}

for (i=0; i<4; ++i) Res[3-i] = CRC[i] ? '1' : '0'; // Convert binary to ASCII
Res[4] = 0; // Set string terminator

return(Res);
}

 Please Guide me through this.

  • 0
    TI__Genius 15290 points

    Rajath,

    Thank you for reaching out with your question.  Please make sure you parse the entire 32 bits when running your CRC calculation.  The transmitted BitString should have the LSBs set to 0b0000.  After completing the calculation, these bits should then be replaced with the calculated CRC values.  When I check the codes for your expected output I am getting a result of 00 7D83 03.

    Bit INPUT Code CRC3 CRC2 CRC1 CRC0
    1 0 1 1 0 1
    2 0 1 0 0 1
    3 0 0 0 0 1
    4 0 0 0 1 0
    5 0 0 1 0 0
    6 0 1 0 0 0
    7 0 0 0 1 1
    8 0 0 1 1 0
    9 0 1 1 0 0
    10 1 1 0 0 0
    11 1 0 0 0 0
    12 1 0 0 1 1
    13 1 0 1 0 1
    14 1 1 0 0 1
    15 0 0 0 0 1
    16 1 0 0 0 1
    17 1 0 0 0 1
    18 0 0 0 1 0
    19 0 0 1 0 0
    20 0 1 0 0 0
    21 0 0 0 1 1
    22 0 0 1 1 0
    23 1 1 1 1 1
    24 1 1 1 1 0
    25 0 1 1 1 1
    26 0 1 1 0 1
    27 0 1 0 0 1
    28 0 0 0 0 1
    29 0 0 0 1 0
    30 0 0 1 0 0
    31 0 1 0 0 0
    32 0 0 0 1 1
    x007D 8303

    In the above example bit 1 is the MSB to match the timing diagram shown in the datasheet.  The second column "Input Code" would be equivalent to BitString in your code. Notice that bits 29-32 are set to '0'. The CRC columns are calculated iteratively using the following code:

    For i = 1 To 32
    CalcBit = Worksheets("Iterative Routine").Cells(i + 1, 2).Value
    inv = CalcBit Xor crc_val(3)
    crc_val(3) = crc_val(2)
    crc_val(2) = crc_val(1)
    crc_val(1) = crc_val(0) Xor inv
    crc_val(0) = inv

    After the 32 iterations are complete, the final CRC bits are 0b0011 and these then are concatenated to the preceding 28 bits.

    If you are reading a CRC error from the previous transaction, then this indicates a CRC error in the transmitted command to the device.  Any write you have performed will not be latched into the device registers when this occurs.  You should also observe that the LSB will invert during the read of the same word a Tx CRC error occurs.  In this case, I would calculate a read value of xE0 0000 8A, but instead you are capturing a 'B' because of this indicator.  When CRC errors occur, the device assumes a data corruption and will not recognize the command as valid.  You can verify your read/writes and SPI timing are correct by writing x0F000407 as your first transaction.  After this the device will not require the CRC bits to be correct, and you should be able to confirm there are no timing issues.  You are free to disable it permanently as you see fit, but this feature does help improve system robustness and diagnostics.

    Thanks,

    Scott

  • 0 in reply to Scott Bryson
    Prodigy 10 points

    Hi Scott, 

    Thank you for time, I tried Disabling CRC as you suggested by performing a write of 0x0F000407 on the very first Transaction, but I see no change in the data read, it as same as before i.e E0 0000 8B, And yes I checked the CRC of (00 7D83 00) which constitutes 3 by using the same CRC algorithm as mentioned earlier. After CRC disable do I need to take care of anything else on the communication part ? 

    Thanks and Regards

    Rajath R Rao

  • 0 in reply to Rajath Rao
    TI__Genius 15290 points

    Rajath,

    If you are receiving E0 0000 8B on the second transaction, this would suggest you have an error in your data logic or timing.  There should be no error bits if the CRC disable command is received correctly.  I would recommend that you connect to a scope to ensure that the first communication matches your expectation.  

    Thanks,

    Scott