Post Go back to editing

AD5592R ADC Sequence Conversion dropping conversion results.

Category: Hardware
Product Number: AD5592r

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!

Top Replies

    •  Analog Employees 
    •  Super User 
    in reply to PhilV +1 suggested

    Hi  

    The timing looks OK. I was trying to see if the SYNC to CLK edge timing is within the datasheet standards ( t410ns min, 1.65us max)

    What's the value of this wait time after writing to ADC_SEQ…

Parents
  • Hi  

    Thanks for the detailed description. I've understood the problem you are having. Now we'll try to look at why there is more than one cycle latency on the ADC readback on the failing cycle. 

    One thing to look at is the timings, can you zoom in on the first and 2nd conversion cycle where ADC index 0 was repeated. I'd like to check the t4 timing, or the time between SYNC falling edge and the first clock falling edge. 

    What is you clock frequency used? and the voltage levels of VDD and VLOGIC? 

    I'm assuming this is a custom board. Can you share the schematic, an image of your board and mark where you are probing the signals on both your board and the schematic. you can send it to ianvincent.andal@analog.com 

    Best regards,

    Ian

Reply
  • Hi  

    Thanks for the detailed description. I've understood the problem you are having. Now we'll try to look at why there is more than one cycle latency on the ADC readback on the failing cycle. 

    One thing to look at is the timings, can you zoom in on the first and 2nd conversion cycle where ADC index 0 was repeated. I'd like to check the t4 timing, or the time between SYNC falling edge and the first clock falling edge. 

    What is you clock frequency used? and the voltage levels of VDD and VLOGIC? 

    I'm assuming this is a custom board. Can you share the schematic, an image of your board and mark where you are probing the signals on both your board and the schematic. you can send it to ianvincent.andal@analog.com 

    Best regards,

    Ian

Children
  • Hi Ian,

    Thanks for your reply.

    In this example the clock frequency is 500KHz, although I've seen the same behaviour with clocks of 1MHz and 2MHz as well.
    VDD is 3.3V, and there is no VLOGIC on the AD5592R (only on the AD5593R as far as I am aware).

    As for timings, see below:

    Capturing MOSI and MISO for the first and second conversion cycles that give the 0x0FFF output, the t4 timing is approx. 576nS in both cases:

       

    Similarly capturing the ADC_BUSY line instead of MOSI on the red trace:

      

    I have these complete traces available as PicoScope "psdata" files if you wish. For this you could download the free PicoScope 7 T&M software and then open "full sequence" files and could then zoom in on any section as desired - let me know if you want these.

    As a "workaround" for now I have implemented some error detection & correction code in my software, that after receiving the 5 ADC result messages will then inspect them and see if they are the 5 that we requested in the ADC Sequence register write. If it detects that there has been a duplication (and effectively caused all the results to shift right by one conversion cycle) it will perform 1 addition read to try and obtain the missing ADC result.

    With the red trace capturing the ADC_BUSY line we can see here that the ADC conversion is run 5 times with 1 cycle of latency for the ADC results (this is a "good" cycle that doesn't need correction).
    The first comms word is the write to ADC_SEQ, then we have the 'burn' read where we can see the ADC conversion of the first channel was performed, then the next read clocks out the data from the first conversion and starts the second:

    If we look at a "bad" cycle that has the repetition, and requires an additional read:

    This starts in the same manner, but due to the repetition we are short of one ADC result after the ADC_SEQ write, the burn read, and the following 5 reads. Note also that the ADC busy line has activated on the 5th read whereas on a "good" cycle it does not; despite writing the same value to the ADC_SEQ register (requesting ADC channels 0,1,2,5 and 8 (die temp)) the ADC has run 6 conversions.
    Since this includes the "workaround" code the software is then doing a 6th read cycle, where we do get the 5th ADC result (the ch8 die-temperature).

    You are correct this is a custom board, and I cannot send the full design, but the implementation of the AD5592R on the board is fairly basic, so I will send you those snippets via email as requested.

  • 0
    •  Analog Employees 
    •  Super User 
    in reply to PhilV

    Hi  

    The timing looks OK. I was trying to see if the SYNC to CLK edge timing is within the datasheet standards ( t410ns min, 1.65us max)

    What's the value of this wait time after writing to ADC_SEQ register and before starting the first conversion cycle (burn read)? See image below. This might not be in the timings but it is recommended to immediately start the conversion cycle after addressing the ADC_SEQ registers.

    Nice workaround. The safest approach is to utilize channel address encoded in our ADC readback data. 

    Best regards,

    Ian

  • Hi  ,

    In this example this is approximately 31us.

    The safest approach is to utilize channel address encoded in our ADC readback data

    The checking of the address value in the ADC readback data is exactly what my error correction is doing Slight smile

    ..."after receiving the 5 ADC result messages will then inspect them and see if they are the 5 that we requested in the ADC Sequence register write. If it detects that there has been a duplication (and effectively caused all the results to shift right by one conversion cycle) it will perform 1 addition read to try and obtain the missing ADC result."