S/PDIF input ramp not detected

[danielpieczko]

App: xk_316_mc Config: 2ASi10o10xssxxx

The S/PDIF input test fails with no ramp detected on either channel:

E           Failed: Checking analyser output failed:
E           No ramp seen on channel 8
E           No ramp seen on channel 9

This was originally seen in the nightly tests a couple of times across a few weeks, where it has only occurred on this config. It only happens infrequently, so I have been trying to reproduce it by repeatedly running lots of 15s input tests with this config and can currently reproduce it within three hours.

[danielpieczko]

Also seen regularly with xk_316_mc config 2AMi10o10xssxxx.

The test does the following:

1. start xk_316_mc app
2. start audio analyzer S/PDIF tx and set the sample rate
3. change the clock source on the host using volcontrol app

Reproduced this state in a test and kept the device running. On the Mac host, the device appears with zero channels in and out.

Application thread/register dumps from four separate instances of this issue: dump_state0.txt dump_state1.txt dump_state2.txt dump_state3.txt

Threads that are in the same place across these dumps:

• thread 3 AudioClassRequests_2, waiting for the response to GET_VALID from the clockgen thread
• thread 4 i2c_master (I think this is just waiting because there is no i2c activity, so probably irrelevant)
• thread 6 XUD
• thread 11 AudioHub, not sure what's happening here, looks like it's stuck in InitPorts_master
• thread 12 mixer

Working theory is that the S/PDIF rx is starving the clockgen thread or that a transaction on the c_clk_ctl channel has been lost.

I'll attach a USB capture if I can reproduce this with the analyzer attached.

[danielpieczko]

Here's a USB trace when it gets into this state no_channels_usb_capture.zip

The S/PDIF input signal was fine - verified by moving the cable (while the analyzer was still running) to another board on a separate host and checking that the clock was valid and the ramp was correct.

[xross]

https://github.com/xmos/lib_xua/blob/eee5b474a009b2b96bb108971097b5591834bd7a/lib_xua/src/core/endpoint0/xua_ep0_uacreqs.xc#L476 relates to the interrogation of the ADAT clock source, which seems odd? I would expect the access of the clockValid[] array to go out of bounds at this point? Perhaps there is an issue with the line numbers from the debugger as I wouldn't expect the ADAT clock to be exposed in the descriptors to the host in this S/PDIF build config.

[danielpieczko]

Not sure if this is a distraction, or maybe it will be useful, but I'll add another observation.

I saw one case that had the same symptom of no S/PDIF input ramp being detected, but the problem wasn't that the host saw zero channels, but that the host reported an error for an invalid sample rate when running xsig.

The underlying issue could be the same, so maybe this will provide some useful evidence. Here is the dump state and USB protocol capture: dump_state_invalid_samp_freq.txt invalid_samp_freq.zip

[xross]

@danielpieczko can you confirm the source you are using you are using for testing matches https://github.com/xmos/lib_xua/blob/eee5b474a009b2b96bb108971097b5591834bd7a/lib_xua/src/core/endpoint0/xua_ep0_uacreqs.xc#L476

I feel that the reported line should actually be 462, otherwise it doesn't make a lot of sense to me. Also, inspecting the USB trace shows the host only iterrogating the clock unit with the ID 42 (which the clock unit relating to the SPDIF clock) further indicating L476 is a red herring.

[xross]

Another thing that would be useful to know, is the output clock to the CS2100 still running in this state? The test point is PLL_SYNC on J43. It should have a 300Hz signal on it.

Another potential cause of this issue is maxing out the number of routes through the switch.

[danielpieczko]

The ID_CLKSRC_SPDIF/ADAT discrepancy is just a line number mistake. My source matches the head of develop in lib_xua. More conclusively from the disassembly of the app, register r7 holds the unitID variable, which we can see in the register dump is 42 (ID_CLKSRC_SPDIF).

[danielpieczko]

I checked the PLL_SYNC test point on J43 and it had no signal.

