AN01034 and XK-VF3100-C43 development kit Topic is solved

Technical questions regarding the XTC tools and programming with XMOS.
Post Reply
jneuman
New User
Posts: 3
Joined: Tue Feb 11, 2020 6:29 pm

AN01034 and XK-VF3100-C43 development kit

Post by jneuman »

I'm attempting to use the device control library (https://github.com/xmos/lib_device_control) with the vfspk_base.xn on the XK-VF3100-C43 development kit. The AN01034 example project loads and runs, but never provides an enumerated USB device on my Windows 10 machine. It appears based on my call stack that tile[1] is getting hung in XUD_GetSetupData_Retry and it never completes the endpoint generation (i.e. no XUD_RES_OKAY). I've attached my call stack from the debugger.

I can successfully run the sw_vocalfusion_xvf3000-[sw]_1.1.2rc5 with the microphone and speaker (and DFU with no driver) enumerating so it would seem that the USB hardware on the device is ok.

I'd like to get this working so I can add the USB control to my project. Any suggestions out there?
call_stack.PNG
(36.13 KiB) Not downloaded yet
call_stack.PNG
(36.13 KiB) Not downloaded yet


View Solution
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi. Disclaimer: Do not have either referenced kit.

However in reviewing similar issues on OEM designs found that the USB IP is very time sensitive. Respectively, if the timing is not met the USB interface can and will break. Recommend to review the source code that is not working for any I2C interface code - then for starters, comment out the calls for these I2C devices -> check if the USB interface works to properly enumerate. On past code reviews, client's custom code broke due to massive retries by the XMOS I2C Bus Master engine (2000 retries before a timeout would occur and these calls were blocking). These retries to phantom devices that were not present on the custom design but present in the code run caused the USB IP to break.
jneuman
New User
Posts: 3
Joined: Tue Feb 11, 2020 6:29 pm

Post by jneuman »

After some further review, I went back to the source of the example application (https://github.com/xmos/lib_device_cont ... y_over_usb). I went back to the version where it was using the module_xud vs the lib_usb. This allowed the device to enumerate, which lead to the next problem... the expectation is to use a generic WinUSB driver which I can't install on my Windows 10 machine due to the driver signing problem. I'll need to look at a different option for USB control with the XMOS to eliminate the need for driver signing at this point.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

According to this URL, Windows 10 should be possible but you may have to massage the INF file:

https://docs.microsoft.com/en-us/window ... stallation

A little trick you may wish to consider to get moving on your development is to "borrow" the USB IDs from Microchip or some other strong semiconductor firm who has signed device drivers. Then proceed to use your widget with those IDs for your development till you true IDs and signed drivers are available.
User avatar
fabriceo
XCore Addict
Posts: 181
Joined: Mon Jan 08, 2018 4:14 pm

Post by fabriceo »

hi jneuman, on W10, I m able to attach the DFU interface 3 to winusb just using Zadig. no problem of driver signature
you can use this interface to exchange data between the host and the device, provided that the 64bytes packet is enough
FYI if the windows usabaudio2.sys driver is linked to the device, you might not be able to access the other interfaces, the way to overcome this is to activate HID interface in addition to your DFU and so on. then all of them will show up with a library like libusb.
jneuman
New User
Posts: 3
Joined: Tue Feb 11, 2020 6:29 pm

Post by jneuman »

Thanks for the help! I was able to get the libusb drivers to install using the Zadig tool. I had never used that before and it saved me the effort of going through the Microsoft dev signing process.
Post Reply