XUF208 TDM8 USB Audio

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
ajudge
Junior Member
Posts: 5
Joined: Wed Aug 30, 2017 8:08 am

XUF208 TDM8 USB Audio

Postby ajudge » Tue Sep 12, 2017 2:20 am

Hello,

Following AN01027, I am attempting to use a XUF208 to implement an USB audio class 2 device as a TDM8 slave (8x8 or 16x16). So far the XUF enumerates successfully as a USB device on the host and I can receive audio from it (ie TDM8 --> USB --> host).
Unfortunately "audio out" (host --> USB --> TDM8) appears to be failing. Using a software bus analyser, I can see the host transmitting, but I do not have any activity on the TDM8 line(s)*.

Before I dig into the USB library code - has anyone experienced anything similar or have any suggestions?

I have attached the makefile I am using, the customdefines.h (moved the specific defines from makefile to here for syntax highlighting), and the xn file I am using.

* Initially, when playing a test tone immediately after power up/insertion of USB lead, I get a small (sub 1s) burst of activity on the lines.
Attachments
Makefile.txt
(1.97 KiB) Downloaded 22 times
Makefile.txt
(1.97 KiB) Downloaded 22 times
XUF208-128-TQ64-C10.xn
(3.15 KiB) Downloaded 33 times
XUF208-128-TQ64-C10.xn
(3.15 KiB) Downloaded 33 times
customdefines.h
(3.21 KiB) Downloaded 23 times
customdefines.h
(3.21 KiB) Downloaded 23 times
ajudge
Junior Member
Posts: 5
Joined: Wed Aug 30, 2017 8:08 am

Postby ajudge » Tue Sep 12, 2017 8:37 am

I have done some digging into the problem and eventually arrived at the decoupler.

Code: Select all

#if (NUM_USB_CHAN_OUT > 0)
        /* Check for OUT data flag from host - set by buffer() */
        GET_SHARED_GLOBAL(aud_from_host_flag, g_aud_from_host_flag);
        if (aud_from_host_flag)
        {
            temppinval = !temppinval;
            p_test_pin <: temppinval;


With this I observe the pin toggling for the same "short period of time", but nothing more - indicating the decoupler isn't actually receiving anything.

I added the same test into the endpoint buffer code (usb_buffer.xc) and saw the same result. At this point, I assume the device isn't actually receiving the packets the host indicates it is sending...

Code: Select all

            case XUD_GetData_Select(c_aud_out, ep_aud_out, length, result):
            {
                GET_SHARED_GLOBAL(aud_from_host_buffer, g_aud_from_host_buffer);
                temppinval = !temppinval;
                p_test_pin <: temppinval;
                write_via_xc_ptr(aud_from_host_buffer, length);


Is this just a driver issue?
User avatar
Ross
XCore Expert
Posts: 761
Joined: Thu Dec 10, 2009 9:20 pm

Postby Ross » Tue Sep 12, 2017 11:00 am

I'd inject some data in at the buffering level and see if anything pops out on the TDM data-lines. Perhaps this will narrow down the location of the issue.

What board are you running this on?
ajudge
Junior Member
Posts: 5
Joined: Wed Aug 30, 2017 8:08 am

Postby ajudge » Wed Sep 13, 2017 4:05 am

I'm using a breakout board I made for the XUF208-128-TQ64 to run various separate projects - so far CDC, HID, SPDIF->I2S and 8/16 channels of USB Audio IN have worked.

I think the issue is occurring earlier than that. I toggled the pin inside XUD_GetData_Select (as below) and saw the same behaviour - brief activity initially, followed by nothing. It's as if the XUD_GetData_Select stops being called after a short period of audio.

Code: Select all

XUD_GetData_Select:
#if defined(__XS2A__)
.issue_mode single
  ENTSP_lu6 4
#else
  entsp 4
#endif
   stw r4, sp[1]
   stw r5, sp[2]
   ldw r4, dp[temppinval]
    eq r4, r4, 0
    stw r4, dp[temppinval]
    ldw r5, dp[p_test_pin]
    out res[r5], r4
    testct     r11, res[r0]
    bt         r11, XUD_GetData_Select_Return_Reset
ajudge
Junior Member
Posts: 5
Joined: Wed Aug 30, 2017 8:08 am

Postby ajudge » Wed Sep 13, 2017 7:36 am

So I now have consistent activity on the TDM lines (an issue with signed-ness on the output stream appears to exist also, but I'm sure this is separate).
As I figured this was likely going to be an issue in the XUD_Manager - or at least some sort of configuration I missed - I solved my issue by replacing the libxud_x200.a from sw_usb_audio_6.15.2 with the one from sw_usb_audio_6.12.5. I now have consistent activity in both directions.

What changed between these two versions?
User avatar
Ross
XCore Expert
Posts: 761
Joined: Thu Dec 10, 2009 9:20 pm

Postby Ross » Wed Sep 13, 2017 10:46 am

I wonder if you have some signal integrity issues - some error signal handling was added at this point - it should recover but that is the only major change I believe.
ajudge
Junior Member
Posts: 5
Joined: Wed Aug 30, 2017 8:08 am

Postby ajudge » Wed Sep 13, 2017 11:28 am

It wouldn't surprise me if that's the case - I didn't pay much attention to signal integrity as I have no intention for the boards to be used long-term. Rather just made it to dive into XMOS.

I'll let it run for an extended period of time to see if it recovers. Is there any user control mechanisms in place for the error handling - even if just on/off?
User avatar
Ross
XCore Expert
Posts: 761
Joined: Thu Dec 10, 2009 9:20 pm

Postby Ross » Wed Sep 13, 2017 11:44 am

If you have SI issues I would recommend staying on the older XUD version for now - I'll try and take a look at making the recovery more robust for bad links (we have a bug registered here)

Return to “Applications”

Who is online

Users browsing this forum: No registered users and 8 guests