USB reference design and SPDif

Technical discussions related to any XMOS development kit or reference design. Eg XK-1A, sliceKIT, etc.
User avatar
RemcoW
Member
Posts: 10
Joined: Tue Jan 15, 2013 9:00 pm

USB reference design and SPDif

Postby RemcoW » Tue Jan 15, 2013 9:48 pm

We've roughly based our design on the L2 reference design, getting rid of some of its features we didn't need, changing out the clocking mechanism, replacing it with a low jitter clock and algorithm. We've also changed the DAC and some back end stuff.
It seems to work very well and sound great except that I can't seem to change SPDif frequencies more than 7 times.
The system seems to hang.

After some tracing, it seems to hang in decouple.xc, where it tells the audio thread that the frequency has changed.
It sends a token into delivery in audio.xc, which shuts it down, reinitializes and it sends a token back to the decouple thread. The decouple thread waits for this token, reinitializes some things, turns the interrupt back on and it is ready to receive more SPDif data, at the higher speed this time.

Well, this works well for up to 7 times. After 7 times, the handshake token from the audio thread is not being received by the decouple thread, for some reason.

I've put some test points where the token is sent and where the token is received. It clearly hangs waiting for the token.

The following code can be found in decouple, around line 750 or so:

Code: Select all

               
SET_SHARED_GLOBAL(g_aud_from_host_rdptr, aud_from_host_fifo_start);
SET_SHARED_GLOBAL(g_aud_from_host_wrptr, aud_from_host_fifo_start);
SET_SHARED_GLOBAL(aud_data_remaining_to_device, 0);
 /* Wait for handshake back and pass back up */
p_USB_debugLED <: 1;      // turn on debug LED
chkct(c_del_out, XS1_CT_END);
SET_SHARED_GLOBAL(g_freqChange, 0);
asm("outct res[%0],%1"::"r"(buffer_aud_ctl_chan),"r"(XS1_CT_END));
ENABLE_INTERRUPTS();
p_USB_debugLED <: 0;      // turn on debug LED


What could be the cause for this? Can a channel go bad somehow? Could I have run out of heap or stack somehow? It does it at after switching sampling rates exactly 7 times. It does not matter what rates I use - any of them will do the same thing.

Any light shed on this would be greatly appreciated.
User avatar
Ross
XCore Expert
Posts: 719
Joined: Thu Dec 10, 2009 9:20 pm

Postby Ross » Mon Jan 21, 2013 11:28 am

Hi,

Is this S/PDIF data input or output to the XMOS device and therefore are the sample frequency changes you mention in the XMOS device or an incoming S/PDIF stream.

Also, what version of the codebase did you base your design on please?
User avatar
RemcoW
Member
Posts: 10
Joined: Tue Jan 15, 2013 9:00 pm

Postby RemcoW » Mon Jan 21, 2013 3:49 pm

Thanks for replying, Ross.

This is based on Version 1.4

This is SPDif receive.
We're using an Audio Precision analyzer to generate an SPDif stream. It detects the switches in sampling frequencies fine up until the 7th time it switches, after which the delivery and audio threads appear to hang waiting for tokens/activity on the delivery channel, respectively.
User avatar
Ross
XCore Expert
Posts: 719
Joined: Thu Dec 10, 2009 9:20 pm

Postby Ross » Tue Jan 22, 2013 11:41 am

Sorry, I meant the version of the reference design software rather than the SPDIF receive code, the latest is 5.3.
User avatar
RemcoW
Member
Posts: 10
Joined: Tue Jan 15, 2013 9:00 pm

Postby RemcoW » Tue Jan 22, 2013 3:32 pm

I don't see much of a version reference within the code, other than the 1.4.
The zip file has the name "USB-Audio-2.0-XS1-L2-Software-Release(5.3)[11.2.0].zip" so I take it is version 5.3?
User avatar
Ross
XCore Expert
Posts: 719
Joined: Thu Dec 10, 2009 9:20 pm

Postby Ross » Tue Jan 22, 2013 4:13 pm

I noticed a potential race condition in this version of the code, what is the value of the variable outOverflow when this sample frequency change takes place?
User avatar
RemcoW
Member
Posts: 10
Joined: Tue Jan 15, 2013 9:00 pm

Postby RemcoW » Tue Jan 22, 2013 8:43 pm

I have outOverflow as a 1.

Yes, it does 'smell' (for a lack of a better word) like some sort of race condition.
User avatar
Ross
XCore Expert
Posts: 719
Joined: Thu Dec 10, 2009 9:20 pm

Postby Ross » Wed Jan 23, 2013 12:50 pm

A bug was closed in our latest development branch that might cause this. This is fixed in the latest release for SU1 (version 6.0). This will hopefully be released for other chips shortly:

XUD_SetReady needs to be called on buffer reset (i.e. SF change) if overflow flag is set (in decouple.xc)

Code: Select all

/* Reset OUT buffer state */               
outUnderflow = 1;
SET_SHARED_GLOBAL(g_aud_from_host_rdptr,aud_from_host_fifo_start);             
SET_SHARED_GLOBAL(g_aud_from_host_wrptr,aud_from_host_fifo_start);
SET_SHARED_GLOBAL(aud_data_remaining_to_device, 0);

/* ADD THIS */
if(outOverflow)
{
    XUD_SetReady(aud_from_host_usb_ep, 1);
    outOverflow = 0;
}



Might not be the issue, but worth a shot!
User avatar
RemcoW
Member
Posts: 10
Joined: Tue Jan 15, 2013 9:00 pm

Postby RemcoW » Wed Jan 23, 2013 4:22 pm

Thanks.
I appreciate the suggestion but the same thing seems to occur.
Is the fact that it allows normal switching up until 7 times a clue?

When I hit suspend to see where it hangs, I see this in decouple:
Image
Does that provide any useful information?

I instrumented to code a bit with some test LEDs.
I basically turn an LED when it is about to do the "chkct" and turn it back off when it has detected it. With a storage scope, those blips are very evident.
The associated code in audio that actually sets the token also has an LED on/off around it.
I see the audio.xc LED blip on a scope. When it works (prior to switching frequencies 7 times), I see the decouple.xc LED blip immediately after the audio.xc LED blip, indicating that the token is sent and received.
When it stops working, I see the full hi/low blip on audio.xc but the decouple.xc LED only goes high and not back to low so it seems to be hanging in that chkct.
User avatar
Ross
XCore Expert
Posts: 719
Joined: Thu Dec 10, 2009 9:20 pm

Postby Ross » Thu Jan 24, 2013 5:34 pm

I assume the same thing happens with multiple changes of sample frequency from the host PC control panel?

Have you added much code to the design? Specifically any more communication channel between the two tiles?

Return to “Other XMOS Development Kits”

Who is online

Users browsing this forum: No registered users and 2 guests