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.

PGA970: PGA970 SPI data transfer consistency

Part Number: PGA970

Dear TI Team, 

We have used the PGA970 in some of our projects. Following reports from end customers, we have noticed issues with the consistency of the data provided by the PGA970.

In general, we use this component to read LVDT sensors without any further processing. Therefore, the ARM is turned off, and data transfer occurs only via SPI (configured at approximately 900 kHz). Our analysis revealed that the demodulation registers (32 bits wide) read via SPI are corrupted by the PGA970 itself. Specifically, reading the entire register requires two 16-bit SPI requests. Apparently, the PGA lacks a mechanism to prevent these registers from being updated during the read operation. Therefore, when reading a 32-bit register, the first 16 bits (MSB) belong to the first sample, while the second 16 bits belong to the next sample. This issue is most evident when the value straddles the 16-bit boundary (as a raw numerical position). For example (for a generic demodulation register), given two consecutive samples as follows:

0x0000 FFEA
0x0001 0023

sometimes the SPI read result is:

0x0001 FFEA 
or 
0x0000 0023


As seen in the example, the two acquisitions made by the PGA970 may, at the SPI transfer level, be mixed in certain cases, corrupting the final data.

 

Since these issues were identified in a safety-critical project (under DO-178C), I need to provide definitive documentation to submit to the certifying authority (EASA). Is it possible to obtain an “errata” document or an official document confirming this behavior (with a tracking number)?

 

Thanks in advance.
DS

  • Hi Davide Scarabattoli,

    Let me look into this and get back to you

    Note that we typically don't issue errata for ADCs, especially in the case where a specific behavior is just not fully described in a datasheet i.e. the device is operating as intended

    -Bryan

  • Hi Davide Scarabattoli,

    We can most likely empirically document that this behavior occurs in an app brief or something similar. This would take some time however as this is one of many competing priorities. Let me know if you have any feedback about this proposal

    -Bryan

  • Hi Bryan,

    I found another forum discussing the same issue.So I assume that the SPI communication issue has already been investigated by TI.

    pga970: data consistency of demod-result-registers while SPI-transfer

    As for your proposal, it works for us. I understand that the timeline is long, but we need to be certain about certain considerations that have been made to date.
    For now, we have found a possible solution that we are testing. However, to complete the software certification, we need documentation from the device manufacturer, Texas Instruments.

    I look forward to your feedback.
    Thank you

  • Hi Davide, 

    Can you please confirm a couple of details about your setup? 

    I see that you have the ARM turned off (that is, the device is in reset mode, not compensation mode). What data are you attempting to read? Are you only attempting to read demodulation data or are you attempting to read phase data as well? Additionally, are you trying to read data from one demodulator or both demodulators? What is the demodulator output rate you're using?

    Thanks,

    Maggie

  • Hi Maggie,

    Yes, I confirm that the ARM is in reset mode.

    I'm attempting to read only the demodulator data, from both the 2 demodulators (both show the corrupted behaviour).

    the output rate of the demodulator registers is set to 128us.

    DS

  • Hi Davide, 

    Thank you for the confirmation. Please give us some time to collect data and generate a document.

    Best,

    Maggie