[xross]

My leading theory now relates to too many routes open across the switch, we should manually consider code/comms arrangements for the 316 board to make sure we are happy with this.

To help this investigation, when the device is in this state can we attach xgdb and do source "xlreg2.txt"

xlreg2.txt

[henkmuller]

Just thinking - given this is a 2-tile device, you are really interested in whether you have ran out of PLINKS; check that that is in xlreg2.txt (which may be mostly xlink focussed which was good for the XS1-L2)

[danielpieczko]

(gdb) source xlreg2.txt
Tap 0, mux 1, reg 0 0x00070002
        Node id 0x8002
        PLL reg 0xc0003100: od 0 f 49 r 0 ratio 25.000000 (600 @ 24 Mhz)
        Sec reg 0x00000000
        Sys Clock reg 0x00000000
        Node COnf reg 0x00000000
  Dirs: 1111111111111101
  PLink 0 EN:  d:0  siu:T diu:T dest (16..23): 7   desttyp (24..25): 1
  PLink 1 EN:  d:0  siu:F diu:F dest (16..23): 0   desttyp (24..25): 0
  PLink 2 EN:  d:0  siu:F diu:F dest (16..23): 0   desttyp (24..25): 0
  PLink 3 EN:  d:0  siu:T diu:F dest (16..23): 5   desttyp (24..25): 1
  PLink 4 EN:  d:0  siu:F diu:F dest (16..23): 0   desttyp (24..25): 0
  PLink 5 EN:  d:0  siu:F diu:T dest (16..23): 0   desttyp (24..25): 0
  PLink 6 EN:  d:0  siu:T diu:F dest (16..23): 0   desttyp (24..25): 1
  PLink 7 EN:  d:0  siu:F diu:T dest (16..23): 0   desttyp (24..25): 0
  Link 0 EN: 2w 4/4 d:0 snd:F rec:F siu:F diu:F
  Link 1 not enabled
  Link 2 not enabled
  Link 3 not enabled
  Link 4 not enabled
  Link 5 not enabled
  Link 6 not enabled
  Link 7 not enabled
  Link 8 not enabled
Tap 0, mux 2, reg 0 0x02800400
        Node id 0x0003
        PLL reg 0x00000063: od 0 f 0 r 99 ratio 0.005000 (0 @ 24 Mhz)
        Sec reg 0x00000000
        Sys Clock reg 0x00000000
        Node COnf reg 0x00000000
  Dirs: 0000000000000000
  PLink 0 EN:  d:0  siu:F diu:F dest (16..23): 240   desttyp (24..25): 3
  PLink 1 EN:  d:39  siu:F diu:F dest (16..23): 8   desttyp (24..25): 0
  PLink 2 EN:  d:46  siu:F diu:F dest (16..23): 8   desttyp (24..25): 0
  PLink 3 EN:  d:55  siu:F diu:F dest (16..23): 8   desttyp (24..25): 0
  PLink 4 EN:  d:25  siu:F diu:F dest (16..23): 8   desttyp (24..25): 0
  PLink 5 EN:  d:104  siu:F diu:F dest (16..23): 8   desttyp (24..25): 0
  PLink 6 EN:  d:34  siu:F diu:F dest (16..23): 8   desttyp (24..25): 0
  PLink 7 EN:  d:0  siu:F diu:F dest (16..23): 8   desttyp (24..25): 0
  Link 0 not enabled
  Link 1 not enabled
  Link 2 not enabled
  Link 3 not enabled
  Link 4 not enabled
  Link 5 not enabled
  Link 6 not enabled
  Link 7 not enabled
  Link 8 not enabled

[henkmuller]

My reading of this is as follows::

PLink 0 EN: d:0 siu:T diu:T dest (16..23): 7 desttyp (24..25): 1 PLink 3 EN: d:0 siu:T diu:F dest (16..23): 5 desttyp (24..25): 1 PLink 5 EN: d:0 siu:F diu:T dest (16..23): 0 desttyp (24..25): 0 PLink 6 EN: d:0 siu:T diu:F dest (16..23): 0 desttyp (24..25): 1 PLink 7 EN: d:0 siu:F diu:T dest (16..23): 0 desttyp (24..25): 0

