• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 48 subscribers
  • Views 682 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

PGA309 Internal temperature not reading consistently

Douglas Dieruff
Prodigy 30 points
Other Parts Discussed in Thread: PGA309, PGA309EVM-USB

I'm using a Multi-Cal setup to communicate with a PGA309.  In the Fast Scan portion of the code, before the EEPROM verify, I've added the mnemonic commands to set up register 6 for internal temperature measurements and then read the temperature from register 0.  Occasionally I get an invalid value back from register 0.

The command sequence is ONE 0x55 0x01 0x06, ONE 0x55 0x04 0x03 0x12, ONE 0x55 0x01 0x00, ONE 0x55 0x10 R R.  I have a 100mS delay between the register 6 write and the setting of the address for the read.  I have found that if I repeat the sequence twice in a row, the second time I always get a good temperature reading.

For example I've read back 201B, 014B; 1A5B, 014B; 014A, 014A.  The first read is sometimes an invalid value.  I can detect this in software and retry, but would like to understand why it's happening.  Has any one run into something similar?

Thanks!

  • 0
    TI__Expert 4420 points

    Douglas, PGA309 is supported by the Precision Amplifiers group, I am moving your post to that forum.Thanks,

    JV

  • 0
    TI__Mastermind 27715 points

    Hello Douglas,

    The PGA309 may not have powered on fully and completed an internal temperature ADC conversion by the time you send the first command. Please refer to Figure 3-1 in the PGA309 User's Guide, also copied below. Most notably, there is a 33ms delay after the part checks for valid power and a 125ms delay for a 16-bit temperature conversion to complete. You may have more consistent initial reads if you increase your delay time slightly.

    Best regards,

    Ian Williams
    Linear Applications Engineer
    Precision Analog - Op Amps

  • 0 in reply to Ian Williams
    Prodigy 30 points

    The PGA309 has been powered for many seconds before I read the temperature.

    In internal temperature mode the PGA309 User's Guide shows a 24mS conversion time, which is why I used 100mS, just to have some cushion.

    Interestingly, if I do two initiate/read cycles in a row (100mS delay between cycles) I always get a good temperature reading the second time.

    If I do the double transaction and wait a few seconds then try again, the first read always returns an invalid temperature value.

  • 0 in reply to Douglas Dieruff
    TI__Mastermind 27715 points

    Hello Douglas,

    If you're using the Multi Cal system, the PGA309 itself may have not been powered on for many seconds. The normal Fast Scan procedure applies power to each channel one at a time before performing the EEPROM read/write. Even though your analog supply may have been up for several seconds, power is being programatically applied to each PGA309 module.

    Best regards,

    Ian Williams

  • 0 in reply to Ian Williams
    Prodigy 30 points
    Ian,

    I'm using only the DAQ board from the Multi-Cal kit, only for the one-wire communication. J3 pin 11 is routed through a relay mux to the UUTs.
    The UUTs containing the PGA309 are constantly powered. I only have two UUTs right now, but they both are behaving the same way.

    Thanks,

    Doug
  • 0 in reply to Douglas Dieruff
    TI__Mastermind 27715 points
    Hello Doug,

    Thank you for clarifying your setup.

    Checking the code of the Multi-Cal and PGA309EVM-USB software, there are no additional delays given when issuing a read command. For reading from register 0x00, the commands are "ONE 0x55 0x01 0x00" followed by "ONE 0x55 0x10 R R," the same as in your sequence.
    However, our software waits for error-checking to complete on the first transaction before issuing the second, adding some delay.

    Does a similar issue happen with other registers? An interesting test would be to read the Temp ADC configuration register after you've written it. Does it match the expected value every time? If not, the issue is likely related to general SPI timing. If so, then the issue is likely to be something more specifically related to the temp ADC conversion.

    Best regards,

    Ian Williams