• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 46 subscribers
  • Views 199 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.

ADS1259-Q1: Valid Data Only When CS Held Low. No Data when CS set low from high.

Michael Green69
Prodigy 110 points
Part Number: ADS1259-Q1
Other Parts Discussed in Thread: MSP430F2619, ADS1259

Tool/software:

I'm currently working on a tool that includes an ADS1259-q1 and msp430f2619 MCU. Currently, my hardware and firmware are able to read valid data with Chip select (CS) always low (set with GPIO pin), as seen below:

* START = yellow (circled), DRDY = purple, CS = blue, DOUT = green. 

 

I am preparing for a future design in which 2x ADS1259-q1 will be on one SPI line (sharing SCLK, DOUT, DIN with separate CS, RST, START, DRDY). I am testing a communication scheme that engages the CS with one ADS1259 on one SPI line in preparation. However, when engaging the CS, my DOUT remains inactive. This is shown below:

* START = yellow (circled), DRDY = purple, CS = blue, DOUT = green. 

Some notes:

  • This is the same hardware that gave me valid results with CS kept low.
  • The only difference in firmware between version is whether CS is kept low for entire operation (the working version in first screenshot) or if CS is only brought low for read/write operations (the second screenshot).
  • The datasheet mentions a minimum time between CS low and SCLK rising edge of 50ns. I measure 300ns in my system and have tested with delays up to 15us with no change in behavior.
  • Checked pins on ADS1259 and MSP430 side to confirm signals going through.
  • MCU uses 16MHz external clock, The ADS SCLK uses SPI clock set to 2 MHz
  • ADS1259 register settings (applies to both cases):
    • CONFIG0 = 0x05: SPI timeout enabled, Internal reference bias
    • CONFIG1 = 0xc0: checksum, out-of-range flag enabled (used to confirm valid data)
    • CONFIG2 = 0x17: Pulse Control Mode, 14400sps.
    • Offset: not set
    • Set to RDATAC 