Plink 0 is ENABLED, in-use-as-a-source is True, in-use-as-a-destination is True, the destination for the in-use-as-a-source is 7, and it is destination-type 1 (PLINK).

Hence:

• PL0 is sending data to PL7 [Core 0 to Core 1]
• PL3 is sending data to PL5 [Core 0 to Core 1]
• PL6 is sending data to PL0 [Core 1 to Core 0]

Out of the 16 half-links (4 in and 4 out on each core), 6 are in use and 10 are not in use; so it isn't hung up on a lack of bandwidth inside the switch. More likely it has hung up in the processor.

If that is the case, the next thing to do is to get the PS register value for each of the channel ends CTRL0 and DATA register. That is, getps[0x8002KKZ2], for 0 <= KK <= 0x20. and for Z = {0, 5}. The DATA register will tell us what the destination is for each channel end; the CTRL0 register tells us who is blocked::

resreg 0 0x0x8002KKZ2 0 print $resregval

I believe...

[note from @xross, core = tile in this comment]

[danielpieczko]

0x80020002 0x04040027
0x80020052 0x80030002
0x80020102 0x00000001
0x80020152 0x80030102
0x80020202 0x00000005
0x80020252 0x80030202
0x80020302 0x02020001
0x80020352 0x80030302
0x80020402 0x00060005
0x80020452 0x80030402
0x80020502 0x01010005
0x80020552 0x80030d02
0x80020602 0x03030105
0x80020652 0x80030d02
0x80020702 0x05020001
0x80020752 0x80020802
0x80020802 0x02060005
0x80020852 0x80020702
0x80020902 0x05020001
0x80020952 0x80020a02
0x80020a02 0x02060001
0x80020a52 0x80020902
0x80020b02 0x05050007
0x80020b52 0x80020c02
0x80020c02 0x02020001
0x80020c52 0x80020b02
0x80020d02 0x05020001
0x80020d52 0x80020e02
0x80020e02 0x02060005
0x80020e52 0x80020d02
0x80020f02 0x05020001
0x80020f52 0x80021002
0x80021002 0x02060005
0x80021052 0x80020f02
0x80021102 0x05020001
0x80021152 0x80021202
0x80021202 0x02060001
0x80021252 0x80021102
0x80021302 0x05050007
0x80021352 0x80021402
0x80021402 0x02020001
0x80021452 0x80021302
0x80021502 0x04060005
0x80021552 0x80021602
0x80021602 0x02020021
0x80021652 0x80021502
0x80021702 0x05050000
0x80021752 0x00000000
0x80021802 0x00000000
0x80021852 0x00000000
0x80021902 0x00000000
0x80021952 0x00000000
0x80021a02 0x00000000
0x80021a52 0x00000000
0x80021b02 0x00000000
0x80021b52 0x00000000
0x80021c02 0x00000000
0x80021c52 0x00000000
0x80021d02 0x00000000
0x80021d52 0x00000000
0x80021e02 0x00000000
0x80021e52 0x00000000
0x80021f02 0x00000004
0x80021f52 0x00000000
0x80022002 0x00000000
0x80022052 0x00000000

[henkmuller]

