This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Part Number: ADC3424
in our project we use the ADC3424 part in 2-wire mode sampling at 40MSPS.
We acquire data with an FPGA that performs deserialization and bitslips the data.
We use frame clock FCLK as a reference for our bitslipping procedure.
In a few cases we observed that data at the channel and FCLK gets misaligned.
FPGA is correctly aligned to FCLK but data has an error offset by 3 to 5 bit positions.
Also when this happens, error is different for each channel of the ADC.
For example: we get an error of 3 bits for channel A and 5 bits for channel B.
We observed one additional problem when using the test patterns in ADC's erroneous state.
There seems to be bit error even between two lanes of one channel - e.g: DA0 has error of 3 bits and DA1 has an error of 4 bits.
Is this an expected behavior? I think test patterns are free running and I am unsure whether the lanes in a channel are aligned in this mode.
According to timing diagram (Figure 130 in datasheet) data should be aligned to frame clock.
Only variable propagation delay mentioned in datasheet is t_PDI that applies to propagation of input clock to FCLK.
I assume that data clock DCLK and FCLK should be always aligned considering they are sourced from the same PLL.
Can you provide me more information on timing between clocks and data channels? Is it possible there is no deterministic relationship between them?
Is aligning to FCLK clock a valid option or should we consider do the alignment with test patterns instead?
We tried to reset the ADC via reset pin and software reset but that did not change anything. Only power cycling the board helps.
Yes, DCLK and FCLK are aligned as you have described.
Triggering the FPGA data acquisition off of the FCLK or DCLK should be reliable.
Is a hardware reset being performed as part of start up? Are any register writes being performed for the expected normal operation?
When you see the error in the data, is it a shifting of data, or is it just completely wrong? Can you share a screen shot of what one of these errors looks like?
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to dBrock:
thank you for a quick response.
We do perform hardware reset on the ADC. Although it seems it doesn't impact the ADC behavior if we trigger it again when erroneous state happens.
Triggering the software reset does not help either.
We don't change any registers since default configuration of the ADC works fine for us, we only start test patterns for debugging.
When we see the error, the data is shifted.
I cannot share a screenshot right now. It is hard to reproduce, because it happens once in many power cycles.
But lucky enough, colleague of mine debugged the board in the last erroneous state with test patterns an this is what we got for channel DAx:
For channel DBx we got these errors: DB0 by 5 bits to the right, DB1 by 4 bits to the right.
He didn't get the data for channels DCx and DDx, but you should be able to get the overall idea.
What troubles me is the fact that the bit shift is not consistent within one data channel in 2-wire mode.
In reply to Jakub Tomko:
I am not certain as to why this is happening. It looks like it could be a firmware issue though. Do you have a way to test the firmware without the use of the ADC?
For instance, when you get into this error state, can you reset the firmware and see if that clears the issue?
Are you able to share a schematic? What is the sampling clock source? Can we verify that the clock source / power rails is not getting disturbed during the error state?
we thought it could be a FPGA FW issue. We tried multiple resets, reboots, and even flashing with a bit different version of the FW, although the ADC interface logic is still the same. None of these changed anything. Once in the error state only power cycling of the ADC board helps.
The number of bits the data is shifted by always remains the same after each reset or reboot of the FPGA.
This behavior made me think of some misalignment between FCLK and data channels.
We provide sampling clock from SI5338B (https://www.silabs.com/timing/clock-generators/general-purpose/device.si5338b)
I cannot confirm that power rails do not get disturbed. It is under further investigation since the module is part of the larger fairly complex system.
Wouldn't a reset recover the ADC from the error state once power rails are stable? Communication with the ADC works fine. We are able to set registers and ADC responds to it as expected, only the data continues to be shifted. If there is power rail disturbance, I think it gets stabilized over time.
Do you happen to have access to an oscilloscope or logic analyzer? If you are able to probe the FCLK and the data lines for one channel coming out of the ADC (please share images), we can see what the ADC is actually putting out. I think this will help to best guide our troubleshooting efforts at this point.
Additionally, if you are able to share the ADC schematic, this would be helpful.
I am sorry for late response, but we did investigate it a bit more and now we know the cause.
We found out that out system occasionally experiences a power supply outage for ADC's analog supply while digital supply is OK.
This always gets the ADC into a weird error state - SERDES interface sends wrong data and if you read SPI registers you receive random values.
Resetting the ADC helps though.
Our problem was a bit more complex since it was masked by the FPGA a bit.
This happened to us:
1. Our system booted up correctly (all power supplies up), ADC was reset, afterward FPGA logic does bitslip procedure to align data channels etc.
2. Analog power supply outage happens. During this event DCLK is glitching which causes SERDES cells in the FPGA to have different bitslip values and thus the bitslip difference per lane in channel, etc.
3. After last event ADC is stuck in error state and DCLK is inactive.
4. We reset the ADC
5. ADC is functioning and DCLK is active again.
6. FPGA logic deserializes data and since we got corruption in bitslip logic due to DCLK glitches we get different offset per each lane/channel only FCLK is correctly aligned since it is the reference signal.
7. Resetting the SERDES cells is enough to get it back in order, but we did more automated recovery logic for our use case.
Our testing proves that ADC gets into error state even when digital supply is up first and analog one a few seconds later.
I hope this post helps anyone encountering the same behavior.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.