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.
I have a question about the startup timing for the ADS1299. We have a custom board design with multiple ADS1299 converters. Most of the time it is working fine, but occasionally a few channels don't power up correctly. Its roughly one time in about 50 powerup cycles, and the results are a little random. I've seen alternate channels on one ADC affected, all the channels on one ADC affected, and other combinations. Sometimes the output is fixed at zero, but mostly they are saturated high or low. The input is always driven, sometimes with a few millivolt AC signal, mostly with zero (a few millivolt DC offset). It looks to me like the PGA configuration is not correct, but I haven't investigated it too deeply and I could be wrong on that. Powering the board down and restarting it has so far always cleared the problem.
The PowerUp Sequencing section of the data sheet (page 57) says there should be 2**16 clock cycles from power supplies up to Reset. At the 2.048MHz clock we are using that should be about 30msec. We are using the SPI reset command issued by a CPU on the same power supply as DVDD for the ADC, but need to wait at least 100mS before issuing the reset command or it doesn't startup correctly most of the time. The frequency of startup errors does seem to be tied to that delay time, but its not a linear relationship.
The flow chart on the following page says to wait 1 sec before resetting. That seems like a pretty long time. We can tolerate the delay if necessary, but we tried it and even at that delay I had one or two times that it didn't power up correctly.
What is the required delay from powerup to reset and do you have any other ideas on how we can prevent this from happening
In reply to Brian Pisani:
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.
In reply to Tom Moyer:
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)
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.