Channel end CTRL0         Destination 
0x80020002 0x04040027 0x80030002 IE INW  T=4           Waiting for 0x80030002
0x80020102 0x00000001 0x80030102
0x80020202 0x00000005 0x80030202 EE
0x80020302 0x02020001 0x80030302
0x80020402 0x00060005 0x80030402 EE      T=6
0x80020502 0x01010005 0x80030d02 EE      T=1
0x80020602 0x03030105 0x80030d02 EE EVAL T=3
0x80020702 0x05020001 0x80020802         INT=2 OUTT=5  INTERNAL
0x80020802 0x02060005 0x80020702         INT=6 OUTT=2  INTERNAL
0x80020902 0x05020001 0x80020a02         INT=2 OUTT=5  INTERNAL
0x80020a02 0x02060001 0x80020902         INT=6 OUTT=2  INTERNAL
0x80020b02 0x05050007 0x80020c02 IE      T=5           INTERNAL
0x80020c02 0x02020001 0x80020b02         T=2           INTERNAL
0x80020d02 0x05020001 0x80020e02         INT=2 OUTT=5  INTERNAL
0x80020e02 0x02060005 0x80020d02         INT=6 OUTT=2  INTERNAL
0x80020f02 0x05020001 0x80021002         INT=2 OUTT=5  INTERNAL
0x80021002 0x02060005 0x80020f02 EE      INT=6 OUTT=2  INTERNAL
0x80021102 0x05020001 0x80021202         INT=2 OUTT=5  INTERNAL
0x80021202 0x02060001 0x80021102         INT=6 OUTT=2  INTERNAL
0x80021302 0x05050007 0x80021402 IE      T=5           INTERNAL
0x80021402 0x02020001 0x80021302         T=2           INTERNAL
0x80021502 0x04060005 0x80021602 EE      INT=6 OUTT=4  INTERNAL
0x80021602 0x02020021 0x80021502    INW  T=2           INTERNAL Waiting for 0x80021502? Thread 4?

It seems thread 2 is waiting for thread 4, through channel 0x80021502 <-> 0x80021602 Thread 4 is waiting for the other tile through 0x80020002 <-> 0x80030002

If we do the same for the other tile (using channel ends 0x8003XXZ2 on core 1 rather than 0) we should find who thread 4 is waiting for.

We don't know for sure that thread 4 is waiting for 0x80030002; it depends on channel ends pointing to each other: the output knows the destination of the input but not the other way around

[danielpieczko]

Channel end CTRL0     Destination
0x80020002 0x04040007 0x80030002
0x80020102 0x00000001 0x80030102
0x80020202 0x00000005 0x80030202
0x80020302 0x02020021 0x80030302
0x80020402 0x00060005 0x80030402
0x80020502 0x01010025 0x80030d02
0x80020602 0x03030105 0x80030d02
0x80020702 0x05020001 0x80020802
0x80020802 0x02060005 0x80020702
0x80020902 0x05020001 0x80020a02
0x80020a02 0x02060001 0x80020902
0x80020b02 0x05050007 0x80020c02
0x80020c02 0x02020001 0x80020b02
0x80020d02 0x05020001 0x80020e02
0x80020e02 0x02060005 0x80020d02
0x80020f02 0x05020001 0x80021002
0x80021002 0x02060005 0x80020f02
0x80021102 0x05020001 0x80021202
0x80021202 0x02060001 0x80021102
0x80021302 0x05050007 0x80021402
0x80021402 0x02020001 0x80021302
0x80021502 0x04060005 0x80021602
0x80021602 0x02020001 0x80021502
0x80021702 0x05050000 0x00000000
0x80021802 0x00000000 0x00000000
0x80021902 0x00000000 0x00000000
0x80021a02 0x00000000 0x00000000
0x80021b02 0x00000000 0x00000000
0x80021c02 0x00000000 0x00000000
0x80021d02 0x00000000 0x00000000
0x80021e02 0x00000000 0x00000000
0x80021f02 0x00000004 0x00000000
0x80022002 0x00000000 0x00000000

