ADS1299 Startup

Brian,

The schematic is attached.  I only included two of the five A/D converters and the micro driving them.  The other three are essentially the same.  This should give you everything you need to know, but let me know if it doesn't.

The startup sequence is as follows:

After processor startup, a timer is started.  Other things get initialized while it is waiting to set up the ADC.  After the timeout period, the ADC configuration registers are written as follows:

We do not currently reset the ADC as the spec requires.  We did try issuing a RESET command over the SPI interface at the start of the initialization and waiting longer than 18 clock cycles required.  It did not have any effect that we could detect.

The initialization timeout is currently set to 250msec and startup errors are rare.  At 125msec they were more common, but still fairly rare.  At 100ms the startup errors were quite frequent.

I am out of the office tomorrow, but on Friday I will add the RESET command back in and shorten the delay time back to 100msec and see if I can get more detail on what is happening and how often.  Let me know if you have any other suggestions to try.

Tom

Brian,

As I was pulling together the information for your last request, I realized a number of things I thought were happening at startup were not actually happening.  I've been juggling this with some other priorities, so it's taken longer than I had hoped, but I think we are now following all the timing guidelines in the data sheet and we're still having trouble.

Our startup sequence is as follows:

Wait 20msec for power to stabilize

Enable main clock (2.097MHz oscillator)

Wait 38msec

Issue SPI reset command

wait 1 msec

Issue StopContinuousMode command

Set Channel Registers to 0x00

Set Config Register 1 to 0x95

Set Config Register 2 to 0xD1

Set Config Register 3 to 0xE8

readback channel and config registers to verify they are set correctly

The initialization issues seem to be specific to certain chips.  Some of the 5 ADS1299 always configure OK, some are OK sometimes and not OK other times.  The ones that are intermittant vary between different boards, so I don't think it's due to a PCB issue.  The symptoms of a misconfigured device vary.  The outputs are often, but not always saturated, and if they are not the noise level is very high (several millivolts typically).  The two consistent things we have found so far is that a misconfigured device will not read back the configuration registers;  All reads return 00's.  I assume this is because any SPI read is read data registers, regardless of what commands may have been sent, but I don't have any way to confirm that.  The second consistent thing is that setting the channel mux to the test pattern setting saturates the output, usually positive, but occasionally negative.

I will continue to dig into this issue, but any help you can offer would be appreciated.  Someone just reminded me that we do have and ADS1299 eval board here, so we will look for differences from that as well.

I tried your suggestions for uploading the file, but without success so far.  I am working on a Linux machine, so I will try loading it from Windows and try a few different browsers as well to see if I can get one of them to work.

Tom

ADS1299 Schematic.pdf

Brian,

We are powering the whole board from an isolated DC-DC converter that puts out 5V.  The DVDD is from a linear 3.3V regulator on the  5V and the AVDD is the 5V filtered by a 100uH inductor/100uF capacitor.  The 3.3V is stable about 1ms after power-up, while the 5V takes another 10msec or so to reach its final level.

The oscillator spec sheet specifies a 10msec startup time, but it was typically a few msecs.  For testing purposes, we wired the OE pin on the oscillator to a pin on the micro so we could control the startup.  After powerup initialization, the micro waited 20msecs for power to stabilize, set the oscillator OE pin to enable the clock, waited another 38msec, and then reset and initialized the ADS1299.  Setting that final delay to 100msec lessened the frequency of the error, and setting it to 500msec eliminated it completely.  Based on past experience, my guess is that if we ran it enough times, we would eventually see a configuration error even at 500msec, but to this point we have tried it about 50-100 times and not seen any problem.

Tom

Brian,

Here is the screen capture from the scope.  The purple trace is AVDD, the cyan trace is the ADC clock and the yellow trace is the SPI clock.  The SPI clock pulses at the end are the RESET commands followed by the configuration register setup.    In doing this I discovered that the RESET pin was being driven by the micro immediately at power up.  I hoped that might be the source of the problem, so we disconnected it.  It is no longer driven, but I did verify that the pin goes high at powerup and stays high throughout the initialization process.  It didn't change the problem at all, but the pin is no longer available to drive, so we switched back to the using the RESET command.  I can rewire the board so that we can drive the pin if that would be beneficial.

Let me know if you would like to see anything else.

Tom

B

Brian,

That is fine with me.

Tom, 

Did you every find a solution to this issue? I am seeing the exact same results. Often, my data is reading all zeros from the ADC channels. 

Thanks,

Chris,

We did get it resolved.  We needed to wait 2^18 clock cycles (125ms) after power-on before any activity on the chip.  The datasheet has been updated with that timing requirement as well. (SBAS499C - pg 70)

Tom, 

Thank you for the reply. I am currently waiting 3 seconds after power-up before even issuing a RESET (VCAP1 charges rather slow for some reason). After I issue a RESET I even wait 100 ms before starting to initialize the registers.

I initialize the ADS1299 and sometimes get good RDATAC data, but if I re-initialize the ADS1299 (while still powered up) I occasionally get bad RDATAC data. Not much consistency.

Thanks,