USB Audio 2.0 won't compile with DFU disabled

[ChrisW]

As part of a product refresh I've updated our XMOS USB Audio software from v6.5.1 to the latest v6.12.6. We've always built with DFU disabled because firmware updates are handled by our main control board, however this now causes a compilation error, as below.

Code: Select all

Analyzing main.xc
C:/dev/xmos-6.12.6/sc_usb_audio/module_usb_audio/main.xc:540:24: error: invalid null argument
            DFUHandler(dfuInterface, null);
                       ^~~~~~~~~~~~
C:/dev/xmos-6.12.6/sc_usb_audio/module_usb_audio/main.xc:526:26: note: expanded from here
    #define dfuInterface null
                         ^~~~
C:/dev/xmos-6.12.6/sc_usb_audio/module_usb_audio/main.xc:555:41: error: invalid null argument
                , c_clk_int, c_clk_ctl, dfuInterface
                                        ^~~~~~~~~~~~
C:/dev/xmos-6.12.6/sc_usb_audio/module_usb_audio/main.xc:526:26: note: expanded from here
    #define dfuInterface null
                         ^~~~
xmake[1]: *** [.build_rdc_class2/_m_usb_audio//main.xc.pca.xml] Error 1
xmake: *** [analyze] Error 2

The source of the problem seems to be this code in sc_usb_audio/module_usb_audio/main.xc:

Code: Select all

#ifdef DFU
    interface i_dfu dfuInterface;
#else
    #define dfuInterface null
#endif

So when DFU is disabled, dfuInterface is defined as null, but null isn't allowed in the places where dfuInterface is used. Is there a quick way to patch around this?

[infiniteimprobability]

Yeah - looks like a bug. I'll file this on the internal bugzilla. The recent changes to allow DFU to exist on a different tile assume that DFU is always enabled.

Easy to fix - you need to allow the functions that are passed type

Code: Select all

 interface i_dfu dfuInterface

to "nullable", which means adding a ? before the argument name.

Ie. in main.c :

Code: Select all

void usb_audio_core(chanend c_mix_out
#ifdef MIDI
, chanend c_midi
#endif
#ifdef IAP
, chanend c_iap
#ifdef IAP_EA_NATIVE_TRANS
, chanend c_ea_data
#endif
#endif
#ifdef MIXER
, chanend c_mix_ctl
#endif
, chanend ?c_clk_int
, chanend ?c_clk_ctl
, client interface i_dfu ?dfuInterface
)

and..

Code: Select all

[[distributable]]
void DFUHandler(server interface i_dfu ?i, chanend ?c_user_cmd);

Note - I haven't tried this yet on hardware, but it certainly builds now and it should work. Let us know..

[ChrisW]

Thank you. I've been using v6.11.4 in the meantime but I can build 6.12.6 now. I also had to make a change to module_usb_audio/endpoint0/endpoint0.c at line 589:

Code: Select all

#ifdef DFU
						if(((interfaceNum == 0) || (interfaceNum == 1) || (interfaceNum == 2)) && !DFU_mode_active)
#else
						if(((interfaceNum == 0) || (interfaceNum == 1) || (interfaceNum == 2)))
#endif

I'll post another update once it's been tested.

[ChrisW]

I'm having trouble getting this to run on our hardware. We're using an XS1-U8A-128-FB217, so I wasn't sure which variant of the audio app to use - the two closest matches seem to be:

app_usb_aud_skc_u16 - for the U16A-128
app_usb_aud_xk_u8_2c - for the U8A-64

I went with the U16 app and changed the device type in the .xn file to a U8A-128. Should this work? I've set the build options for 2 channels from host, 0 channels to host, no MIDI, no SPDIF, no DFU.

Doing the same build on v6.11.4 we get software that mostly works but has occasional clicks at higher sample rates, and has completely broken audio in Class 1 mode on some computers. With v6.12.6 it doesn't get as far as enumerating on the bus.

[infiniteimprobability]

The U8A-128 is much closer to the U16A-128 than the U8A-64 because it has two tiles rather than 1. So I would start from the U16A project if starting fresh.

But how come you decided to change the working xn file from v6.5.1? It should be OK to use it still and it's known working on proven hardware.

Can you find out where the code hangs when it doesn't enumerate? This should give you some clues - it's almost definitely a hardware mapping issue. Use xrun --dump-state or use the GUI debugger to see where things are...

[ChrisW]

Sorry I wasn't clear in my first post but this is new hardware. Our older product range had been based on the LS1 chip and most recently software v6.5.1. This new product is the first to use the U8A.

Our current board doesn't have a JTAG connector but we can probably bodge something together so I can run the debugger as suggested. Thanks for the hints.

[infiniteimprobability]

Ah - that makes sense. Yes, do rig up a debug adapter. It will save you a lot of time in the long run. Check the datasheet for the XSYS connection checklist. It's been compiled over time to be a comprehensive guide as to what to connect up to what.

So I understand that it mostly works on the new hardware using 6.11.4?

[ChrisW]

Yes it's mostly working with 6.11.4. I've been looking at the XN file again and there is a signal (PORT_MCLK_IN2) that's not connected on our hardware. This is used for USB feedback so could explain the symptoms of choppy/glitching audio. We're hoping to supply a clock through an alternative port that is connected to our FPGA but currently unused.

The other thing I spotted in the XN file is SystemFrequency="500MHz". We're using a 12MHz oscillator and the mode pins are set for a PLL multiplier of 30.75, so our frequency should be 369MHz. If I put 369 in the XN file I get a lot of warnings:

Code: Select all

..\.\src\core\xp-skc-u16-audio.xn:16 Warning: XN11136 Default 100Mhz reference frequency for node "0" could not be achived. Using 92250000Hz.
..\.\src\core\xp-skc-u16-audio.xn:44 Warning: XN11136 Default 100Mhz reference frequency for node "1" could not be achived. Using 92250000Hz.

Would having a reference frequency of 92MHz cause any problems?

[infiniteimprobability]

I've been looking at the XN file again and there is a signal (PORT_MCLK_IN2) that's not connected on our hardware. This is used for USB feedback so could explain the symptoms of choppy/glitching audio.

Yes, that will cause issues. That signal is responsible for clocking the port that counts MCLK cycles between SOF periods. No clock, no feedback to the host for asynch audio. It *may* play, but won't be pretty!

Would having a reference frequency of 92MHz cause any problems?

Very much so. All of the IP in there assumes a 10ns tick period, including XUD (for USB). The tools should be able to manage getting 100MHz ref clock from 12MHz clock in. Stick with 500MHz.. That, and 100MHz can easily be derived from the 12MHz XTAL. The tools will tell you if you don't get an exact mul/div ratio in the PLL.

[ChrisW]

Yes, that will cause issues. That signal is responsible for clocking the port that counts MCLK cycles between SOF periods. No clock, no feedback to the host for asynch audio. It *may* play, but won't be pretty!

It worked surprisingly well! Anyway I'm trying to connect this up now. Without redesigning the PCB we've got the following pins already routed to our FPGA:

X0D14 (P4C⁰ / P8B⁰ / P16A⁸ / P32A²⁸)
X0D15 (P4C¹ / P8B¹ / P16A⁹ / P32A²⁹)
X0D16 (P4D⁰ / P8B² / P16A¹⁰)
X0D17 (P4D¹ / P8B³ / P16A¹¹)
X0D18 (P4D² / P8B⁴ / P16A¹²)
X0D20 (P4C³ / P8B⁷ / P16A¹⁵ / P32A³¹)

Is there any reason I can't use bit 0 of a 4-bit port instead of a 1-bit port? If I change XS1_PORT_1F to XS1_PORT_4C (or 4D) in the XN file then USB enumeration fails. Our XTAG seems to have gone missing so I'm not sure exactly where it's falling over.

Very much so. All of the IP in there assumes a 10ns tick period, including XUD (for USB). The tools should be able to manage getting 100MHz ref clock from 12MHz clock in. Stick with 500MHz.. That, and 100MHz can easily be derived from the 12MHz XTAL. The tools will tell you if you don't get an exact mul/div ratio in the PLL.

Ah - I was thinking that the frequency was fixed by the PLL multiplier set by the MODE[1:0] pins, and that the XN file had to reflect that.