0x80030002 0x04040007 0x80030002
0x80030102 0x00000001 0x80030102
0x80030202 0x00000005 0x80030202
0x80030302 0x02020021 0x80030302
0x80030402 0x00060005 0x80030402
0x80030502 0x01010025 0x80030d02
0x80030602 0x03030105 0x80030d02
0x80030702 0x05020001 0x80020802
0x80030802 0x02060005 0x80020702
0x80030902 0x05020001 0x80020a02
0x80030a02 0x02060001 0x80020902
0x80030b02 0x05050007 0x80020c02
0x80030c02 0x02020001 0x80020b02
0x80030d02 0x05020001 0x80020e02
0x80030e02 0x02060005 0x80020d02
0x80030f02 0x05020001 0x80021002
0x80031002 0x02060005 0x80020f02
0x80031102 0x05020001 0x80021202
0x80031202 0x02060001 0x80021102
0x80031302 0x05050007 0x80021402
0x80031402 0x02020001 0x80021302
0x80031502 0x04060005 0x80021602
0x80031602 0x02020001 0x80021502
0x80031702 0x05050000 0x00000000
0x80031802 0x00000000 0x00000000
0x80031902 0x00000000 0x00000000
0x80031a02 0x00000000 0x00000000
0x80031b02 0x00000000 0x00000000
0x80031c02 0x00000000 0x00000000
0x80031d02 0x00000000 0x00000000
0x80031e02 0x00000000 0x00000000
0x80031f02 0x00000004 0x00000000
0x80032002 0x00000000 0x00000000

[danielpieczko]

Not sure if there's something wrong with my debug ... the two sets of values look the same other than the 0x8002XXXX and 0x8003XXXX.

[henkmuller]

I think you need to change the first argument from ‘0’ to ‘1'; otherwise it will interrogate the same core. It probably ignores the first 16 bits (node id) when reading the PS values.

[danielpieczko]

I think this looks better...

Channel end CTRL0     Destination
0x80020002 0x04040007 0x80030002
0x80020102 0x00000001 0x80030102
0x80020202 0x00000005 0x80030202
0x80020302 0x02020021 0x80030302
0x80020402 0x00060005 0x80030402
0x80020502 0x01010005 0x80030d02
0x80020602 0x03030105 0x80030d02
0x80020702 0x05020001 0x80020802
0x80020802 0x02060005 0x80020702
0x80020902 0x05020001 0x80020a02
0x80020a02 0x02060001 0x80020902
0x80020b02 0x05050007 0x80020c02
0x80020c02 0x02020001 0x80020b02
0x80020d02 0x05020001 0x80020e02
0x80020e02 0x02060005 0x80020d02
0x80020f02 0x05020001 0x80021002
0x80021002 0x02060005 0x80020f02
0x80021102 0x05020001 0x80021202
0x80021202 0x02060005 0x80021102
0x80021302 0x05050007 0x80021402
0x80021402 0x02020001 0x80021302
0x80021502 0x04060005 0x80021602
0x80021602 0x02020001 0x80021502
0x80021702 0x05050000 0x00000000
0x80021802 0x00000000 0x00000000
0x80021902 0x00000000 0x00000000
0x80021a02 0x00000000 0x00000000
0x80021b02 0x00000000 0x00000000
0x80021c02 0x00000000 0x00000000
0x80021d02 0x00000000 0x00000000
0x80021e02 0x00000000 0x00000000
0x80021f02 0x00000004 0x00000000
0x80022002 0x00000000 0x00000000

0x80030002 0x04040001 0x80020002
0x80030102 0x00000001 0x80020102
0x80030202 0x00000015 0x80020202
0x80030302 0x00000015 0x80020302
0x80030402 0x00000001 0x80020402
0x80030502 0x00000001 0x80020502
0x80030602 0x00000001 0x80020602
0x80030702 0x04040021 0x80030802
0x80030802 0x03030001 0x80030702
0x80030902 0x03030011 0x80030a02
0x80030a02 0x00000005 0x80030902
0x80030b02 0x00020021 0x80030c02
0x80030c02 0x03000001 0x80030b02
0x80030d02 0x00000001 0x80020502
0x80030e02 0x00000000 0x00000000
0x80030f02 0x00000000 0x00000000
0x80031002 0x00000000 0x00000000
0x80031102 0x00000000 0x00000000
0x80031202 0x00000000 0x00000000
0x80031302 0x00000000 0x00000000
0x80031402 0x00000000 0x00000000
0x80031502 0x00000000 0x00000000
0x80031602 0x00000000 0x00000000
0x80031702 0x00000000 0x00000000
0x80031802 0x00000000 0x00000000
0x80031902 0x00000000 0x00000000
0x80031a02 0x00000000 0x00000000
0x80031b02 0x00000000 0x00000000
0x80031c02 0x00000000 0x00000000
0x80031d02 0x00000000 0x00000000
0x80031e02 0x00000000 0x00000000
0x80031f02 0x00000000 0x00000000
0x80032002 0x00000000 0x00000000

