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: Hall sensor Sleep Operating Mode

Part Number: TMAG5170

Hi,

We’re currently developing a system using the TMAG5170 Hall sensor chips.

 

We’re looking at our options for refinements , in this case decreasing our current draws.

Our application requires reading these hall sensors at a range of frequencies between 100Hz and 1000Hz.

We have the system working with the operating mode set to 4 – that is wakeup and sleep , where it runs automatically at either 200Hz , or 1000Hz with the settings below:

//                              [reg num][byte num]

static uint8_t TMAG_INIT_SETTINGS_BUFF[4][4] =

{

                {0x0F,0x00,0x04,0x07},   //de-activate CRC , bytes 0-4

                {0x00,0x31,0x40,0x00},   //write to register 0 of the TMAG sensors

                {0x01,0x04,0x95,0x00},   //write to register 1 of the TMAG sensors

                {0x02,0x00,0x00,0x00}    //write to register 2 of the TMAG sensors

};

//              address,hi,lo,misc

However, when we try to use sleep mode, (switching register 0 from 0x3140 to 0x3150), this causes the data sent back to be only 0’s, as shown by the below trace.

We’ve tried sending 0x10 in the final byte (as shown by the above trace) to have “CMD0=1”.

We’ve tried changing the TRIGGER_MODE (bit 10-9 of register 0x02) from 0h to 1h to activate read on chip select.

We’ve tried slowing down the frequency with which we request data down to 1Hz , in order to rule out a timing issue.

Does anyone have any guidance on how we could get the sleep mode to work properly?

  • Daniel,

    It looks like STAT3 bit is high here.  This is the ERROR_STAT bit.  It would be good if you could attempt a read back from the status registers (AFE_STATUS, SYS_STATUS) to see what the device is reporting.

    Thanks,

    Scott

  • Hi Scott,

    Thanks for the quick reply.

    I've just added some debug code to the initialisation function of the TMAG chip , so that it does a read of every buffer of every TMAG sensor after initialisation , and here is what I have got from it.

    Buffer Num 00 = 40_31_50_0B
    Buffer Num 01 = 40_04_95_06
    Buffer Num 02 = 40_00_00_0A
    Buffer Num 03 = 40_00_00_0A
    Buffer Num 04 = 40_7D_83_00
    Buffer Num 05 = 40_7D_83_00
    Buffer Num 06 = 40_7D_83_00
    Buffer Num 07 = 40_67_32_09
    Buffer Num 08 = 40_00_00_0A
    Buffer Num 09 = 40_00_00_0A
    Buffer Num 0A = 40_00_00_0A
    Buffer Num 0B = 40_00_00_0A
    Buffer Num 0C = 40_00_00_0A
    Buffer Num 0D = 40_80_00_05
    Buffer Num 0E = 00_06_00_0E
    Buffer Num 0F = 00_00_44_08
    Buffer Num 10 = 00_00_00_09
    Buffer Num 11 = 00_00_00_09
    Buffer Num 12 = 00_00_00_09
    Buffer Num 13 = 00_00_00_09

    Where the 4 pairs of digits for each buffer number are the 4 bytes that are sent on the MISO line by the TMAG sensor

    the first pair is the status phase , the 2nd and third pair are the data phase , and the last pair being the command/status phase and the CRC (which is disabled) .

    Having had a look at AFE_STATUS (register 0x0D) i can see from the reading (0x8000) , that the only bit set is CFG_RESET

    from looking at the SYS_STATUS(register 0x0E) , I can see from the reading (0x0600) , that 2 bits are set in this register.

    bits 9 and 10 , which indicate that OPERATING_STAT is set to 6h (sleep state)

    I can also see that the CFG_RESET bit is getting cleared properly by the read of 0x0D , as the first byte of the transmission changes from 0x40 to 0x00 after 0x0D was read. 

    If there are any other tests that you would like me to do for diagnostics , just ask.

  • Daniel,

    I've tried to recreate your setup using the EVM by making the same register writes that you indicated in your first post.  When I capture data I get the following plot:

    This looks pretty close to expectation.  With the device configured for 8x conversion time, the conversion cycle will take about 225 us (50 us + 7*25us).  The wake up time before the conversion can start is about 140 us to wake up and start a conversion.  Our expected total time then from conversion to conversion is:

    5 ms (sleep) + 140 us (initialize) + 225 us (convert)  = 5.365 ms.

    With the sensor being sampled every 50 us, then we should typically see about 108 samples captured every conversion, which is close to what was observed.

    The question still stands, however, why you are not getting data back during the reads. Looking through your register reads, I see in the first read back that you have 0x3150 in register 0x00.  Here the OPERATING_MODE is 0b101 (Sleep Mode).  This is just standard sleep, and the device will not wake for a conversion in this mode.  Based on your previous commands, I had expected to see 0x3140 here, which would put the part into wake & sleep mode at the set interval.  Check to make sure that there's not another write changing this setting or perhaps check to make sure that the SPI communication looks clean.  For reference, I ran the capture again, but with 0x3150:

    Here I got a matching result with no data change on the Y output.

    Thanks,

    Scott

    Scott

  • Hi Scott,

    Thanks for the reply,

    We had previously been doing testing with 0x3140 in register 0x00

    We have tried to switch to using 0x3150 in register 0x00

    It was our understanding that with 0x3150 , that the TMAG chip would take 1 reading per read of the buffer over SPI , triggered by the SPI read, so that unnecessary read events dont occur.

  • Daniel,

    When you send the sleep command at the same time as a SPI trigger event, the sleep will take priority, so the device will not start a conversion.  To setup for one-shot type conversions, you might use the ALERT pin to indicate the completion of a conversion.  Once the conversion completes, you could send the sleep command to re-enter a low current state.  I believe the device should retain the data from the last conversion, so you could read the SPI data at will afterwards. This does take an extra step to manually wake and then put the device to sleep, but you would have full control over the frequency of the conversion timing.

    Thanks,

    Scott