I suspect that this issue is very similar to the one posted at the link (ad5592r-sequence-conversion-mode) , but I thought I'd start my own thread in case:
I have experimented with clock rates at 50KHz, 500KHz, and 5MHz, and still I get the same problem, occasionally I lose an ADC conversion result, and instead get one repeated.
I have gone through the datasheet, and I have rechecked timings and even added extra delays just in case but none of it seems to improve the reliability.
I wait for 2ms after power on, and then perform a software reset. I then wait at least another 250uS before trying to configure the device as I want it; IO 0-2 & 5 as ADC inputs, IO 3-4 as gpio outputs & IO7 as ADC busy flag.
After writing the configuration I then read back all the relevant configuration registers and confirm that the configuration is as required, and this always works.
Then I write to the ADC Sequence register for the ADCs that I am interested in, wait for 100uS (to be sure!) , burn one read, and then start my read cycle.
Once the read cycle completes I am then checking my receive buffer to see if it contains all of the ADC indexes that I am expecting, and if it does not then my code will halt; if all is well then my code continues to loop and after 1ms repeats the process again writing to the sequence register and reading the adcs etc.
Here we can see a series of 9 of these ADC reads:
Looking in more detail at the first cycle:
0x1127 is sent from the Controller to the AD5592R to indicate that we want the ADC channels 0,1,2,5 and the die temperature (effectively address 8).
We then wait a duration before doing the "burn" read to start the first conversion.
We then do a sequence of 5 read operations (writing 0x0000) and receive data of 0x0---, 0x1---, 0x2---, 0x5---, and 0x8---, which is the ADCs and temperature as expected.
Similarly if I look at the 8th cycle in the sequence a similar pattern can be seen:
However if we look at the 9th sequence we have the problem:
Here again 0x1127 is sent from the Controller to the AD5592R to indicate that we want the ADC channels 0,1,2,5 and the die temperature (effectively address 8).
We then wait a duration before doing the "burn" read to start the first conversion.
We then do a sequence of 5 read operations (writing 0x0000) and receive data of 0x0---, 0x0---, 0x1---, 0x2---, and 0x5---.
The first result was repeated, and the 5th result (channel 8 / temperature) was missed.
Despite being sure that I had the timings correct, I then repeated the experiment with the MOSI probe instead attached to IO7 as the ADC busy pin (so ignore the MOSI data on the following shots)
This time the full sequence was 7 ADC reads (with the 7th being the failure).
The full sequence is shown below with the RED trace now being the ADC busy line:
Looking at the first cycle:
We can see the same pattern (albeit unable to observe the MOSI data):
The initial command is sent, then a long pause, then the "burn" read to start the conversions, and then the ADC reads returning indexes 0,1,2,5 and 8.
In each case the busy line is only asserted for a very short period since we are at a relatively low clock speed of 500KHz.
Again checking the penultimate "good" cycle all looks well:
and then we have the failure cycle:
In this case we can again see that the ADC index 0 is repeated for two read cycles, and index 8 is missing, despite the ADC conversion 'busy' line indicating that the ADC did do 5 conversions.
PLEASE can someone explain what is going on here and how to avoid it?
Thanks!
