• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 29 subscribers
  • Views 201 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: TRIM_STAT Causes

Joel Brunetti
Prodigy 10 points
Part Number: TMAG5170

I have an application where I'm sampling many TMAG5170 sensors at a relatively high rate and I am very occasionally finding that the TRIM_STAT bit is being set and then cleared.

My test setup:

- 72 TMAG5170 sensors on 3 separate boards each with an FPGA.

- Conversion started by pulsing nCS low.

- Conversion read after nALERT goes low.

- Sampled at approx 1200 Hz for 5 minutes for approximately 364,000 samples.

In the above sample set,  over 3 consecutive samples, I detected that the ERROR_STAT and one of the ALERT_STATUS bits was set 186 times.

All other samples are as expected.

I was able to return the AFE_STATUS and SYS_STATUS registers for a third of the sensors (limited due to FPGA resource constraints) read after the sample was read and before the next sample and in every case the ALRT_LVL and TRIM_STAT bits are set.

The ALRT_LVL bit is as expected and I do not believe it would cause the ERROR_STAT or an ALERT_STATUS bit to be set.

The TRIM_STAT bit does concern me though.

These results are not unique to my setup. The same problem (to a lesser extent) has been observed with different hardware (of the same design) by another team in a different location.

What could cause a memory CRC error? Why would that error be transient? I do not power cycle the sensors but the error recovers. What could cause the same error at approximately the same time over 72 sensors across 3 boards?

My initial thought was a power dip maybe caused by the inrush of many sensors changing operating mode but the LDO_STAT bit is not being set and the input power dips by only 24 mV to 3.239 mV as measured by my scope.

Thanks,

