You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The CH372 processor (and the compatible ones CH375 and CH376, when configured in device mode) has an "internal firmware mode" in which the chip itself takes care of all the control transfers on endpoint 0. In this mode the processor doesn't provide any string descriptor at all, not even the language IDs descriptor: a request for this descriptor will always fail.
This makes it impossible to use WinUSBNet to access such a device. That's because the USBDevice constructor calls its GetDeviceDescriptor method, which will in turn call wuDevice.GetSupportedLanguageIDs(); this is going to throw, and thus GetDeviceDescriptor throws and the entire instantiation fails.
The following alternative implementation of USBDevice.GetDeviceDescriptor fixes the problem. If any string descriptor related operation fails the device object is still created without any string information whatsoever (it could be improved by wrapping a try around each string descriptor request, up to you):
privatestatic USBDeviceDescriptor GetDeviceDescriptor(stringdevicePath){using(API.WinUSBDevice wuDevice=new API.WinUSBDevice()){
API.USB_DEVICE_DESCRIPTOR deviceDesc;try{
wuDevice.OpenDevice(devicePath);deviceDesc= wuDevice.GetDeviceDescriptor();}catch(API.APIException e){thrownew USBException("Failed to retrieve device descriptor.", e);}try{// Get first supported language IDushort[]langIDs= wuDevice.GetSupportedLanguageIDs();ushortlangID=0;if(langIDs.Length >0)langID= langIDs[0];stringmanufacturer=null,product=null,serialNumber=null;byteidx=0;idx= deviceDesc.iManufacturer;if(idx>0)manufacturer= wuDevice.GetStringDescriptor(idx, langID);idx= deviceDesc.iProduct;if(idx>0)product= wuDevice.GetStringDescriptor(idx, langID);idx= deviceDesc.iSerialNumber;if(idx>0)serialNumber= wuDevice.GetStringDescriptor(idx, langID);returnnew USBDeviceDescriptor(devicePath, deviceDesc, manufacturer, product, serialNumber);}catch(API.APIException){returnnew USBDeviceDescriptor(devicePath, deviceDesc,null,null,null);}}}
The text was updated successfully, but these errors were encountered:
Hi, thanks for your report. Is there a specific error code that is thrown in this case? It would be good to work around the issue but I'm a bit hesitant to blankly ignore all API errors.
The CH372 processor (and the compatible ones CH375 and CH376, when configured in device mode) has an "internal firmware mode" in which the chip itself takes care of all the control transfers on endpoint 0. In this mode the processor doesn't provide any string descriptor at all, not even the language IDs descriptor: a request for this descriptor will always fail.
This makes it impossible to use WinUSBNet to access such a device. That's because the
USBDevice
constructor calls itsGetDeviceDescriptor
method, which will in turn callwuDevice.GetSupportedLanguageIDs()
; this is going to throw, and thusGetDeviceDescriptor
throws and the entire instantiation fails.The following alternative implementation of
USBDevice.GetDeviceDescriptor
fixes the problem. If any string descriptor related operation fails the device object is still created without any string information whatsoever (it could be improved by wrapping atry
around each string descriptor request, up to you):The text was updated successfully, but these errors were encountered: