U16 slice kit - will lock to optical but not coax?! Topic is solved

[bowerymarc]

I'm using the U16 slice kit and for some reason it's not locking to the coax input, but is to the optical.

I'm switching by commenting/uncommenting the lines in xp-skc-u16-audio8.xn:

Code: Select all

            <Port Location="XS1_PORT_1C"  Name="PORT_SPDIF_IN"/>     <!-- COAX -->
<!--            <Port Location="XS1_PORT_1C"  Name="PORT_ADAT_IN"/>   -->  <!-- COAX -->
       	<Port Location="XS1_PORT_1G"  Name="PORT_ADAT_IN"/>         <!-- OPT -->
<!--              <Port Location="XS1_PORT_1G"  Name="PORT_SPDIF_IN"/>    -->    <!-- OPT -->

(so that's for coax)

I'm using the same interface to drive both - scoping X0D10 and X0D22 show the signals are in excellent condition going to the xmos chip.

But, in the core audio audio-midi control panel when I select SPDIF clock, if it's compiled for coax, it immediately switches back to internal, whereas if compiled for optical, it will stick on SPDIF clock and lock OK. What am I missing?

I'm using USB-Audio-2.0-Device-Software_6.12.6 - haven't updated to 6.15 yet.

[infiniteimprobability]

All look sensible. It literally is just a re-mapping the I/O so what you have done is correct.

The clock will automatically disable if it sees a sample rate outside of the nominal ones (44.1, 48 etc.) so that suggests an invalid SPDIF stream coming in.

Do you get sound coming out? Even if the clock hasn't locked, you should still hear the samples (although the buffers will over/undeflow periodically).

Optical input is only reliable up to 96KHz. TOSLINK isn't specified to go higher than that, so try at lowest rates first.

[bowerymarc]

The clock will automatically disable if it sees a sample rate outside of the nominal ones (44.1, 48 etc.) so that suggests an invalid SPDIF stream coming in.

Yes it does suggest that, but as I said, it's the same interface driving both. I've tried both a custom built interface, where the coax and optical are actually driven by the same electrical signal (running at 48KHz) and currently, a Lexicon 20/20 A/D converter, which has one of the most accurate to spec SPDIF implementations I've ever seen.

Do you get sound coming out? Even if the clock hasn't locked, you should still hear the samples (although the buffers will over/undeflow periodically).

Yes, get sound out.

Optical input is only reliable up to 96KHz. TOSLINK isn't specified to go higher than that, so try at lowest rates first.

Check the thread title... TOSLINK is the one that's working! It's the Coax that's broken - the clock select in the audioMedia control panel keeps flipping back to internal.

I'm running at 44.1KHz, and does the same at 48KHz, two different interfaces as noted above.

btw - there are now optical parts that support 25Mbps so should be able to do 192K - check out DLR2140 and DLT2140A from Aixin.

edit - I forgot to add, I have checked the frequency accuracy of the Lexicon 20/20 with a high resolution frequency counter... 44100.01 Hz.

[bowerymarc]

I wonder if my XP-SKC-U16 board has X0D10 pin on the XMOS blown? Because when I 'scope the D10 test point on the board (which I believe is post-mux, right on the XMOS pin) the signal looks pristine.

Can someone verify that this should work on this hardware setup?

thanks!

[bowerymarc]

update - the test points are pre-mux. The file slicekit_slicecard_init.S appears to be setting the mux to allow use of the GPIO (disabling the EEPROM SPI), but on my board, at least, it seems something happens on X0D15 to clock this crazy latch circuit on the slice U16 board to select SPI incorrectly, and once it clocks once that's it til next reset. It appears there is a + glitch on X0D15 well before the main clock pulse generated within slickest_slicecard_init.S that is high enough (it's about 800-900mV) to cause the D-flop to clock. So, no matter what the SPI bus is selected, since it doesn't matter what the assembly routine does later, there's no way to re-clock the flop. Totally crazy.

[infiniteimprobability]

Hmm - that's not great is it..

I remember that circuit was designed so that you could flip the mux to be able to use the SPI flash pins for user functions and then be able to reuse the 8b port too after making the selection. The older slice kits used a DFF so you could select dynamically, but you lost 2 port pins.

It sounds like noise is getting into that circuit meaning the one time shot is already spent by the time you get to run any code.

Not sure how you were getting audio coming through when it wasn't selected? Anyhow, sounds like a HW issue - are you able to lift a leg on the mux or add a cap to suppress that initial glitch?

[bowerymarc]

Hmm - that's not great is it..

spending weeks on this is less than great

It sounds like noise is getting into that circuit meaning the one time shot is already spent by the time you get to run any code.

it looks like it's happening when the chip is starting up from the debugger or thereabouts.

Not sure how you were getting audio coming through when it wasn't selected?

From the optical port, which doesn't go thru the mux. Ergo the title of this thread...

Anyhow, sounds like a HW issue - are you able to lift a leg on the mux or add a cap to suppress that initial glitch?

I would love it if someone from XMOS would verify if this hardware ever worked, whether I got a dud board that should be replaced, or whether this ever worked at all. I don't want to get into debugging XMOS's dev kits. I'm being paid a flat fee for this gig and right now, I could be flipping burgers for more money considering how much time I've spend chasing this issue.

[infiniteimprobability]

spending weeks on this is less than great

I can only apologise an empathise as a development engineer how annoying issues like this can be..

I would love it if someone from XMOS would verify if this hardware ever worked, whether I got a dud board that should be replaced, or whether this ever worked at all. I don't want to get into debugging XMOS's dev kits. I'm being paid a flat fee for this gig and right now, I could be flipping burgers for more money considering how much time I've spend chasing this issue.

I haven't used this kit for a long time (the recommended kit these days is https://www.xmos.com/support/boards?product=18334 which thankfully has no pin muxing) so will check with colleagues.

[bowerymarc]

So... I got my prototype hardware in so I'm not spending more time on this dev board. Just to wrap up, the answer to this is, the optical and switch inputs won't work unless you modify the main PCB - lift the part driving the signal and put in the resistor, to control it but sacrifice an XMOS pin for that dedicated function, or solder a wire high or low to permanently enable/disable the eeprom.