ADS1299-4: ADS1299 is unresponsive to commands

Hi David,

Thanks for your post!

From your description I think that you may be missing the additional /RESET pulse. If you look at the flow on pg 62, after VCAP >=1.1V, -> "Issue Reset Pulse, Wait for 18 tCLKs" -> Send SDATAC command. Is this the cause?

I have a few other threads with some common questions for issues like these. If the suggestion above and the questions in the threads below don't fix your problem please let me know. Providing screen captures and a schematic may be helpful as well.

SPI Checklist: e2e.ti.com/.../2727329
SPI Speed: e2e.ti.com/.../2573727

1) Does the ID register read back correctly?
No
2) Are you following the correct start-up sequence in section 10.1.2 and 11.1? After the power-on reset is complete, /DRDY should begin pulsing at the default data rate (assuming the START pin is pulled up). The /RESET pulse after tPOR is essential for bringing up the digital core in the correct state.
As far as we have measured, yes. We will go through and check again this afternoon.
START is tied high. I am toggling the RESET by GPIO well (>10s) after DRDY is pulsing.

3) Before trying to read the registers, are you sending the SDATAC command?
yes
4) Can you provide a schematic?
If needed
5) What is the frequency and how many SCLK pulses are you sending to clock data out?
@Mhz
8 per byte, three bytes of toggling for a register, one byte of toggling for a command with the CS held for the entire transaction . Plenty (>1ms), between bytes.

I've tried 16 bit transfers as well. This SPI engine will not handle 24bit transfers, otherwise I'd have tried that too.



If I toggle the reset, the DRDY returns and I read 4x24 bits of garbage before zeros are consistently returned.

What would you like to see trace wise?

Hi David,

Typically, if the ID register is not reading back correctly then there is an issue with your startup/power up routine.

e2e.ti.com/.../658195
e2e.ti.com/.../2706522

Trace wise, DIN, DOUT, SCLK and CS. This may not be necessary though as I suspect there is a timing or command issue. If you post your code I can take a look as well.

Here's the schematic 

:ADC_brd_TI.pdf

This is the SDATAC, First wide view showing DRDY pulsing, 

Narrow view showing 8bit SDATAC command with miso clocking garbage back:

ID request, wide view of three clock transfers <CMD><NREG><Dummy>

first byte out, garbage clocked in

Second byte:

Dummy byte: (expecting data returned....), got garbage

We are using this chip at 1.8v dvdd -vs- the eval board at 3.3v dvdd. SPI is mode 1. 

This is attached to an ARM with a PL022 SPI engine. I am currently using library calls for the transfer, but I can manipulate the registers directly if needed.

The DRDY signal pulses at the Spec frequency on "power-up", and observed before the reset is toggled through a GPIO pin.  SDATAC is sent seconds later.

Hi Alex,

I am working with David Tyree on our ADS1299-4 SPI issue. We have VCAP1 tied to -2.5v through a 100uf cap. When I read the voltage across the cap I get +1.208 volts. Is -2.5v the correct reference point for my meter gnd or should I tie my meter gnd to chip gnd?

Hi Roger, David,

Looking at your MOSI line, it looks like the data is being sent backwards. For example, "Narrow view showing 8bit SDATAC command with miso clocking garbage back" is showing 1000 1000 instead of 0001 0001 for the SDATAC command. Same pattern for "first byte out, garbage clocked in".

You are reading VCAP1 correctly. If you want to check the other VCAP voltages here is what they should be:
VCAP1: AVSS + 1.2V
VCAP2: (AVDD+AVSS)/2
VCAP3: AVDD + 1.9V

I've sent it both ways, I'll switch and try again...

Most significant bit first, with the same timing does not work either. You want screen shots?

Most significant bit first, with the same timing does not work either. You want screen shots?

I've tried SDATAC, and RREG ID.

Hi David,

Screen shots would be great. Just a reminder to check your SCLK frequency, send 4 sets of 8 SCLKs, and 2 bytes of data on MOSI as shown in section 9.5.3.10 of the datasheet.

Ryan explains it well in this post: e2e.ti.com/.../705896

Alex,
9.5.3.10 shows a two register read (nnnnn =1). I should be able to get the ID with just three SCLK transfers, (nnnnn=0),correct? I'll get the traces this morning.

SDATAC BE wide:

SDATAC BE narrow:

ID BE Wide:

ID BE B1:

ID BE B2:

ID BE B3

Here's a reproduction of the last with the bit order changed. I understand what the spec says the transfers are, but in the absence of data, I've pretty much tried all the permutations. This is MSB first, SPI1.

The library in use is part of a proprietary SDK for the arm we are using, not a very vetted os, but "trustworthy" with single byte transfers, I'll have to write a lower level replacement to handle 16 bit transfers or better byte to byte transfer timings if needed.

 

Hi David,

Looking at the screenshots, now it appears that you are no longer in SPI mode 1. Looking at the narrow screenshots, your MOSI is transitioning on the falling edge, which means that you are in SPI mode 0.

e2e.ti.com/.../2315934

Since you are in the incorrect SPI mode, you never get to SDATAC mode, and you are attempting to read the ID register while still in RDATAC mode.

Looking at your schematic again, what is the purpose of R1 & C19, R2 & C20,... etc? Same question but for TV1 and TV2? You may want to consider removing these components. Is your sniffer hooked up by the processor or the ADC? It's possible that the sniffer is not actually seeing what is appearing on the ADC pins due to these connections.

 Sorry, the last data set was from the wrong file, my board was being converted to 3.3v operation. 

This morning I got to test the board and it works at 3.3 volts with the test read. Reg0 returns 0x3c and reg1 returns 0x96.

We'll try again with 1.8v, but can live with 3.3v. 

Is your SPI mode affected by the digital voltage level?

What voltage is your uC running at? If the uC is running at 3.3V, ADS1299 digital supply is 1.8V, and there's no level translation in between then it could be that the MISO signals are not passing the threshold of recognition by the uC.