AnsweredAssumed Answered

Bug in SHARC USB EZ-Extender software?!?!

Question asked by rkn on Apr 12, 2015
Latest reply on Jun 4, 2015 by Harshit.Gaharwar

Hi,

 

I'm playing around with the USB Audio example software. It seem sot work in Full-Speed-Mode. Mac OSX recognizes the new audio device. Now I'm changing it to High-Speed-Mode and USB Audio Class 2.0. Therefore, I've to change the USB descriptors and found a problem with the configuration descriptor. Due to UAC2.0 this descriptor becomes bigger then 256bytes. Interestingly the DSP send then only the difference to the host. E.g. the configuration descriptor is 264bytes long only 8 bytes are sent and the host detects an error because it is waiting for 264bytes and receives only 8 (error message in the kernel log). I traced it a bit today and found that the problem is caused by the type of  Sizeof_UsbConfiguration. This is a union:

 

typedef union _WORDBYTE

{    

BYTE Byte[2];   // Two 8-bit bytes  

USHORT Word;   // One 16 bit word

}

WORDBYTE, *PWORDBYTE;


Now it is filled with values in line 1810 of NcFwApi.c:


Sizeof_UsbConfiguration.Byte[MYEND_LO] = UsbConfiguration->wTotalLengthLo;

Sizeof_UsbConfiguration.Byte[MYEND_HI] = UsbConfiguration->wTotalLengthHi;


Since byte and ushort seem to be both 32bit on a SHARC the line 945 in NcDevice.c

Length = MIN(WLENGTH, Sizeof_UsbConfiguration.Word);

won't give the the correct value: Byte[2) is 64bit long in total, while Word is 32bit long. There is also a warning in the comment to check the packing.


Any idea how to fix this issue in a smart way?


Of course I can rebuild the length a 16bit word in line 945 but are there more lines where it can fail?


Raphael

Outcomes