• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 79 subscribers
  • Views 1268 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.

LMP90100 ADC unstable readings

Elias Fasuolo
Prodigy 30 points
Other Parts Discussed in Thread: MSP430F249, LMP90100

Hi,

  I've recently started to interact between a LMP90100 and a MSP430F249, using the library and demos provided in the file snac006.zip. I'm using a custom board in which the communication port with the AFE is the UCB1 module.

  The configuration stage is done without problem, and the readout of the config register is also OK. The values and configuration procedure is as follow:

 

  1. TI_LMP90100_RESETCN_REG = 0xC3 (fixed value)

  2. TI_LMP90100_SPI_HANDSHAKECN_REG = 0x00 ()

  3. TI_LMP90100_SPI_DRDYBCN_REG = 0x83 (D6 = drdyb signal)

  4. TI_LMP90100_ADC_RESTART_REG = 0x01 (just in case)

  5. TI_LMP90100_SPI_CRC_CN_REG = 0x14 (enable CRC, Bit 3 must be 0, DRDYB is deasserted after CRC is read)

  6. TI_LMP90100_ADC_DONE_REG = 0xFF (set ADC not done)

  7. while(TI_LMP90100_SPIReadReg((TI_LMP90100_CH_STS_REG & TI_LMP90100_CH_SCAN_NRDY), prevURA)); // wait if CH_SCAN_NRDY

  8. TI_LMP90100_CH_SCAN_REG = 0x1B (ScanMode0: Single-Channel Continuous Conversion, firt and last ch = CH3 for vin6 and vin7)

  9. TI_LMP90100_CH3_CONFIG_REG = 0x20 (6.71 SPS and buffer included in the signal path)

  10. TI_LMP90100_CH3_INPUTCN_REG = 0x37 (VINP: 0x6, VIN7: 0x7)

  You can see in the figure that the config verification in done correctly:

 

 

  The thing is that during the ADC_OUT readings, the behaviour is completly unexpected to me. Basically, the reading sequence is as follow:

  1. Check TI_LMP90100_ADC_DONE_REG != 0xFF

  2. if TRUE, read ADC_OUT + CRC_DATA with:

  TI_LMP90100_SPINormalStreamReadADC(TI_LMP90100_ADC_DONE_REG, (uint8_t *)dataADC, 4, &prevURA);

  3. back to 1

  What I see is that whenever I try to read the ADC_OUT register I get 3 different voltage levels at the SDO/DRDYB pin, as you can see below:

  My question is if this behaviour is due to a configuration issue that I might be missing, since I could't find any reference in the documentatin nor in the forum that addresses this issue.

  I appreciate wny suggestion or information regarding this problem.

  Thanks in advance,

  Elias

  • 0
    Guru 22270 points

    Hello Elias,

    Welcome to the Forum!

    You have done a great job at detailing what you have observed.  I'm sure it will be valuable to others.

    The one thing I am not entirely clear on is this: You have mentioned just about everything execpt whether or not you are getting a valid reading.  if you set you input voltage to a value below the Vref, do you get the correct reading?

    Perhaps I missed it in your explanation.

    Thanks,

  • 0 in reply to Greenja
    Prodigy 30 points

    Hi greenja,

      Thanks for your comments. With respect to the readings, I couldn't get valid readings once I started the reading loop, the only valid values were the ones read during the configuration stage.

    Then, in my case I'm having a 2.048 V Vref with an input voltage fixed to 0.3 V.

      Hope it helps to get a better idea to what the problem might be.

      Thanks.

  • 0
    Guru 227245 points

    Elias Fasuolo said:
    I get 3 different voltage levels at the SDO/DRDYB pin

    Seeing mroe than two logical levels on a digital data line usually indicates a hardware problem. Like two outputs fighting each other, so the resulting voltage is 0, ~0.5 or 1, depending on the state of the two output bits. Or different supply levels (and therefore logic levels).

    I don't know the software nor do I know the LPM, so this rather generic hint is allI can provide.

  • 0 in reply to Jens-Michael Gross
    Prodigy 30 points

    Actually, I'm considering that possibility, since I'm working with a custom made hardware which might have a hidden error as a cause of this behaviour. I was also thinking of an unstable HiZ state during the reading at the SDO pin, but haven't find anything conclusive yet.

    Thanks for your time and answer.

**Attention** This is a public forum