XCore Exchange

Posted: **Wed Nov 02, 2016 7:30 pm**

Details:
- xTIMEcomposer 14.2.3, OS X Yosemite 10.10.5
- USB Audio 2.0 6.15.2rc1
- custom board, XUF208-256-TQ64

I'm seeing what appearrrrs to be a bug in the XUD library. During compilation of my application, I get the following errors:

Code: Select all

/Users/tobylawrence/workspace/SmartStand/module_xud/src/XUD_Ports.xc:11:36: error: use of undeclared identifer `PORT_USB_TX_READYOUT'
  out port tx_readyout           = PORT_USB_TX_READYOUT;
                                   ^~~~~~~~~~~~~~~~~~~~
/Users/tobylawrence/workspace/SmartStand/module_xud/src/XUD_Ports.xc:11:36: error: initializer element is not constant
  out port tx_readyout           = PORT_USB_TX_READYOUT;
                                   ^~~~~~~~~~~~~~~~~~~~
/Users/tobylawrence/workspace/SmartStand/module_xud/src/XUD_Ports.xc:12:36: error: use of undeclared identifer `PORT_USB_TX_READYIN'
  in port tx_readyin             = PORT_USB_TX_READYIN;
                                   ^~~~~~~~~~~~~~~~~~~
/Users/tobylawrence/workspace/SmartStand/module_xud/src/XUD_Ports.xc:12:36: error: initializer element is not constant
  in port tx_readyin             = PORT_USB_TX_READYIN;
                                   ^~~~~~~~~~~~~~~~~~~