I am looking for additional debug tips to look into as I try to get this working with CS. Also, I would appreciate any advice to consider when designing a system with 2x ADS1259-q1 on one SPI line

  • 0
    TI__Guru 52496 points

    Hi Michael Green69,

    Can you bring the START pin of both devices high and then monitor the DRDY pin of both devices to see if they are both working? You should see DRDY toggling at approximately 1/data rate. If you do this at powerup, expect the default data rate of 10 SPS.

    Can you try enabling SDATAC mode and using the RDATA command instead of RDATAC mode?

    Do you have a logic analyzer for this troubleshooting effort? That will make it a lot easier than trying to use a scope, especially because you want to look at longer periods of time and multiple signals (>4) at the same time

    It is definitely possible to use 2x ADS1259 in the configuration you are describing, so there is some other issue here

    -Bryan

  • 0 in reply to Bryan Lizon86
    Prodigy 110 points

    “Can you bring the START pin of both devices high and then monitor the DRDY pin of both devices to see if they are both working? You should see DRDY toggling at approximately 1/data rate”

    I do not have hardware with 2 devices on 1 SPI line at this time. I am testing with 1 device on 1 SPI. For the above test, I assumed this needed to be in Gate Control mode to work. Switching modes and keeping START high, I get the following:

    Blue = CS, Yellow = DRDY, Green = DOUT

    Here, DRDY pulses every 68-69us, ~14.4kHz. This corresponds to the 14400SPS that I have programmed to. DRDY stays high for ~2.67us or 20 clk cycles for 7.5MHz clock on ADS1259. I believe this corresponds to expected behavior and commands. I don’t have a scope pic of this, but using chip select, DOUT remains inactive in this mode as well.

     

    “Can you try enabling SDATAC mode and using the RDATA command instead of RDATAC mode?”

    This is where things get interesting:

    Purple = DRDY, Blue = CS, Yellow = DIN, Green = DOUT

    In SDATAC mode + pulse control, by sending RDATA (in yellow), the ADS1259 chip does respond with valid data (passes checksum check). I will evaluate whether this mode works for our application, but this is likely a workable solution.

    I would still like to understand why RDATAC is having issues with CS though.

  • 0 in reply to Michael Green69
    TI__Guru 52496 points

    Hi Michael Green69,

    In the image below (which is the second image from your initial post), what were you expecting to see here? I cannot see the START signal going high, but I am guessing this is behind the purple trace where you circled? Then DRDY (purple) goes high, and then about 420us later it drops low. At this point you pull CS low for about 25us. I assume during this time period you are sending SCLKs? (this is why I recommended a logic analyzer for this task, because then you could capture all of the signals at the same time). I just want to confirm as there is nothing obviously wrong with the image below, unless of course you are sending SCLKs during this time. Also you say that "DOUT is inactive", so I just want to understand if this means "DOUT isn't sending data even though I am sending SCLKs", or something else

    -Bryan

  • 0 in reply to Bryan Lizon86
    Prodigy 110 points

    “Also you say that "DOUT is inactive", so I just want to understand if this means "DOUT isn't sending data even though I am sending SCLKs",”

    This is what I meant. I retook the screenshots and zoomed in to show SCLK in RDATAC + Pulse Control Mode:

    Purple = DRDY, Blue = CS, Yellow = SCLK, Green = DOUT

    Compared to SDATAC + RDATA command + Pulse Control Mode (this is valid data):

    Purple = DRDY, Blue = CS, Yellow = SCLK, Green = DOUT

  • 0 in reply to Michael Green69
    TI__Guru 52496 points

    Hi Michael Green69,

    Thanks for clarifying

    In your original code, were you sending the SDATAC command to initialize the device, then sending the RDATAC command once you were ready to start converting?

    And were you using the START pin or START command to control conversions?

    Is there any reason you selected Pulse Convert (single-shot) mode instead Gate Control (continuous conversion) mode? It seems like you want to be able to start the ADC at some specific instant, take one sample, then wait for some amount of time before repeating this process - is that correct?

    Let me know if using SDATAC + RDATA is a sufficient solution to your issue. If not, I can try to mimic the behavior you see in your system, but I will need more time (1-2 weeks) to do so.

    -Bryan

  • +1 in reply to Bryan Lizon86
    Prodigy 110 points

    In your original code, were you sending the SDATAC command to initialize the device, then sending the RDATAC command once you were ready to start converting?

    That is correct. Specifically, these are the settings used to init ADS1259 in both screenshots in last post. The only difference is the last command is commented out for SDATAC + RDATA. It is active for RDATAC.

        writeSPIA0(0x11);    //SDATAC = stop data continuously

    writeSPIA0(0x40);    //WREG command: from address 0h

    writeSPIA0(0x05);    //WREG command: 6 registers - 1

    writeSPIA0(0x05);    //CONFIG0: SPI timeout enabled, Internal reference bias

    writeSPIA0(0xc0);    //CONFIG1: checksum, out-of-range flag enabled

    writeSPIA0(0x17);    //CONFIG2: Pulse Control Mode, 14400sps.

    writeSPIA0(0x00);    // Offset: not set

    writeSPIA0(0x00);

    writeSPIA0(0x00);

    //writeSPIA0(0x10);  //RDATAC = read data continuously
     

    And were you using the START pin or START command to control conversions?

    In both scenarios, I was using the START pin.

     

    Is there any reason you selected Pulse Convert (single-shot) mode instead Gate Control (continuous conversion) mode? It seems like you want to be able to start the ADC at some specific instant, take one sample, then wait for some amount of time before repeating this process – is that correct?

    Yes, that’s correct.

     

    Let me know if using SDATAC + RDATA is a sufficient solution to your issue. If not, I can try to mimic the behavior you see in your system, but I will need more time (1-2 weeks) to do so

    SDATAC+RDATA looks to be a sufficient solution, but I would like to know the root cause why RDATAC + chip select does not work for future projects. If this is an issue of physical damage to chip, I might need to add a check for future debugging.

  • 0 in reply to Michael Green69
    TI__Guru 52496 points

    Hi Michael Green69,

    This doesn't sound like a result of physical damage. But I guess I should ask if you are seeing this behavior on multiple devices / boards? If you are not seeing it all on boards, can you swap a "good" device with a "bad" device to see if the problem tracks the device or the board? If you are seeing this issue on all boards, can you swap out a "bad" device with a device fresh from the reel to see if the problem persists?

    -Bryan

  • 0 in reply to Bryan Lizon86
    Prodigy 110 points

    I don't have an extra device/board to test at this time, but will attempt once I do.