• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 46 subscribers
  • Views 1233 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.

ADS131E08: ADS131E08 Registers don't match Datasheet!

Scott Allred19
Prodigy 190 points
Part Number: ADS131E08

I'm trying to get my ADS131E08 up and running on a new board.  I've finally gotten the  OS stuff figured out to get the SPI bus to function correctly and wait the appropriate sclk times.

When I read the registers, they don't match the data sheet for the defaults... 

Most specifically and worringly, the ID register reads 0xC0 indicating it's only a 4-ch device and not an 8-ch, but the part is clearly marked ADS131E08S.

More distressingly, when I try and read data, I get 0x00 back for the read slots for Ch's 5-8.

This is the second device I used, the first device read back as 0x00 for CHnSet{5:8].  I thought perhaps I had written a bad device somewhere in my development.  Now I'm beginning to question these devices, or am I just missing some step in the initialization?

Device ID: 0xc0
Config 1 : 0x94
Config 2 : 0xe0
Config 3 : 0xe1
fault    : 0x00
ch1 set  : 0x10
ch2 set  : 0x10
ch3 set  : 0x10
ch4 set  : 0x10
ch5 set  : 0x10
ch6 set  : 0x10
ch7 set  : 0x10
ch8 set  : 0x10
flt statP: 0x00
flt statN: 0x0f
gpio     : 0x0f

  • 0
    Prodigy 190 points

    Here is the register reading from my second device:

    Device ID: 0xc0
Config 1 : 0x00
Config 2 : 0x00
Config 3 : 0xc9
fault    : 0x00
ch1 set  : 0x10
ch2 set  : 0x10
ch3 set  : 0x10
ch4 set  : 0x10
ch5 set  : 0x00
ch6 set  : 0x00
ch7 set  : 0x00
ch8 set  : 0x00
flt statP: 0x00
flt statN: 0x0f
gpio     : 0x00

    UPDATE:  I've just noticed that I do in fact have ADS131E08S devices, and not the ADS131E08's I thought I ordered (from the TI store).  However, I still only apparently have 4 channel devices instead of 8 channel devices, and therefore the registers still don't match!

  • 0 in reply to Scott Allred19
    TI__Guru 55152 points
    Hi Scott,

    Improper device ID is typically caused by an improper start-up routine.

    Can you verify that you are following section 10.3.1 Setting the Device Up for Basic Data Capture?

    Is DRDY pulsing after initialization?

    A schematic may help as well if above does not fix the issue.

    e2e.ti.com/.../634414
  • 0 in reply to Alexander Smith
    Prodigy 190 points

    Yes, I am following that procedure and meet the timings required.  

    Yes, DRDY is toggling both before and after I write the configuration registers, and START works as advertised.

    And in reading the data sheet it mentions the first read might not be settled data.  I read all the registers a couple of times just to be sure.

    I am indeed getting what looks like fairly appropriate data on the first 4 channels, but all 0 on channels 5-8 - so it looks to me like I've got a 4 channel part that is marked as 8 channel?

    I have attached the schematic for your reference.  Also is a screen shot of my logic analyzer showing that the part does indeed stop sending data.

    ForceFlex-8ch-Amps+ADC_Rev-1 - DEBUG.pdf

  • 0 in reply to Scott Allred19
    TI__Guru 55152 points
    Hi Scott,

    Thanks for checking on those sections.

    While it is possible that you did receive a 4ch version of the device, I think that we should rule out a few small nuances to the start-up routine before exploring that further. Please see the threads below:

    1) Are you sending the SDATAC command before trying to read/write to the part? e2e.ti.com/.../438201
    2) How quickly are your power supplies ramping up? It could be that the microcontroller begins counting the 2^18 clock cycle waiting period before the device is actually ready for the count to start. e2e.ti.com/.../585352
    3) This user reports the exact problem that you're experiencing and it was solved by tweaking the delays. e2e.ti.com/.../292219
  • 0 in reply to Alexander Smith
    Prodigy 190 points
    Thanks! That did it - I was never actually issuing the PWRDN ... perhaps it should be an implicit part of the initial flow at power up
  • 0 in reply to Scott Allred19
    TI__Guru 55152 points
    Great! I'll make a note to revise the datasheet for clarity.