AD4134 Multi-Device Synchronisation

hi S Robson

Apologies for coming back late.

i presume that you are operating the devices in High Performance, ASRC mode(ODR Input) with DCLK gated as input. 

the DIG_IF_RESET command needs to be simultaneous to all devices and should be given once the PLL is locked.

Please also check if PLL unlocks when you see that 1 ODR difference. Let me know how it goes.

thanks

Hi folks,

Apologies for the delay. I missed the forum notification.

We are operating all the ADCs in :
• ASRC Slave mode
• SPI Control Mode
• DCLK gated mode, INPUT, 50 MHz
• 16-bit mode
• High-Performance mode
• Sinc3 filter with a sample rate of 1 MHz (or 850 kHz when we include the CRC and status bits for debug).

Janine, here is the updated signal trace including the DCLK.

Wa$im, you can also see that I have included the PLL Lock in pink.

I have dropped the sample rate to 850 kHz so that I can include the CRC and status bits in the data word, and see the status of the PLL on every sample.

Then I can look for my lock signal ever being "not equal" to ffff. Once we've established ODR the lock never drops.

We also had a conversation yesterday with one of your local Apps engineers who may share further details with you once I provide an updated report.

Thanks,

Scott

Signal trace with ODR running at 825 kHz. PLL remains locked but still seeing a 1 sample ODR error on some data captures

Is there anything else I could monitor to help diagnose?

Hi Scott

Apologies for coming back late, there is one experiment to check if DCLK is causing any issue.

Steps are

1. configure all SPI registers as per Need

2. Start the ODR only (Not DCLK) and wait for the PLL to lock

3. once PLL locks, Provide the DIG_IF_RST simultaneously to all devices.

4. Start DCLK

thanks

I am still looking at this after a few days vacation. I will have a further update tomorrow

Thanks,

Scott

Hi,

Well this is new behaviour.

We can't tell if the PLL is locked from the data word without the DCLK running, so I am relying on the software SPI registers to tell me that we have initial LOCK on the PLLs after boot.

Then when we apply the DIG_IF_RESET, we get a couple of cycles where the chip report PLL LOCKED before losing lock and re-establishing LOCK a few cycles later. Is this expected behaviour? Perhaps this has been the source of our problem all along but previously I do not think I was seeing LOCK drop at any time.

Thanks,

Scott

Can you comment on whether the PLL unlocking after a DIG_IF_RESET is expected behaviour?

No, this is not the expected behavior. the blocks are different so PLL should not Unlock.

PLL can only unlock incase of a config change or ODR change

An update on where we are at the moment.

I have not been able to rely on the "No Chip Error" bit in SPI reg 0x02 (henceforth SPI Chip Error) to indicate whether the chip is completely happy or not. In fact I can create examples where the SPI Chip Error and the signals from the "Data Interface Status bits" (henceforth ADC Chip Error) are not in agreement.

Thus, I believe the only thing that can be trusted is the ADC Chip Error

This means that for our current scheme, we are making a sacrifice on AD4134 sample rate (so that we can afford to include the extra status bits in the data word, and still have time to shift in the data before the next conversion).

Procedure is as follows :

1. Turn off SW SPI poll as we now know that SPI writes can cause chip errors / LOL.

2. Set up ODR

3. Program all of the ADCs.

4. As a final programming step, change the ADC Data Format to include the status bits and CRC. There is a non-zero chance that this will cause an ADC Chip Error

5. Switch off ODR, then switch it back on. There is a high probability that this will clear Chip Errors. After this :

5a. If No ADC Chip Error then block all further SPI transactions and continue to data capture

5b. If there is still an ADC Chip Error then revert to step 1 and repeat all steps

This is a major compromise but we have exhausted the time allocated to this project and have not been able to find a better solution. Either we have something misconfigured or the chips are not behaving as specified for some other reason.

Apologies Rob for coming back late

do you Observe that No_CHIP_ERR Is cleared whenever you do any SPI operation?

secondly do you say that status header and the SPI registers are no in agreement?

thanks

Hi all,

I believe I have the same problem - data one ODR tick of jitter from reset to reset.

What is the exact sequence for performing DIG_IF_RESET?

Thanks, Steve

hi Rob 

COnfigure all the SPI registers. then Turn ON the ODR and wait for PLL to lock for all the devices.

Issue a DIG_IF_RST once all the devices have PLL locked. 

Note that PLL will be locked unless you start or stop the ODR. OR the ODR value changes cycle to cycle.

you can probe the ODR signal on a oscilloscope for Min and MAX dutycycle and frequency to check 

Hope it helps, thanks

hi Rob 

COnfigure all the SPI registers. then Turn ON the ODR and wait for PLL to lock for all the devices.

Issue a DIG_IF_RST once all the devices have PLL locked. 

Note that PLL will be locked unless you start or stop the ODR. OR the ODR value changes cycle to cycle.

you can probe the ODR signal on a oscilloscope for Min and MAX dutycycle and frequency to check 

Hope it helps, thanks

Hi Wa$iM, I will reply on my thread.

AD4134 data is delayed by one, two or three ODR ticks - Q&A - Precision ADCs - EngineerZone (analog.com)

Thanks,

Steve