X
RSS YouTube LinkedIn Twitter Facebook

Search




Post new topic Reply to topic   [ 16 posts ]  Go to page 1, 2  Next
Author Message
49
PostPosted: Tue Jan 15, 2013 9:48 pm 
User avatar
Member
Joined: Tue Jan 15, 2013 9:00 pm
Posts: 10
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:
               
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.


Top
Offline Profile View all posts by this user  
 
1626
PostPosted: Mon Jan 21, 2013 11:28 am 
User avatar
XMOS Employee
Joined: Thu Dec 10, 2009 9:20 pm
Posts: 407
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?


Top
Offline Profile View all posts by this user  
 
49
PostPosted: Mon Jan 21, 2013 3:49 pm 
User avatar
Member
Joined: Tue Jan 15, 2013 9:00 pm
Posts: 10
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.


Top
Offline Profile View all posts by this user  
 
1626
PostPosted: Tue Jan 22, 2013 11:41 am 
User avatar
XMOS Employee
Joined: Thu Dec 10, 2009 9:20 pm
Posts: 407
Sorry, I meant the version of the reference design software rather than the SPDIF receive code, the latest is 5.3.


Top
Offline Profile View all posts by this user  
 
49
PostPosted: Tue Jan 22, 2013 3:32 pm 
User avatar
Member
Joined: Tue Jan 15, 2013 9:00 pm
Posts: 10
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?


Top
Offline Profile View all posts by this user  
 
1626
PostPosted: Tue Jan 22, 2013 4:13 pm 
User avatar
XMOS Employee
Joined: Thu Dec 10, 2009 9:20 pm
Posts: 407
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?


Top
Offline Profile View all posts by this user  
 
49
PostPosted: Tue Jan 22, 2013 8:43 pm 
User avatar
Member
Joined: Tue Jan 15, 2013 9:00 pm
Posts: 10
I have outOverflow as a 1.

Yes, it does 'smell' (for a lack of a better word) like some sort of race condition.


Top
Offline Profile View all posts by this user  
 
1626
PostPosted: Wed Jan 23, 2013 12:50 pm 
User avatar
XMOS Employee
Joined: Thu Dec 10, 2009 9:20 pm
Posts: 407
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:
/* 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!


Top
Offline Profile View all posts by this user  
 
49
PostPosted: Wed Jan 23, 2013 4:22 pm 
User avatar
Member
Joined: Tue Jan 15, 2013 9:00 pm
Posts: 10
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.


Top
Offline Profile View all posts by this user  
 
1626
PostPosted: Thu Jan 24, 2013 5:34 pm 
User avatar
XMOS Employee
Joined: Thu Dec 10, 2009 9:20 pm
Posts: 407
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?


Top
Offline Profile View all posts by this user  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic   [ 16 posts ]  Go to page 1, 2  Next


Who is online

Users browsing this forum: No registered users and 2 guests



Search for:
Jump to: