AD5592r Sequence conversion mode

Hi,

Let us know the device schematic and all the device configurations done.

Hi,

We have the same issue. The same channel is sometimes clocked out twice.

HW setup: Custom board with AD5592R-1.

Initialization sequence:
1. 0x05AC to SOFTWARE_RESET_REG (0x0F)
    sleep 1 ms
2. 0x5200 to POWER_DOWN_AND_REF_CONTROL_REG (0x0B)
3. 0x0030 to GENERAL_PURPOSE_CONTROL_REG (0x03)
4. 0x0008 to DAC_PIN_CONFIG_REG (0x05)
5. 0x00F4 to ADC_PIN_CONFIG_REG (0x04)
6. 0x0002 to GPIO_READ_CONFIG_REG (0x0A

Measurements:
We poll the ADC every 10 ms at 1 MHz baud. For now we don't want to use repeat (REP) as we don't have SPI DMA and need to free the CPU.
Tracking command to read ADC channel 2, 4, 5, 6 and 7: 0x10F4.

Screenshot when issue appears. Channel 2 is clocked out twice. Replies with channel 2,2,4,5,6 instead of 2,4,5,6,7:

Demonstration of timing:

Looking forward to your reply,
Marcus

If you do not want to use the REP function and want to read the ADC data continuously, then do note that after all the channels are converted and read out, the ADC goes three-state. As such, you need to rewrite the ADC sequence register and let the ADC conversion begin afresh, so that you do not read out previous valid data.

Thanks for your rapid reply.

Yes, we are rewriting the ADC sequence register every time as you can see in the first screenshot. We always write 0x10F4, wait more than 500 ns (14 us in the screenshot) and start clocking out data.

Also note that it is not always the same data that is clocked out twice. It seems to be from a new conversion.

Edit: We have also tried always clocking out one more word. The error rate was the same (1-2%). When the error happened then, the last channel (channel 7 in our case) was clocked out in this additional word.

Thanks for your rapid reply.

Yes, we are rewriting the ADC sequence register every time as you can see in the first screenshot. We always write 0x10F4, wait more than 500 ns (14 us in the screenshot) and start clocking out data.

Also note that it is not always the same data that is clocked out twice. It seems to be from a new conversion.

Edit: We have also tried always clocking out one more word. The error rate was the same (1-2%). When the error happened then, the last channel (channel 7 in our case) was clocked out in this additional word.

Did you try resetting the ADC sequence register after all the channels are converted and then rewrite the ADC sequence register to enable the required channels.

Yes, I have now tried resetting the ADC sequence register by writing 0x1000.
I have tried resetting both directly after and before performing a new conversion. When resetting before, I verified it was more than 2 us before sending the message to perform new conversions (0x10F4).

Unfortunately, the sporadic double channel error still persists.

Do let us know the entire command steps that you have undertaken after powerup and what SDO results do you get with each step.

Here is the complete init-sequence from power on, including two additional DAC-messages sent right after init (0x3844 and 0xB000). I have also included the initial read (a correct read) and the 45th read (first read with error).

Note that I have intentionally added one additional word when reading (clocks out 0xFFFF when no error). This does not affect the error rate.

Initialization sequence:

First read:

First error (read nr. 45):

Please refer to the last two plots shared.

On the MISO or SDO output, after you have set 0x10F4 on the ADC sequence register, the SDO output is 0x0000 in the correct frame and the 0x7000 in the error frame which is the data from ADC channel 7, which means that there is some issue with the device pattern. Also, if you have disabled the ADC sequence register and re-enabled it, it will start afresh from the lowest channel 2 in your case. So, something is wrong in the timing pattern.

Hi. It is only the very first read that outputs 0x0000 before the first channel. Every conversion after that, correct or with error, clocks out 0x7000 before the first channel. In addition, channel 7 is always read. Even when there is an error due to the additional word clocked out.

The second image in my original post shows the timing of a clock cycle between the two channel 2 readouts. I don't see anything wrong there.

Since we are more people with the same issue, have you tried to reproduce it with the same settings?

I checked with multiple runs on the Eval board and I have not been able to reproduced the issue with the same settings.

Here is what I have observed.

When 0x10F4 is written, you will get 0xFFFF on SDO in the same frame.

In the next frame, you will read back the previous ADC result of the last channel converted. 

In the next 5 frames, you will read back the ADC results of all 5 channels in sequential order. 

If you issue more NOP commands, you will read back 0xFFFF as the ADC is now in tristate, unless you issue other commands like DAC, GPIO or Temperature indicator. This will happen until you rewrite the 0x10F4 again and restart the ADC sequencer.

Additionally, if you have issued more than or less than 5 frames after 0x10F4, then the first frame after 010F4 will have the last valid ADC conversion result of the last converted channel.

So, you have to ignore this channel data in the next frame after writing 0x10F4 in the current frame. You are also not allowed to write any readback data request in any frames while the ADC is converting. 

Thanks, this seems to agree with my behaviour when readout is OK. Have you tried repeating readout in a loop, e.g. every 10ms? It usually works as you have described above, but about 2% of the times i get the error previously described where channel 2 (first ADC channel) is read twice.

I have used the loop method to capture and monitor the data every 1 sec. 

I have additional queries : 

1. After all the ADC channels are converted, are there any other activities executed with the device before the restarting the ADC sequencer again.

2. Is any other device sharing the same SPI bus?

3. Is ADC sequencer aborted midway at any point of time

4. Have you tried changing the clock speed or the frame rate?