/Users/tobylawrence/workspace/SmartStand/module_xud/src/XUD_Ports.xc:13:36: error: use of undeclared identifer `PORT_USB_RX_READY'
  in port rx_rdy                 = PORT_USB_RX_READY;
                                   ^~~~~~~~~~~~~~~~~
/Users/tobylawrence/workspace/SmartStand/module_xud/src/XUD_Ports.xc:13:36: error: initializer element is not constant
  in port rx_rdy                 = PORT_USB_RX_READY;

So, looking in "module_xud/src/XUD_Ports.xc", I see the following:

Code: Select all

#if (XUD_SERIES_SUPPORT == XUD_U_SERIES) || (XUD_SERIES_SUPPORT == XUD_X200_SERIES)
  in buffered port:32 p_usb_clk  = PORT_USB_CLK;
  out buffered port:32 p_usb_txd = PORT_USB_TXD;
  in  buffered port:32 p_usb_rxd = PORT_USB_RXD;
  out port tx_readyout           = PORT_USB_TX_READYOUT;
  in port tx_readyin             = PORT_USB_TX_READYIN;
  in port rx_rdy                 = PORT_USB_RX_READY;

  on USB_TILE: clock tx_usb_clk  = XS1_CLKBLK_5;
  on USB_TILE: clock rx_usb_clk  = XS1_CLKBLK_4;

#elif (XUD_SERIES_SUPPORT == XUD_L_SERIES) || (XUD_SERIES_SUPPORT == XUD_G_SERIES)
  in buffered port:32 p_usb_clk  = PORT_USB_CLK;
  out port reg_write_port        = PORT_USB_REG_WRITE;
  in  port reg_read_port         = PORT_USB_REG_READ;
  out port p_usb_txd             = PORT_USB_TXD;
  port p_usb_rxd                 = PORT_USB_RXD;
  in port p_usb_stp              = PORT_USB_STP_SUS;
#else
  #error XUD_SERIES_SUPPORT not equal to XUD_U_SERIES, XUD_G_SERIES, XUD_X200_SERIES or XUD_L_SERIES
#endif

That makes sense... except for when you check out the port defines in "module_xud/include/xud.h":

Code: Select all

#if (XUD_SERIES_SUPPORT == XUD_U_SERIES)
    #define PORT_USB_CLK         on USB_TILE: XS1_PORT_1J
    #define PORT_USB_TXD         on USB_TILE: XS1_PORT_8A
    #define PORT_USB_RXD         on USB_TILE: XS1_PORT_8C
    #define PORT_USB_TX_READYOUT on USB_TILE: XS1_PORT_1K
    #define PORT_USB_TX_READYIN  on USB_TILE: XS1_PORT_1H
    #define PORT_USB_RX_READY    on USB_TILE: XS1_PORT_1M
  #else
    #define PORT_USB_CLK         on USB_TILE: XS1_PORT_1H
    #define PORT_USB_REG_WRITE   on USB_TILE: XS1_PORT_8C
    #define PORT_USB_REG_READ    on USB_TILE: XS1_PORT_8D
    #define PORT_USB_TXD         on USB_TILE: XS1_PORT_8A
    #define PORT_USB_RXD         on USB_TILE: XS1_PORT_8B
    #define PORT_USB_STP_SUS     on USB_TILE: XS1_PORT_1E
  #endif

So these "ready" ports are defined if you're targeting a U-series device, but not if you're targeting an x200-series device... even though elsewhere, like in module_xud/src/XUD_Ports.xc, it expets the same ports to be available between U-series and x200-series devices.

Maybe I'm just doing something wrong here, but this does feel like a bug.

Deep thoughts?

Posted: **Wed Nov 02, 2016 7:38 pm**

Just a quick follow up:

looking further into this, I realized the port mappings for the USB subsystem are listed in the XUF208 datasheet. Changing the defines in "module_xud/src/xud.h" to this seem to address the issues:

Code: Select all

#if (XUD_SERIES_SUPPORT == XUD_U_SERIES)
    #define PORT_USB_CLK         on USB_TILE: XS1_PORT_1J
    #define PORT_USB_TXD         on USB_TILE: XS1_PORT_8A
    #define PORT_USB_RXD         on USB_TILE: XS1_PORT_8C
    #define PORT_USB_TX_READYOUT on USB_TILE: XS1_PORT_1K
    #define PORT_USB_TX_READYIN  on USB_TILE: XS1_PORT_1H
    #define PORT_USB_RX_READY    on USB_TILE: XS1_PORT_1M
  #else
    #define PORT_USB_CLK         on USB_TILE: XS1_PORT_1J
    #define PORT_USB_REG_WRITE   on USB_TILE: XS1_PORT_8C
    #define PORT_USB_REG_READ    on USB_TILE: XS1_PORT_8D
    #define PORT_USB_TXD         on USB_TILE: XS1_PORT_8A
    #define PORT_USB_RXD         on USB_TILE: XS1_PORT_8B
    #define PORT_USB_STP_SUS     on USB_TILE: XS1_PORT_1E
    #define PORT_USB_TX_READYOUT on USB_TILE: XS1_PORT_1K
    #define PORT_USB_TX_READYIN  on USB_TILE: XS1_PORT_1H
    #define PORT_USB_RX_READY    on USB_TILE: XS1_PORT_1I
  #endif

Taking a cursory glance at other datasheets for XUF devices, my updated defines appear to be an accurate reflection of the port mappings.

Posted: **Thu Nov 03, 2016 7:12 pm**

It's the XN file where there would normally be a complete port mapping, e.g. xk-audio-216-mc.xn

xud.h has defaults that, as you found, are incomplete

Posted: **Thu Nov 03, 2016 7:12 pm**

larry wrote:It's the XN file where there would normally be a complete port mapping, e.g. xk-audio-216-mc.xn

xud.h has defaults that, as you found, are incomplete

Yup, making the above change let me get past that issue and I was able to get USB working on my custom board. I figured I'd raise it here, initially, to try and get an answer while I investigated more in parallel, but it seems like this is probably worth fixing as xCORE-200 is sort of the future, right?

I guess maybe I'm overestimating the reliance of the reference apps for people building custom designs, but this problem was perplexing at first because it *appeared* all the options -- U vs L vs G vs 200 -- were they... but it didn't originally occur to me that they would be incomplete. :)

Posted: **Fri Nov 04, 2016 5:24 pm**

Definitely, thank you for pointing it out

Posted: **Wed Feb 08, 2017 12:31 pm**

I'm experiencing the same problems as nuclearfurnace
I also hav ethe sam eissue with reliance on the reference software when trying to do custom designs - it's an incredibly complicated maze of dependencies & exemptions & when there is a problem with a build I find it insanely difficult to track down where the bug may lie.
Now, I'm new to this so maybe I'm missing some tool or debugging feature that will help in tracking down the particular bug nuclearfurnace identified?

One thing that seems would address this is a fully specified xn file - I'm trying to create firmware fr a board that uses the XUF216-512-TQ128-C20 chip.
I don't see full port mapping in the xn file for XUF216-512-TQ128 but I do see it in xk-audio-216-mc.xn.

So what should I be using? Is therea giude to the structure of & how to modify a xn file (it's XML right?)
Am I wrong to use the installed target XUF216-512-TQ128?
Should I be using both xn files?

Posted: **Thu Feb 09, 2017 11:38 am**

it's an incredibly complicated maze of dependencies & exemptions & when there is a problem with a build I find it insanely difficult to track down where the bug may lie

In .build folder of your app you can find files output from preprocessor (ending .i for C files and .xi for XC files). These can be very useful when working with numerous hash define options, like we do in the USB audio code base. Compiler saves these when using the -save-temps flag. Our makefiles will put files from not only the top level app in the .build folder, but also the app's modules. Very handy.

Regarding XN files, there is fundamentally no difference between the XN file for a bare package and XN file for a whole board. You pass XN file to the tools and for all I/Os listed in XN file, tools create symbolic names you can refer to in your source. If you list ports that aren't actually available on given package, tools will warn you. Tools get package information from another file, PKG, that's part of the tools (lives in a directory called configs). When writing own XN file, it's always best to cross check against list of available I/Os in silicon datasheet.

XN files are documented in xTIMEcomposer user guide. Please do shout if you find important information that is missing.

Posted: **Sat Feb 11, 2017 8:28 am**

Thanks Larry, I missed this post somehow - good info.

XCore Exchange

Bug with XUD library in USB Audio?

Bug with XUD library in USB Audio?

Re: Bug with XUD library in USB Audio?

Re: Bug with XUD library in USB Audio?

Re: Bug with XUD library in USB Audio?

Re: Bug with XUD library in USB Audio?

Re: Bug with XUD library in USB Audio?

Re: Bug with XUD library in USB Audio?

Re: Bug with XUD library in USB Audio?