[henkmuller]

Core 0
Channel end CTRL0         Destination 
0x80020002 0x04040027 0x80030002 IE INW  T=4           Waiting for 0x80030002 C1T4
0x80020102 0x00000001 0x80030102         T=0
0x80020202 0x00000005 0x80030202 EE      T=0
0x80020302 0x02020001 0x80030302         T=2
0x80020402 0x00060005 0x80030402 EE      T=6
0x80020502 0x01010005 0x80030d02 EE      T=1
0x80020602 0x03030105 0x80030d02 EE EVAL T=3
0x80020702 0x05020001 0x80020802         INT=2 OUTT=5  INTERNAL
0x80020802 0x02060005 0x80020702         INT=6 OUTT=2  INTERNAL
0x80020902 0x05020001 0x80020a02         INT=2 OUTT=5  INTERNAL
0x80020a02 0x02060001 0x80020902         INT=6 OUTT=2  INTERNAL
0x80020b02 0x05050007 0x80020c02 IE      T=5           INTERNAL
0x80020c02 0x02020001 0x80020b02         T=2           INTERNAL
0x80020d02 0x05020001 0x80020e02         INT=2 OUTT=5  INTERNAL
0x80020e02 0x02060005 0x80020d02         INT=6 OUTT=2  INTERNAL
0x80020f02 0x05020001 0x80021002         INT=2 OUTT=5  INTERNAL
0x80021002 0x02060005 0x80020f02 EE      INT=6 OUTT=2  INTERNAL
0x80021102 0x05020001 0x80021202         INT=2 OUTT=5  INTERNAL
0x80021202 0x02060001 0x80021102         INT=6 OUTT=2  INTERNAL
0x80021302 0x05050007 0x80021402 IE      T=5           INTERNAL
0x80021402 0x02020001 0x80021302         T=2           INTERNAL
0x80021502 0x04060005 0x80021602 EE      INT=6 OUTT=4  INTERNAL
0x80021602 0x02020021 0x80021502    INW  T=2           INTERNAL Waiting for 0x80021502 C0T4

Core 1
Channel end CTRL0         Destination 
0x80030002 0x04040001 0x80020002        T=4
0x80030102 0x00000001 0x80020102        T=0
0x80030202 0x00000015 0x80020202 EE INR T=0           data waiting from C0T0
0x80030302 0x00000015 0x80020302 EE INR T=0           data waiting from C0T2
0x80030402 0x00000001 0x80020402        T=0
0x80030502 0x00000001 0x80020502        T=0
0x80030602 0x00000001 0x80020602        T=0
0x80030702 0x04040021 0x80030802    INW T=4           INTERNAL, waiting for C1T3 to output?
0x80030802 0x03030001 0x80030702        T=3           INTERNAL
0x80030902 0x03030011 0x80030a02    INR T=3           INTERNAL, data waiting from  C1T0
0x80030a02 0x00000005 0x80030902 EE     T=0           INTERNAL
0x80030b02 0x00020021 0x80030c02    INW INT=2 OUTT=0  INTERNAL Waiting for  C1T3 to output?
0x80030c02 0x03000001 0x80030b02        INT=0 OUTT=3  INTERNAL
0x80030d02 0x00000001 0x80020502        T=0

I think that leads to:

