ADAU1442 S/PDIF breaks between two boards
We are experiencing strange S/PDIF lock issues with a custom ADAU1442-based board, but only when connecting S/PDIF I/O between two of these boards. A brief summary:
S/PDIF from 3rd party source (e.g. soundcard): OK
S/PDIF from DUT to 3rd party receiver (e.g. DAC): OK
S/PDIF between two DUT's: intermittent audio dropouts
S/PDIF loopback between TX and RX on the same DUT: OK
S/PDIF from DUT to EVAL-ADAU1442: OK
The breaks are sporadic and of the same length. If ASRC's are disabled on the DSP input they are much shorter as expected, but still audible. They are often clustered together as a series of quick successive breaks. Cold boards also tend to have less breaks than ones that have been running for a while (power-cycle makes no difference so it does relate to heat, not running period).
The DSP program used for testing is made as basic as possible using all default registers and only configuring the bare minimum of a tone generator to S/PDIF TX in the transmitter and ASRC to analog out in the receiver board. Sample rate is fixed to 48kHz.
The board itself is good: 6 layer with continuous GND, VCCIO & VCORE planes, extensive close decoupling. PLL components as per datasheet, proper attention to routing. Differences to the EVM are that the master clock is a 12.288MHz oscillator via a 74LCX125 buffer, and power supplies for both IOVDD and DVDD use switching regulators that are shared with other board peripherals. PSU ripple and noise are measured to be low.
When used with other S/PDIF and I2S/TDM inputs and outputs we easily achieve proper measured audio performance and no breaks so it's hard to blame it on jitter or EMI. With 3rd party S/PDIF sources and loads it is also very difficult to break the audio such as deliberate impedance mismatch, extremely low signalling voltage levels etc.
The S/PDIF interfacing circuit uses transformers, RS422 receiver and line drivers with proper termination. It measures well on an oscilloscope, but the performance remained the same (no better or worse) on boards that were modified to bypass all the active electronics. An experiment with a direct 3.3V TTL connection between the two chips with only a series capacitor did not fare any better. The boards will be modified to experiment with optical connections but the evidence so far makes it fairly certain that the problem is not the medium.
Breaks have been confirmed to get worse during access to the core, such as a continuous register read. The I2C bus doesn't run close or underneath any of the sensitive electronics though. Once again, with 3rd party sources or sinks it's almost impossible to break the audio.
When using a tone generator in each board and monitoring the received audio on both boards, breaks are observed in both and uncorrelated to each other, although occasionally breaks are perfectly synchronized on both.
Another experiment where the two boards' DSP's were synchronized to the other by using the same MCLK for both yielded no improvement. A next experiment can be to use an external I2S-SPDIF transmitter or receiver, but as there are >1000boards in the field by the time this bug got discovered it would serve little purpose as it is too complex for a field/recall modification.
Any input would be appreciated.
Audio Signal Processors
adau1442
SigmaDSP Audio Processors
Hello WattsAUD,
Hmm... Can you send over your hardware schematic of your SPDIF interface?
How are the DUT boards grounded? What kind of power supplies are you using to power them?
I can look into this further tomorrow.
Dave T
Hello Dave,
I'll prepare a schematic with the relevant parts tomorrow, but since the results were fairly consistent regardless of what method was used I think the problem already exists inside the DSP with it being affected either by power or clock contamination. It's just very strange how all the other interfaces work perfectly while inter-S/PDIF does not.
Each board is powered by a 12V isolated switching brick for testing, or bench supplies. In field applications they are powered by a class D amplifier that also uses an isolated flyback power supply for the digital front-end. The DUT's are mounted on a metal substrate that's connected to safety ground though, and the safety ground at the mounting holes and metal plugs (Ethernet etc.) are connected to signal ground at one position.
The incoming 12V is dropped to 5V with a TPS62143 and from there it is dropped to 3.3V and 1.8V (and all the other system voltages) with AUR9718B and TPS62095. The 1.8V has a heavy current draw from the shared CPU DDR2 bus, but measurements do not show anything untoward.
I have found that an older revision that uses different regulators are better behaved (still drops but about 70% less). This version had less other peripherals on the board though so it's not easy to exactly pin-point the cause.
I have also just hooked up a little testboard using a DIT4192 as I2S->S/PDIF transmitter to another DUT and the results are the same. The wiring is not exactly optimal so it's not a conclusive experiment though.
Tomorrow I shall try using optical interfaces just as sanity-check. I will also try to disable the ARM CPU to see if the reduced load on the DSP's power rails make any difference.
Thanks for the assistance, please ask if there are any other measurements or experiments to be done.
Regards,
Pierre
Hello Dave,
I have done two more experiments:
1) Holding the main ARM CPU in reset after the DSP is programmed to evaluate the effect of the shared power rails
2) Modifying the two boards to use optical connections
Both of these yield no difference so electrical issues with the coax interfaces can probably be discarded. The optical interfaces are hooked up with 5cm wire wrap and are lacking the usual LC filter but based on experience this should not be the cause.
One other interesting factor: behaviour always starts off well when the boards are cold, and then progressively gets worse as they heat up. Board temperature at equilibrium is only 10degrees above ambient so nothing big.
I am now at at point where I do not know what else to investigate. I will do a direct I2S-I2S test between two boards still, but the S/PDIF interfaces itself are leaving me stumped. With all that got rued out the differences to the AD EVM are on a level where it should not matter.
Any further testing instructions would please be appreciated.
Regards,
Pierre
Hello Pierre,
What revision and data code are the two evaluation boards? The date code is usually near the part number of the board. You can take a picture if you like.
Dave T
Hello Dave,
Perhaps a bit of a misunderstanding: we only have 1x evaluation board, together then with various revisions of our own custom product (i.e. DUT). I have confirmed that the EVM works fine as both transmitter and receiver to a DUT (same as with other 3rd party receivers/transmitters), but the problem is always related to 2x DUT's.
I can confirm the date of the EVM later today, but it dates from around 2010. The breaks are confirmed on DUT's with DSP's ordered from Avnet ranging between early 2014-2017.
Has there perhaps been a silicon revision? I still need to do the I2S-I2S experiment, but can also as an extreme test replace the DSP chip on our EVM with a new one to see if that causes breaks.
Regards,
Pierre
Hello Dave,
Date code of our EVM (EVAL-ADAU1442EBZ REV C) is 080926_02.
As update, I have tested a direct I2S connection between two DUT's (asynchronous via an ASRC on the receiving DUT), and it works fine without breaks.
To summarize therefore:
- 3rd party S/PDIF source (incl. EVM) to DUT input: breaks
- 3rd party S/PDIF sink (incl. EVM) from DUT output: breaks
- DUT1 to DUT2 via S/PDIF (regardless of whether optical, transformer-isolated or direct TTL): breaks
- Repeating test above with synchronized MCK for both DUT's: breaks
- Driving other circuits on board into reset to minimize PSU ripple & EMI: no effect
- Touching or probing various sensitive nodes such as PLL filter or S/PDIF TTL pins: no effect
- DUT to the same DUT via loopback cable: OK
- DUT1 to DUT2 via I2S: OK
- DUT1 via I2S->S/PDIF transmitter to DUT2 S/PDIF input: breaks (test is inconclusive though due to sub-optimal wiring)
- Period between breaks increase with temperature. At cold start the first break can take >10minutes to occur and then progressively increases until plateauing after about 30minutes.
- On a break-prone setup, access to the DSP core has been found to correlate with a break event
- For a bidirectional setup of 2x DUT's with each both transmitting & receiving S/PDIF, breaks mostly occur independently on both, but approx. 30% of the time a break will be perfectly synchronized on both.
One theory why a connection between EVM and DUT is fine could be because the EVM does not get as hot as our DUT due to the EVM's larger board size and less peripheral components. I can experiment with heating of the the EVM and cooling of the DUT's, or perhaps replacing the DSP of the EVM with a new one if there has been a silicon change. I am also considering making a small plug-in PCB with both an external receiver and transmitter for our DUT's expansion port to have proper signal integrity, but this is a time-consuming experiment.
Is there anything else we can test? This is getting a serious matter considering how many boards we have in the field.
Regards,
Pierre
Hello Pierre,
I will take this off-forum since I would like to see much more detail about your product so I will contact you about this.
Dave T
Hello Dave, very well, looking forward to your response.
Regards,
Pierre
Please log in to reply.