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.

ADS1262 ADC data is not proper

Other Parts Discussed in Thread: ADS1262, ADS1263

Hi ,

We are using Normal SPI3 of TMS570LS1224PGE (Launch pad board) controller for reading ADC data from ADS1262. The ADC commands like start, read, stop are used to control ADC functionalities instead of start and DRDY pins. For initial checking purpose internal power supply of ADC is used. we are able to read status and checksum ,however ADC values are not as expected. We are reading very less value instead of 1.25V for following configuration.

SPI3 Configuration:

1)      Master Mode

2)      Internal Clock – 1MHZ

3)      Baud Rate – 1MHZ

4)      No delay

5)      CS HOLD = TRUE

6)      SPI3

7)      8 bit mode

8)      Polling method

ADC configuration:

1)      POWER = 0x01;                                                   // VBIAS = OFF, INTREF = ON

2)      INTERFACE = 0x05;                                            // SERIAL TIMEOUT DISABLED, STATUS BYTE ENABLED, CHECKSUM ENABLED

3)      MODE0 = 0x44;                            // NORMAL REFERENCE POLARITY, PULSE CONVERSION, CHOP DISABLED, 69us ADDITIONAL DELAY

4)      MODE1 = 0x60;                                                   // SINC4 (NOT APPLICABLE FOR 38.4kSPS), SENSOR BIAS DISABLED

5)      MODE2 = 0x0F;                                                   // PGA ENABLED, PGA GAIN = 1, 38400 SPS

6)      INPMUX = 0xCC;                                                                // ANALOG POWER SUPPLY MONITOR (+), ANALOG POWER SUPPLY MONITOR (-)

7)      Other are Default values

8)      Command Mode

9)      START pin is grounded

Verification done:

 

1)      Configurations are verified by reading back configuration register from ADC.

2)      Start and Read commands transmit are verified using oscilloscope.

3)      Power to ADC is proper.

Steps:

1)      ADC configuration

2)      Send Start command

3)      Wait

4)      Send read command and read adc data.

5)      Send stop command

 

Queries:

1)      In command mode is there any special steps needs to be taken care?

2)      Is it required to wait for few cycles in between ADC read opcode and ADC data?

 

Please let us know if more information is required?

Looking forward to hear from you as early as possible.

 

