using DFU in audio class 1.0

Technical discussions related to any XMOS development kit or reference design. Eg XK-1A, sliceKIT, etc.
User avatar
beaker
Junior Member
Posts: 6
Joined: Fri Sep 26, 2014 11:42 am

using DFU in audio class 1.0

Post by beaker »

Hi

I am putting this out there to see if anyone has managed to get the DFU updater working on AUDIO CLASS 1.0.

I have the XMOS USB 2.0 Reference design board and have successfully used the DFU using the Thesycon TUSBAudioDfu application when using the AUDIO class 2.0 firmware (app_usb_aud_l1_2ioxx).

my problems started when i upgraded to the latest firmware for the USB audio devices v6.6.0 which i couldn't get it to enumerate at all with audio class 1.0 project (app_usb_aud_l1_1ioxs).
The newest version of the firmware where i could succesfully enumerate the project was 6.5.0.

I then proceeded to modify the firmware of audio class 1.0 (app_usb_audl1_1ioxs) to enable the DFU which i have successfully completed before with version 6.1.0. Where i had created the drivers the DFU operation and the console app to upload new firmware.

In v6.5.0 (app_usb_aud_l1_1ioxs) with the DFU enabled i can enter DFU mode but when i proceed to download new firmware the device is unresponsive and needs to be reset. On the TUSBAudioDfu app the feedback i get is


Device opened.
Ready for firmware update.

Upgrading firmware...
0 of 27904 bytes transferred.
TUSBAUDIO_GetDfuStatus: Function failed with error code 0xEE000003.

Firmware upgrade failed!



finally, my question is
has anyone had any luck getting the XMOS USB audio working with audio class 1.0 with the DFU in the more recent versions of firmware ?

i'm using a windows 7 PC with service pack 1.

thanks for any help.


User avatar
Ross
XCore Expert
Posts: 783
Joined: Thu Dec 10, 2009 9:20 pm

Post by Ross »

We do not enable descriptors for DFU in Audio Class 1.0 mode - mainly because main reason people like to use it is for "driver-less" operation in Windows.

If a DFU interfaces is exposed in the descriptor set Windows will prompt for a driver.
User avatar
Ross
XCore Expert
Posts: 783
Joined: Thu Dec 10, 2009 9:20 pm

Post by Ross »

Regarding the enumeration issues please try the following change (We already took a report):

(Add the bold stuff, remove the Red stuff..)

/* In UAC1 supported sample rates are listed in descriptor */
-#if (MAX_FREQ_FS == 96000)
+/* Note, we always report 4 freqs, doing otherwise seems to cause an enumeration issue on Windows */
#define NUM_FREQS_A1 (4)

-#elif (MAX_FREQ_FS == 88200)
-#define NUM_FREQS_A1 (3)
-#elif (MAX_FREQ_FS == 48000)
-#define NUM_FREQS_A1 (2)
-#elif (MAX_FREQ_FS == 44100)
-#define NUM_FREQS_A1 (1)
-#else
-#error
-#endif


