XCore Exchange

Posted: **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.

Posted: **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?

Posted: **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.

Posted: **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.

Posted: **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?

Posted: **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?

Posted: **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.

Posted: **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!

Posted: **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:

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.

Posted: **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?

XCore Exchange

USB reference design and SPDif

USB reference design and SPDif

Re: USB reference design and SPDif

Re: USB reference design and SPDif

Re: USB reference design and SPDif

Re: USB reference design and SPDif

Re: USB reference design and SPDif

Re: USB reference design and SPDif

Re: USB reference design and SPDif

Re: USB reference design and SPDif

Re: USB reference design and SPDif