Joel

  • 0
    Prodigy 10 points

    Sorry, I was looking at the wrong scope measurement. The peak to peak voltage for the sensors should be 37 mV with a minimum of 2.491 V.

  • 0 in reply to Joel Brunetti
    TI__Genius 15340 points

    Joel,

    Thanks for reaching out on E2E.  This sounds like a very interesting setup.  Are you able to provide any details regarding such a large array of sensors and the measurements you are trying to capture?  

    I will discuss with our team to see if I can find out more details what might cause this particular scenario.  Based on your description, the Vcc voltage does remain above the minimum recommended operating voltage (2.3V).

    Are you using the CRC for SPI communication and checking all transmit data from TMAG5170?  If not, do you think it possible that there might be an error during the read?  It would be suspicious if the error always occurred at the same bit.  

    Can you provide details about your input conditions, register settings, and SPI clock rate?

    Thanks,

    Scott

  • 0 in reply to Scott Bryson
    Prodigy 10 points

    Hey Scott,

    I can provide almost any details. Each of the boards in my above uses an array of 3 x 8 TMAG5170 sensors. I'm measuring all 3 components of the field with each conversion. This is accomplished with an FPGA with 24 separate SPI controllers each operating independently at 10 MHz.

    I am not checking the CRC and have disabled it in my configuration routine.

    My configuration routine is as follows:

    Register Offset Value Command
    TEST_CONFIG 0xF 0b0000000000_00_0_1_00 = 0x0004 0x0F000407
    SENSOR_CONFIG 0x1 0b00_0000_0111_10_10_10 = 0x01EA 0x0101EA00
    SYSTEM_CONFIG 0x2 0b00_00_0_01_000_0_00_0_0_0 = 0x0200 0x02020000
    ALERT_CONFIG 0x3 0b00_1_0_0_00_1_00_00_0_0_0_0 = 0x2100 0x03210000
    AFE_STATUS 0xD 0x0 0x8D000000
    SYS_STATUS 0xE 0x0 0x8E000000

    No other registers are written.

    I then read the following results registers:

    Register Offset Command
    X_CH_RESULT 0x9 0x89000000
    Y_CH_RESULT 0xA 0x8A000000
    Z_CH_RESULT 0xB 0x8B000000

    If the ERROR_STAT or ALERT_STATUS bits are set during any of the 3 previous reads, I resend the configuration routine which also clears the AFE_STATUS and SYS_STATUS registers.

    For some sensors, I read the AFE_STATUS and SYS_STATUS register values before resending the configuration.

    While I can't rule it out, it would be highly unlikely to be an SPI communication problem but I will explain my setup and am interested in your judgement.

    Of my 364,000 samples, I've included 3 in the table below.

    This table does not show the magnetic data though, it shows the last 4 bits of the sample. Normally, these would be 0 but I decided to stuff some diagnostic data in those bits.

    Least significant nibbles:

    • 0x8 - Status Results - Preceding bits are not magnetic data but TMAG5170 status registers.
    • 0x4 - ERROR_STAT.
    • 0x2 - ALRT_STATUS logically ORd.
    • 0x1 - If set, data not from current conversion.

    Note, the NaN is an artifact of my filtering process. These should be read as 0.

    There should be:

    - 0x8 total of 57

    - 0x6 total of 129

      sensor 1 2 3 9 11 12 15 19 22 26 27 28 30 31 33 34 36 40 41 42 44 45 47 48 49 51 54 55 56 57 59 61 63 66 67 68 69 70 72
    sample axis                                                                              
    65436 a NaN 6 6 6 6 NaN NaN NaN NaN 6 6 8 6 8 NaN 8 6 NaN NaN NaN 6 NaN NaN 6 NaN 6 NaN 8 6 6 NaN NaN 6 6 8 6 6 8 6
    c 8 6 6 6 6 NaN NaN NaN NaN 6 6 8 6 8 NaN 8 6 NaN NaN NaN 6 NaN NaN 6 NaN 6 NaN 8 6 6 NaN NaN 6 6 8 6 6 8 6
    r 8 6 6 6 6 NaN NaN NaN NaN 6 6 8 6 8 NaN 8 6 NaN NaN NaN 6 NaN NaN 6 NaN 6 NaN 8 6 6 NaN NaN 6 6 8 6 6 8 6
    65437 a 8 6 6 6 6 6 6 8 8 6 6 8 6 8 6 8 NaN 8 6 6 6 6 6 6 NaN 6 6 8 6 6 6 8 6 6 8 6 6 8 NaN
    c 8 6 6 6 6 6 6 8 8 6 6 8 6 8 6 8 NaN 8 6 6 6 6 6 6 8 6 6 8 6 6 6 8 6 6 8 6 6 8 NaN
    r 8 6 6 6 6 6 6 8 8 6 6 8 6 8 6 8 NaN 8 6 6 6 6 6 6 8 6 6 8 6 6 6 8 6 6 8 6 6 8 NaN
    65438 a 8 NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN 8 NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN

    For some of my sensors, if ERROR_STAT or ALRT_STATUS is set, it clears those flags and sets 0x8 in the least significant nibble. It then over-writes the magnetic data with the AFE_STATUS and SYS_STATUS register values.

    So the 0x6 and 0x8 flags are essentially the same (an 0x8 could also be caused by an 0x2 or 0x4 but I've not ever seen that, from the Datasheet, it isn't clear when ERROR_STAT would be set but ALERT_STATUS would not be and vice versa).

    For all 0x8 though, I have the register values reported. Over 3 separate boards, the only bits set are ALRT_LVL and TRIM_STAT and only those.

    Thoughts? Questions?

    Thanks for the quick reply,

    Joel

  • 0 in reply to Joel Brunetti
    TI__Genius 15340 points

    Joel,

    To me, the odds of a sporadic SPI communication event that always happens on the same bits is pretty minimal.  I threw it out as a possible place to look to debug if nothing else made sense.

    The TRIM_STAT bit gets set when the device detects an internal CRC error while loading the needed trim settings.  Of these, two are only loaded at power up, but the remaining sections are loaded for the X,Y,Z channels at the start of the respective conversion.  

    Discussing with the team, the most likely event that could cause the device to not load these settings correctly would be a power dip.  You mentioned that you did measure the lowest power voltage to be 2.239 V which is comfortably within the operating range of the sensor.  Is this voltage probed at every device? Near the bulk capacitance for the supply?  I'm not sure how you have these all connected, powered, and triggered, but if every device shared the 3.3V supply and were triggered simultaneously, then it might be conceivable to have a larger supply dip at the VCC pin of the device than is observed at the source.  Is it possible to repeat the test while monitoring the voltage of a device that produced the error flag?

    Thanks,

    Scott