unsigned char cfgDesc_Audio1[] =
{
@@ -2694,12 +2685,18 @@ unsigned char cfgDesc_Audio1[] =
0x44, 0xAC, 0x00, /* sampleFreq - 44.1Khz */
#if (MAX_FREQ_FS > 44100)
0x80, 0xBB, 0x00, /* sampleFreq - 48KHz */
+#else
+ 0x44, 0xAC, 0x00, /* sampleFreq - 44.1Khz */

#endif
#if (MAX_FREQ_FS > 48000)
0x88, 0x58, 0x01, /* sampleFreq - 88.2KHz */
+#else
+ 0x44, 0xAC, 0x00, /* sampleFreq - 44.1Khz */

#endif
#if (MAX_FREQ_FS > 88200)
0x00, 0x77, 0x01, /* sampleFreq - 96KHz */
+#else
+ 0x44, 0xAC, 0x00, /* sampleFreq - 44.1Khz */

#endif

/* Standard AS Isochronous Audio Data Endpoint Descriptor 4.6.1.1 */
@@ -2775,12 +2772,18 @@ unsigned char cfgDesc_Audio1[] =
0x44, 0xAC, 0x00, /* sampleFreq - 44.1Khz */
#if (MAX_FREQ_FS > 44100)
0x80, 0xBB, 0x00, /* sampleFreq - 48KHz */
+#else
+ 0x44, 0xAC, 0x00, /* sampleFreq - 44.1Khz */

#endif
#if (MAX_FREQ_FS > 48000)
0x88, 0x58, 0x01, /* sampleFreq - 88.2KHz */
+#else
+ 0x44, 0xAC, 0x00, /* sampleFreq - 44.1Khz */

#endif
#if (MAX_FREQ_FS > 88200)
0x00, 0x77, 0x01, /* sampleFreq - 96KHz */
+#else
+ 0x44, 0xAC, 0x00, /* sampleFreq - 44.1Khz */

#endif
/* Standard Endpoint Descriptor */
0x09,
User avatar
beaker
Junior Member
Posts: 6
Joined: Fri Sep 26, 2014 11:42 am

Post by beaker »

Hi Ross

Thankyou very much for the info, that helped a lot. I know have the latest version 6.6.0rc5 working with audio class 1.0.

As for the DFU operation in audio class 1.0. I still need to get that working as its my only updgrade path to the device once its in our product. As mentioned in my first post i have had in previous versions of the firmware the DFU working before in audio class 1.0 and made drivers and a program for updates but now can't get it work in the latest release.

I see in the descriptors for audio class 1.0 in 6.6.0 that the DFU descriptors are not even there now but have added them and can enumerate with the driver i created but i think there is still a problem with the interface comms in the program. but i will endeavour to get it working. If you can give me any hints that would be great.

Thanks for all the help so far.
User avatar
Ross
XCore Expert
Posts: 783
Joined: Thu Dec 10, 2009 9:20 pm

Post by Ross »

A couple things to check:

- is DFU enabled (i.e. DFU defined as one)
- Does INTERFACE_NUMBER_DFU evaluate to the same value as in the descriptors you have added?
User avatar
beaker
Junior Member
Posts: 6
Joined: Fri Sep 26, 2014 11:42 am

Post by beaker »

Hi Ross,

Thanks for the help with this, sorry for delay in replying as been busy on other things. I have enabled the 'DFU' by setting it to 1 in the customdefines.h.

The INTERFACE_NUMBER_DFU does evaluate to interface 3.
where
Interface 0 = audio control
Interface 1 = audio output
Interface 2 = audio input

I have used a beagle USB monitor to look at the descriptor. below is the DFU section.

Interface Descriptor
bLength 9
bDescriptorType INTERFACE (0x04)
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass Application Specific (0xfe)
bInterfaceSubClass Device Firmware Upgrade (0x01)
bInterfaceProtocol Runtime (0x01)
iInterface Glensound DFU (15)

DFU Functional Descriptor
bLength 9
bDescriptorType DFU FUNCTIONAL (0x21)
bmAttributes.bitCanDnload Yes (0b1)
bmAttributes.bitCanUpload Yes (0b1)
bmAttributes.bitManifestationTolerant Yes (0b1)
bmAttributes.bitWillDetach No (0b0)
wDetachTimeOut 250ms (250)
wTransferSize 64
bcdDFUVersion 1.10 (0x0110)



I then create a driver using 'libusbK-dev-kit' from http://sourceforge.net/projects/libusbk/files/

the DFU interface of the XMOS device then enumerates in the control panel in the 'libusbK Usb Devices' section.

I then use a visual studio 2013 c++ console program based on the host code from the 'module_dfu' folder in the XMOS code to interact with the DFU. This program worked just fine with - "USB-Audio-2.0-Software-Reference-Design(6.1.0)[12.2.0]" with DFU enabled but with "USB-Audio-2.0-Software-Reference-Design(6.6.0)[13.2.0]" with the DFU enabled the same PC software successfullly detects the VID/PID of the DFU but returns an error of -12 (Operation not supported or unimplemented on this platform) when attempting to connect to the interface.

any suggestions on whats happening would be a great help. if need any more info please let me know.

Thanks

Alan
User avatar
beaker
Junior Member
Posts: 6
Joined: Fri Sep 26, 2014 11:42 am

Post by beaker »

since i haven't been able to get DFU to work in audio class 1.0 i thought i'd see if it actually works with unedited firmware (USB-Audio-2.0-Device-Software(6.6.0)) and using the Thesycon drivers supplied (version 2.23.0).

I followed the instructions for using the document "DFU loader for XMOS USB AUDIO devices"
Publication Date: 2014/6/12

i used the dfucons app to check if the device has DFU capability.

dfucons info

returned a yes to the DFU supported.

i then tried to download my new version of code using

dfucons download new_firmware.bin

this just returned.....of many attempts !!!

State 2 (EnteringDfuMode), 0 of 29696 bytes downloaded ...
State 2 (EnteringDfuMode), 0 of 29696 bytes downloaded ...
State 2 (EnteringDfuMode), 0 of 29696 bytes downloaded ...
State 2 (EnteringDfuMode), 0 of 29696 bytes downloaded ...
State 2 (EnteringDfuMode), 0 of 29696 bytes downloaded ...
State 2 (EnteringDfuMode), 0 of 29696 bytes downloaded ...
State 2 (EnteringDfuMode), 0 of 29696 bytes downloaded ...
State 2 (EnteringDfuMode), 0 of 29696 bytes downloaded ...
State 2 (EnteringDfuMode), 0 of 29696 bytes downloaded ...
State 3 (InProgress), 0 of 29696 bytes downloaded ...

X20 times the above line.........

State 6 (Failed), 0 of 29696 bytes downloaded ...
Download failed, completionStatus = 0xEE000003

I tried using the TUSBAudioDfu app but that failed everytime also !
its response was always:-

Device opened.
Ready for firmware update.

Upgrading firmware...
0 of 29696 bytes transferred.
TUSBAUDIO_GetDfuStatus: Function failed with error code 0xEF000011.

Firmware upgrade failed!


has anyone got the DFU working on latest version of firmware. I worked just fine before

any help greatly appreciated.


attached it end of scan i done using beagle USB monitor. The device is reset and DFU descriptor is seen but it all seems to go wrong from there.
You do not have the required permissions to view the files attached to this post.
garryx
Newbie
Posts: 1
Joined: Sun Apr 24, 2011 3:01 am

Post by garryx »

I have the exactly same issue. I tried both 6.51 and 6.6 firmware. The DFU upgrade also fails with error 0xEE000003. I am using Win 8.1 64bit, USB 2.0 and 3.0.

The DFU was working before in 6.4 and all other previous releases.
We are preparing a 6.6 firmware upgrade for our customers. The original firmware can be upgraded to 6.6, but 6.6 DFU has this bug. If we release the 6.6 firmware now, that would be a disaster for future upgrade.

I submit a support ticket already.
User avatar
beaker
Junior Member
Posts: 6
Joined: Fri Sep 26, 2014 11:42 am

Post by beaker »

Hi garryx

I still haven't heard about any fix. If i do i'll let you know. If you hear about any fix for DFU i'd appreciate you letting me know.

Thanks
ffomich
Experienced Member
Posts: 119
Joined: Mon Sep 15, 2014 1:32 pm

Post by ffomich »

Hi beaker and garryx!

Is there any fix for this issue?