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.
ADS1263: SPI Communication with ADS1263 and ATxmega256a3bu
Part Number: ADS1263
I am experimenting with a very interesting error of communication/acquisition with ADS1263.
Here is the setup:
- Using RPI to access the SPI
- Internal clock
- External reference voltage (2.048) connected AIN0-AIN1 (Single-ended - Neg Grounded)
- Scanning among across all AIN (DIFF) and VDig, Vana, TDAC and TEMP.
- Using serial command to start the acquisition
Everything is working fine, the data is clean, except the ADC1263 starts to reply data corrupted randomly after a few hours, sometimes a day. Interesting though, the same DOESN'T happen if I use the ADS1263 internal reference. It seems the chip reset itself, or at least, the REFMUX switch to the internal reference (reading sometimes is compatible if I am using internal reference - not always).
I have implemented many different traps in my code and looks clean, it is working short term and long term with internal reference. Any clue where should I start to look?
How do handling reading the data? Do you use an interrupt or poll for /DRDY to go low? Also, do you read data directly or issue an RDATA command before clocking out the data?
Is possible that over time the SPI communication is not quite able to keep with the ADC's output data rate. If the MCU is not reading the data quickly enough, it might be clocking out data while a new conversion completes, in which case it's possible to get a combination of old and new data shifted out. The best ways to avoid this are:
Regarding the reference voltage, I would make sure that your external reference voltage is buffered and stabled. Any changes in the reference voltage will get reflected in the ADC output codes. Do you have a schematic of your circuit that you could share?
Are you seeing the RESET flag in the STATUS byte? If so that might indicate that a brown-out occurred and the device was reset.
Best regards,Chris HallApplications Engineer | Precision ADCs
Check out these helpful resources...TI Precision Data Converters | TI Precision Labs - ADCs | Analog Engineer's Calculator | Data Converters Learning Center | Selection Guide
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Christopher Hall:
/How do handling reading the data? Do you use an interrupt or poll for /DRDY to go low?/
I poll the data for /DDY
/Also, do you read data directly or issue an RDATA command before clocking out the data?/
I am sending the RDATA cmd.
/Is possible that over time the SPI communication is not quite able to keep with the ADC's output data rate. If the MCU is not reading the data quickly enough, it might be clocking out data while a new conversion completes, in which case it's possible to get a combination of old and new data shifted out./
Could be! but why doesn't happen when I use the internal reference. The difference between working/not working is just the internal/external reference. I might be wrong, but this should create any extra delay or timing issues.
The best ways to avoid this are:
I am using LTC6655 as the reference voltage (2.048V), unbuffered. I've checked the ref output when the problem happened and looks stable, no oscillation.
In reply to Fernando Rafael:
Do you have an example of the corrupted data that you can share to help me get a better idea of what you're observing?
Probing the external reference voltage was a good idea. However, did you probe with a high-bandwidth oscilloscope or a low-bandwidth DMM? In the latter case you may see a stable DC voltage and not be able to obverse higher frequency oscillations.
Also, I'm not fully understanding if the ADC is getting reset and reverting back to the internal reference. Your earlier comment hinted at a possible brown-out condition:
Fernando RafaelIt seems the chip reset itself, or at least, the REFMUX switch to the internal reference (reading sometimes is compatible if I am using internal reference - not always).
Can you share the register settings that you observed before and after this reset, or perhaps the STATUS bytes that can be read out with the data to indicate if a reset has occurred?
I'm afraid I need some additional details about the error(s) your observing to be helpful.
I made some SW/HW change to diagnose the problem.
Here is more information:
I probed the REF using oscilloscope and DVM, either is clean.
The status bit is 0x40, means everything is working.
I attached below the waveform using the START pin to initialize the acquisition.
1) send the MUX_CH command
2) toggle the START pin and start the conversion
3) wait for DRDY signal (falling edge)
4) read data ADC1 (0x12)
First graphics, ADC working. Results match with the input. The top Trac is an analog signal (Ext REF)
Waveform with problems:
here is the sequence of good and bad data received after a channel selection for the above waveforms.
Chip Select - 0 Serial Data - [70, 0, 69] -----> Select AIN4 and AIN5Chip Select - 0 Serial Data - [18, 0, 0, 0, 0, 0] ----> Read Data CMD--->>> Chip Select - 0 ADC Data Received - [72, 72, 117, 176, 223, 15] ------> Data received GOODRead Status - 72 ----> Display the STATUS
Chip Select - 0 Serial Data - [70, 0, 69] -----> Select AIN4 and AIN5Chip Select - 0 Serial Data - [18, 0, 0, 0, 0, 0] ----> Read Data CMD--->>> Chip Select - 0 ADC Data Received - [72, 73, 96, 124, 116, 128]------> Data received BADRead Status - 72----> Display the STATUS (no change)
REFERENCE 2.048 V
I'm sorry for the delayed response.
The STATUS bytes you're showing (72 with good data, and 73 with bad data), indicate two different errors:
On a side note, you can start ADC conversions by setting the START pin high. Toggling the START pin, as you are, might explain why sometimes /DRDY remains low after a conversion and other times it returns high. If you only want to perform a single conversion then I would set the START pin high, delay, then set START low and wait for the /DRDY signal to go low.
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. 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.