• C0T2 is waiting for C0T4
• C0T4 is waiting for C1T4
• C1T0 has data waiting from C0T0 and C0T2
• C1T2 is waiting for C1T3
• C1T4 is waiting for C1T3
• C1T3 has data from C1T0 that is unread

C1T3 seems to be the key to unlocking this; what instruction is it hanging on?

[danielpieczko]

It's a syncr instruction.

Thread 11 (tile[1] core[3] (dual issue)):

***** Call Stack *****
#0  InitPorts_master (divide=545520, p_lrclk=65536, p_bclk=<value optimized out>, p_i2s_dac=@0x852e0, p_i2s_adc=@0x852f0) at /Users/jenkins/daniel/usb_audio/lib_xua/lib_xua/src/core/audiohub/audiohub_initport.xc:42
#1  0x00081164 in XUA_AudioHub (c_aud=2147682306, clk_audio_mclk=<value optimized out>, clk_audio_bclk=774, p_mclk_in=66304, p_lrclk=<value optimized out>, p_bclk=<value optimized out>, p_i2s_dac=<value optimized out>, p_i2s_adc=<value optimized out>, c_spdif_out=<value optimized out>, c_dig_rx=<value optimized out>) at /Users/jenkins/daniel/usb_audio/lib_xua/lib_xua/src/core/audiohub/xua_audiohub.xc:259
#2  0x00080d35 in _Susb_audio_io_0.task.XUA_AudioHub.2 (frame=<value optimized out>) at /Users/jenkins/daniel/usb_audio/lib_xua/lib_xua/src/core/main.xc:472
#3  0x00083e78 in __start_core ()

***** Disassembly *****
0x80e88 <InitPorts_master+64>:  syncr (1r)      res[r1] *
0x80e8a <InitPorts_master+66>:  nop (0r)
0x80e8c <InitPorts_master+68>:  getts (2r)      r11, res[r1]
0x80e8e <InitPorts_master+70>:  nop (0r)
0x80e90 <InitPorts_master+72>:  ldc (lru6)      r4, 0x64

[henkmuller]

That is waiting for a clock edge (or ready signal)? Is there a chicken-and-egg thing about the clock not having started yet?

[xross]

That is waiting for a clock edge (or ready signal)? Is there a chicken-and-egg thing about the clock not having started yet?

This I2S core has paused setting up the ports due to no MCLK. This setup is happening due to a SR change request from the host just prior to its get_valid() check on the SPDIF clock source.

My guess is that there is no MCLK because the ClockGen() core along with the PllRefPinTask() core have stopped operating. Between the two of them they drive the reference signal to the CS2100, which in turn drives the MCLK signal.

It should be noted that PllRefPinTask() is a relatively new core added since the sync pin to the CS2100 is no longer on the same tile as the ClockGen() thread on the 316 board. Comms between the two are via an XC interface (such that on the 216 it can easily be "distributed" back into the ClockGen() core.

The "dumpstates" seem to show the PllRefPinTalk() sitting on a waiteu whilst ClockGen() since on an in (or chkct) on the channel communicating between the two. Though "dump_state1.txt" shows slightly different states.

[xross]

* C0T2 is waiting for C0T4

* C0T4 is waiting for C1T4

* C1T0 has data waiting from C0T0 and C0T2

* C1T2 is waiting for C1T3

* C1T4 is waiting for C1T3

* C1T3 has data from C1T0 that is unread

Translation:

• Endpoint0() is waiting for Decouple()
• Decouple() is waiting for mixer()
• ClockGen() has data waiting from SpdifReceive() and Endpoint0()
• SpdifTransmit() is waiting for AudioHub()
• AudioHub() has data from ClockGen() that is unread

[danielpieczko]

I haven't been able to reproduce this since #136 was merged.

[xross]

This missing delay was certainly important, however, I'm still at a loss to explain this lock-up - unless the various debugging information attached to this issue is misleading (errors in usb tracing etc).

[xross]

Closing since not been able to reproduce since #136