Thanks in advance.

  • Hi Lokraj,

    Welcome to the TI E2E Forums!

     

    What data values do you read back when measuring the supply voltage?

    The output code should be around '40 00 00 00' (hex). It's usually  a good idea to check the raw ADC code (before this value is converted to a voltage) to ensure that the error is not in the conversion math....and even better yet... 

    Have you tried looking at the SPI communication on an oscilloscope to see if the data looks invalid on theSPI bus?
    This can really help you determine if your code and the MCU are doing what you expect and can reveal many other hidden issues, such as timing violations or signal integrity issues.

     

    How long do you wait for the conversion result?

    To answer your question:

    LOKRAJ PATRO said:
    2)      Is it required to wait for few cycles in between ADC read opcode and ADC data?

    You don't need to wait between the RDATA1 command and when you clock out data. However, you do need wait about 5 conversion cycle between the START1 command and the RDATA1 command when using the SINC5 filter, as this filter is performing an average on 5 conversion results.

    Regarding your first question:

    LOKRAJ PATRO said:
    1)      In command mode is there any special steps needs to be taken care?

    You shouldn't be running into any issues in pulse convert mode, so long as you've waited for the conversion to complete. You can confirm this by seeing if the status byte indicates that the data is a new conversion result.

     

    Best Regards,
    Chris

  • Hi Chris,

    First of all thanks a lot for quick response,

    Below are my response to your suggestions:

    What data values do you read back when measuring the supply voltage?

    I am receiving data “40 00 00 40 29 04” (hex) for INPMUX = 0xCC configuration i.e. ANALOG POWER SUPPLY MONITOR (+), ANALOG POWER SUPPLY MONITOR (-) but expected value should be equivalent count of 1.25V. (Correct me if i am wrong)
    Here 40 (1st byte) is status byte which means new ADC1 data is available.
    0x04 (last byte) is checksum of ADC data i.e. 00 + 00 + 40 + 29 + 9B (offset constant) = 104 .

    I tried reading configuration registers of ADC to check ADC configuration. While reading configuration register initially one extra byte is received, But ADC should send REG DATA immediately after OPCODE1 and OPCODE2
    as per Figure 121. Read Register Sequence of ADC data sheet.
    Received configuration data:
    00 01 05 44 60 0F CC 00 00 00 40 00 00 BB 00 00 00 00 00 00 00
    Here 1st 0x00 is extra byte and 01 is the power register......
    Is it expected behavior of ADC?


    Have you tried looking at the SPI communication on an oscilloscope to see if the data looks invalid on the SPI bus?

    The SPI communication is looking fine it seems, the SPI transmit data I can see in MOSI line and whatever data is there in MISO line is receiving by SPI.

    How long do you wait for the conversion result?
    I am waiting around 2 seconds for conversation results after sending Start command.

    Please let me know if i am doing anything incorrectly.

    Looking forward to hear from you



    Thanks & Regards,
    LOKRAJ
  • Hi Lokraj,

    I think the issue may be with your register configuration.

    LOKRAJ PATRO said:
    Received configuration data:
    00 01 05 44 60 0F CC 00 00 00 40 00 00 BB 00 00 00 00 00 00 00
    Here 1st 0x00 is extra byte and 01 is the power register......
    Is it expected behavior of ADC?

    Here the FSCAL[2:0] registers are set to "40 00 00", when they ought to be "00 00 40", since the first byte in this sequence corresponds to FSCAL0. With this setting, you are multiplying the ADC's output result by 0.00001526 V/V. Hence, 1.25V becomes 1.25V * 0.00001526 V/V = 0.0000768 V (which corresponds with the data bytes you're reading: "00 00 40 29"). If you set the FSCAL registers back to it default settings, you should see an output result much closer to 1.25 V.

    Regarding the extra "00" byte, keep in mind that the "RREG" command requires two bytes: <RREG + Addr> <Number of registers>; therefore, data doesn't appear until the third byte. Perhaps, the "00" is the output byte while you're still sending the <Number of registers> byte?

    Best Regards,
    Chris

  • Hi Chris,
    Thanks for information.

    You are absolutely right, the issue with the FSCAL[2:0] configuration registers write. As you said I was writing “40 00 00” instead of "00 00 40”. Now I am able to read 1.253V after writing default vales to FSCAL[2:0] register.

    Chris:
    With this setting, you are multiplying the ADC's output result by 0.00001526 V/V. Hence, 1.25V becomes 1.25V * 0.00001526 V/V = 0.0000768 V (which corresponds with the data bytes you're reading: "00 00 40 29").

    However I would like to understand calculation behind to get 0.00001526 V/V multiplication factor for FSCAL[2:0] configuration 00 00 40 (as per your earlier comments.)

    Chris:
    Regarding the extra "00" byte, keep in mind that the "RREG" command requires two bytes: <RREG + Addr> <Number of registers>; therefore, data doesn't appear until the third byte. Perhaps, the "00" is the output byte while you're still sending the <Number of registers> byte?

    I am sending <0x21> and <0x13> , which means from power register 20 configuration bytes are interested to read .
    Below are complete write and read packet :

    Sending: 21 13
    Receiving: 00 00 00 01 05 44 60 0F CC 00 00 00 00 00 40 BB 00 00 00 00 00 00 00

    Here first two zeros are received during transition of <RREG + Addr> and <Number of registers> (which is expected ), however 3 zero is extra byte received and sometimes some garbage value also is received at 3r byte instead of zero . But 4th byte on wards proper configuration data is received every time.

    IS ADC required one extra Clock cycle to process the received command before transmitting data?
    if yes then I will ignore 1st byte . Similar behavior is observed for ADC data read also. The ADC sends valid data after 1st byte.

    Below ADC data is read for INPMUX = 0xCC configuration:
    “40 40 40 2A 82 31 B8 “ here 1st 40 is extra byte which ADC sends after that valid 6 bytes.
    40 : (2nd byte) status byte new ADC1 data is available
    40 2A 82 31 : is ADC data which is equivalent to 1.253V
    B8 : is checksum.

    Thanks for your support which helps a lot.

    Thanks & Regards,
    Lokraj
  • Hi Lokraj,

    You're welcome!

    FYI: There is an Excel Calculator that can help with with these calculations, located here:  

    LOKRAJ PATRO said:
    However I would like to understand calculation behind to get 0.00001526 V/V multiplication factor for FSCAL[2:0] configuration 00 00 40 (as per your earlier comments.)

    The ADS1263 takes the 24-bit word in the FSCAL[2:0] registers and divides it by 400000h.

    Therefore, if FSCAL[2:0] = 400000h, then 400000h/400000h = 1 V/V.

    Or if FSCAL[2:0] = 800000h, then 800000h/400000h = 2 V/V; however, in most cases FSCAL[2:0] should be set to something close to 400000h, to correct for small gain errors.

     

    Regarding your other issue with reading an extra data byte:

    You're sending the correct command sequence, so there shouldn't be an issue. The ADC does NOT need an extra byte to process the command, as shown in Figure 121 of the datasheet:

     

    Have you tried looking at the SPI bus with an oscilloscope?
    I suspect that the communication is okay, however, you may be running into an issue with your MCU. Many MCUs implement an SPI buffer and, if not cleared out, you may have an extra byte (or bytes) left over from the previous SPI transaction. You may need to read from the SPI buffer with EVERY byte sent (even for command bytes when the communication is not full-duplex) to ensure that the buffer does not hold on to those junk bytes. Otherwise, you may need to clear the SPI buffer before starting another command sequence.

     

    LOKRAJ PATRO said:
    Below ADC data is read for INPMUX = 0xCC configuration:
    “40 40 40 2A 82 31 B8 “ here 1st 40 is extra byte which ADC sends after that valid 6 bytes.
    40 : (2nd byte) status byte new ADC1 data is available
    40 2A 82 31 : is ADC data which is equivalent to 1.253V
    B8 : is checksum.

    In this case you may be sending an extra byte after reading the previous data...

    The ADS1262 will REPEAT the data output sequence, starting with the STATUS byte. Therefore, you may be getting the STATUS byte into the SPI buffer on the previous reading. Then when you go to read data again (without first clearing the SPI buffer), you will get the new STATUS byte and the data, so the MCU acquires two STATUS bytes in a row.

    Does that make sense?

     

    Best Regards,
    Chris

  • Hi Chris,

    You are absolutely right.
    Now able to receive exact ADC data as per data sheet without any extra byte, after clearing SPI receive buffer (before transmitting new command).

    Below ADC data is read for INPMUX = 0xCC configuration:
    40 40 20 2D 97 BF
    40 : (1st byte) status byte new ADC1 data is available
    40 20 2D 97 : is ADC data which is equivalent to 1.253V
    BF : is checksum.

    Thanks a lot for supporting. Cheers!!!

    Thanks & Regards,
    Lokraj
  • Hi Lokraj,

    Glad I could help!

    Feel free to let me know if you have any additional ADS1262 questions that I can help with.

    Best Regards,
    Chris

  • Hi Chris,

    I hope you are doing good .

    As i mentioned earlier I am able to read ADC  data properly  for INPMUX = 0xCC configuration i.e. ANALOG POWER SUPPLY MONITOR (+), ANALOG POWER SUPPLY MONITOR (-) i.e. around 1.25V every time . , However i am getting garbage values if i am again writing same or different configuration after some time.

    Below are the steps:

    1) Configuration write for INPMUX = 0xCC with gain  1

    Reading proper data .

    2) Delay (2 Sec)

    3) Again write configuration INPMUX = 0xCC with gain  1 OR  Configuration write for INPMUX = 0xCC with gain  2

    Reading Garbage data.

    Query:

    1)   is there any special steps needs to be taken care for writing configuration Second time onward ? Or let me know to perform any experiment.

    Looking forward to hear from you ..

    Thanks,

    LOKRAJ..

  • Hi Lokraj,

    I am well, thank you!


    I would double check that the WREG command to configure the device (the 2nd time) is completing successfully and that after starting another ADC conversion that you are waiting the proper time for the conversion to complete.

    By chance, would you be able to share the garage data that you are getting? ...Perhaps this data may give us a clue to the issue.



    You could try the following things to help troubleshoot the issue:

    - You could skip the second register configuration and just issue another START command to get another ADC conversion result. If this data is valid, then there might be a problem with the 2nd WREG command sequence.

    - You can read back the register settings (with RREG) after writing to the registers the second time, to ensure that are configured correctly before starting the next conversion.

    - Do you toggle /CS after configuring the device for the second time? This "resets" the SPI communication and can reduce the chance of communications issues. If you don't already do this, then I would recommend adding this between ADC commands.

    - Also, since you have the STATUS and CRC bytes enabled, you might try verifying that the STATUS byte looks okay and the the CRC byte matches the data that you're receiving.


    Best Regards,
    Chris
  • Hi Chris,

    The problem was with SPI receive . After clearing SPI receive buffer few more times , i am able to get proper data.

    Thanks for your support,

    Lokraj.

  • Hi Lokraj,

    I'm glad you found the issue and thank you for the update on the problem!

    Let me know if there is anything else I can do to help.

    Best Regards,
    Chris