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.
Hi guys,
I have a question from a priority customer of mine using the PCM4202 on a soon-to-ship design:
Occasionally, I observed unexpected excessive noise (observed more than 15 bits toggling at ADOUT), from PCM4202 A/D. I disconnected all sensors so the input noise to PCM4202 is relatively small during my investigation.
Here are my observations:
If all PCM4202 A/D are working normal, i.e. no excessive noise, after power on they will remain ok ( less than 10 bits toggling at ADOUT) until power off.
If any PCM4202 A/D outputs excessive noise after power on it will keep outputting excessive noise until power off.
All PCM4202 A/D clocks (SCKI, LRCK and BCK) are fed by the same source -> K2G processor’s MCASP0_AHCLKR, MCASP0_AFSR, MCASP0_ACLKR.
During the power off the Vcc +5VA drops to 0V but my VDD +3.3VD doesn’t drop to zero. Instead, it drops to 2.1V.
According to data sheet:
The power-on reset circuit
monitors the VDD (pin 14) and VCC (pin 22) power supplies.
When the VDD supply exceeds +2.0V (±400mV) and the
VCC supply exceeds +4.0V (±400mV), the internal reset
signal is forced high. The PCM4202 then waits for the
system clock input (SCKI) to become active.
Q1: Can I get proper Power-On Reset after power on, i.e. Vcc goes from 0V to +5V and VDD goes from 2.1V to 3.3V? Do you think my issue is reset related? Why doesn’t happen all the time? Why doesn’t always impact all A/D when the excessive noise occurs?
Q2: My schematic is attached below. RST(pin19) has internal pull-up). Do I must to have pull-up for HPFD and S/M (PCM4202 is in Slave mode on our board)?
Thanks,
Brian
Hi Brian,
Apologies for the late reply.
I don't think the issue is related to power-up sequence...but just to make sure, would you be able to share scope capture of clocks and other supply rails on power-up? is this issue very easy to recreate? Finally, will the issue not be seen if we force RST on the device by pulling RST pin low for >40nS?
We do not have anyone from design side who worked on PCM42xx family to consult with...but we should be able to run some bench tests to figure out the root cause.
Thanks.
Best regards,
Ravi
Ravi,
When the unexpected noise shows up we force RST* pin low , i.e. external reset, does remove the noise, but cause a phase shift problem as I mentioned in this post. We compare the ADC sample outputs with different durations of RST* low. E.g. if RST* goes low on the rising edge of LRCK then goes up after 3BCK (bit clock is 1/64 of the L/R clock) it will have phase difference of one BCK on the ADC samples comparing RST* goes up after 4BCK.
For the following scope shot, channels are the following:
Ch1 in yellow color is the RST* signal.
Ch2 in blue color is the 3.125MHz BCK signal.
Ch3 in pink color is the 48.828125KHz LRCK signal.
Ch4 in green color is the 12.5MHz SCKI signal.
External Reset applied to PCM4202:
We set the RST* signal LOW on the rising edge of LRCK and change the duration of RST* LOW in terms of number of BCH clocks. We can see the A/D samples have different phase depending on when the RST* rising edge occurs refer to LRCK. There is a discrepancy between data acquisition and data sampling. Can you guys confirm these findings?
For power on reset, see below scopeshots:
The above scopeshot shows the +5VA Vcc (red color) and +3.3VD (blue color) supplied to PCM4202 starting 350ms earlier before digital clocks start.
The above image png shows the first LRCK, MCLK(i.e. 12.5MHz SCKI) and BCLK (3.125MHz BCK).
The above scopeshot shows the PCM4202 DATA is not ready until 22.859ms after System Clock SCKI becomes active. Based on data sheet, the DATA should be valid after the 1024 SCKI clocks initialization period. Why PCM4202 doesn’t behave as specified in the data sheet?
Between these two issues on these two E2E posts, can you let us know the best way to guarantee a known phase and same behavior from all the ADC converters?
Thanks,
Brian