Hello TI Team,
I have an engineer that is having some issues with the digital interface (SPI) to the ADC084S021.
The engineer is not looking for support on the actual issue he is seeing, he was hoping to be able to talk to someone about questions he has with the datasheet. One question is the datasheet indicates the part completely powers down when the CS is de-asserted, so do you not de-select the chip when running in an interleave mode?
As he mentions below, he is seeing different behavior with the part under real time and debugging and wanted to get TI’s opinion on exactly how to interface to the part for what he is trying to do; and what he should expect as far as when and what values are returned.
Some detailed information on his issue...
The device uses all 4 ADC channels of the part and the software was written to not interleave the reading of the ADC, but just force a conversion on the requested channel by writing the address twice and throwing away the first reading. The software also de-asserts the CS line between reads. Therefore what we end up with is:
Turn on IR LED (light count)
Channel 1 write and throw away return value.
Channel 1 write and keep return value.
Turn off IR LED (dark count)
Channel 1 write and throw away return value.
Channel 1 write and keep return value.
Turn on IR LED (light count)
Channel 2 write and throw away return value.
Channel 2 write and keep return value.*
Turn off IR LED (dark count)
Channel 2 write and throw away return value.
Channel 2 write and keep return value.
Continue with channels 3 and 4 and then return back to channel 1 and start over. Each double read is executed in a 2.5ms interrupt.
Now here’s where things seem to get complicated. The issue we see is that the channel 2 light count read (*) sometimes gets stuck at 0x80 for a while, then all of a sudden it starts returning the real value. When the digital side is returning 0x80, we can measure the voltage at the input pin and it calculates out to a higher count. Now 0x80 is the address of the second channel, but that doesn’t explain why the dark count reads are always correct. We also have a bus analyzer on the digital side and the value being returned is 0x80.
I have tried not releasing the CS between the two reads and that hasn’t helped. I have also tried interleaving the reads. There is also an interaction with my development tools when I run with breakpoints that introduce some other issues in this mode that we don’t see running in real time or with a bus analyzer.
Any support on this would be much appreciated.
Thanks!