Microchip chip device tool programmer

[kmvi-dev]

When using the latest version of USBIP windows client, the following problem was discovered:
When forwarding a USB chip programming device manufactured by Microchip Technology Inc, in particular, the Atmell-ICE programmer (this is the programmer debugger), or, for example, AVRISp-MKII (just the programmer), MPLAB ICD 3 In-Circuit Debugger and IDE that use these tools , work with the WinUsb driver. When forwarding using the usbip client on Windows and the usbip server on ubuntu 18.04 and kernel version 5.3.0.42, device drivers are loaded, but the programming environment does not detect remote devices on the bus.
In the screenshots:

IDE, on which both local access and forwarding of the USBIP chip programmig device was checked.

UsbLocalConnect.png - local connection to the chip programming device (without using USBIP).

Then the USBIP driver was installed:

and the result of the device forwarding using the USBIP driver and app:

A similar problem manifests itself in the MPLAB X IDE (v5.10)

[cezanne]

@kmvi-dev :

When using the latest version of USBIP windows client, the following problem was discovered:

Old versions also had the problem, didn't it?

There's remarkably different two things in your screenshots: Device name and instance id. But capitalization of instance id would not matter because the vendor id and the product id were well detected. So how about enforcing the device name to "Atmel-ICE CMSIS-DAP" from "on USB/IP VHCI"?

The string to be modified is here:

usbip-win/driver/vhci/vhci_vpdo.c

Line 17 in bcf3afa

#define USBIP_DEVICE_LOCINFO L"on USB/IP VHCI"

[iv-dev]

Old versions also had the problem, didn't it?

Yes.

There's remarkably different two things in your screenshots: Device name and instance id. But capitalization of instance id would not matter because the vendor id and the product id were well detected. So how about enforcing the device name to "Atmel-ICE CMSIS-DAP" from "on USB/IP VHCI"?

I have provided screenshots for the case of connecting the device locally without using a USBIP client - these are Atmel-ICE CMSIS-DAP device name and screenshots when using a USBIP client -
it's on USP / IP VHCI device name

I already changed this field, and even added the serial number. But it did not lead to a positive result.
Therefore, I sent a report in the screenshots of the latest version from the repository

[koudis]

I had simillar problem. My programmer must be atrached to native Windows USB HUB otherwise it does not work. (I had problem even with comercial solutions if I choose "attach devices to separate device hub")

[iv-dev]

I think the problem lies in the usb / ip configuration. Missing value in the Power field. This can be seen in the last screenshot.
When a programming device is loaded into the driver stack, the WinUsb.sys driver is also loaded. Our problem, I think, somehow intersects with #105

[cezanne]

@kmvi-dev : Can you share USB packet logs of directly attached your device(without usbip-win). One of such a tool is USBPcap.

[kmvi-dev]

Yes, I will make such a log. Can I use the UsbSnoop tool?
https://github.com/SnoopWare/usbsnoop

[cezanne]

@kmvi-dev : I recommend USBPcap because I should learn usbsnoop. 😄 I have used Wireshark to examine USB captured logs and USBPcap supports wireshark format.

[kmvi-dev]

Ok . Now I will make a log with USBCap. But first I will say that the difference in the sequence and contents of URB packets between the local connection and the connection using usbip is significant. I checked URB with USBSnoop

[kmvi-dev]

the log file is ready,
AvrMKII.zip

[cezanne]

@kmvi-dev : Driver file please..

[kmvi-dev]

Drivers are shipped with the Atmel studio 7.0 distributive. But I can send you a folder with these drivers
Drivers.zip

[cezanne]

@kmvi-dev : many infs.. Which one should be installed?

[kmvi-dev]

@cezanne
I install the microcontroller programming environment and drivers from the distribution
https://www.microchip.com/mplab/avr-support/avr-and-sam-downloads-archive
during installation, the driver installation program is called, which programmers need to work with the programming device, for example, with the AVRISP-MKII device

[kmvi-dev]

@cezanne
you can try to run the DPInst.exe module with administrator rights, which is located in the archive along the path Drivers \ Segger \ x64, but I'm not sure that the necessary drivers will be installed correctly so.
here is information on the standalone installation of winusb.sys driver
https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/winusb-installation

[cezanne]

@kmvi-dev : I also installed the microcontroller programming environment. I saw many drivers to be installed. BTW, the device ID's are different between your screenshot(PID:2141) and your USB capture(PID: 2104). Here is a wireshark view loading your capture.

[kmvi-dev]

@cezanne
different identifiers, because I made a capture from another AVR MKII programming device.
The fundamental difference between a USBIP tunnel and a locally connected device for programming microchip will be noticeable if you can get a URB packet from a USBIP hub,
using usbcap. I was unable to get such a log using usbcap, and so I received URB packets from USBIP using usbsnoop. I can send you its executable module of usbsnoop, which I built and used

[kmvi-dev]

@cezanne
or I can, if necessary, send you a screenshots of the capture of URB packets

[cezanne]

@kmvi-dev : A virtual avrispmkii device was implemented by usbip-vstub, which was launched to support a virtual stub for usbip-win.
Simple attaching of a virtual avrispmkii did not playback all URB packets of your capture. No more packet was requested after SET_CONFIGURATION. Here's my kernel log and a screenshot.

BTW, HW id's are quite different each other. In my case, HW id has no suffix MI(multiple interface). Could you check? Other capture or screenshot would be helpful.

[kmvi-dev]

>BTW, HW id's are quite different each other. In my case, HW id has no suffix MI(multiple interface). >Could you check? Other capture or screenshot would be helpful
@cezanne
ok, during the day I will prepare logs and screenshots of the USPsnoop sniffer in order to more fully determine the problem when forwarding a programming device

[kmvi-dev]

@cezanne
https://drive.google.com/open?id=1v4jPttIJc8Jusdse8wfEPruyvo-pbzU-
you can download the archive file from this link, in which you will find screenshots and logs of URB packet capture when connecting the AVRISP mkII programming device locally-LocalConnect-ok folder, using usbip - UsbIpConnect-Err folder. For comparative analysis, I forwarded the programming device using a commercial VirtualHere tool https://www.virtualhere.com/home. The log and screenshots are in the VirtualhereConnect-ok folder . In the usbsnoop folder are the source and build urb package sniffer modules from the https://github.com/SnoopWare/usbsnoop repository

[cezanne]

@kmvi-dev : Thanks for sharing good stuff. I examined all usbsnoop logs.
As you marked, an usbsnoop log of usbip has quite different URB responses. This may be due to that usbip-win does not deliver down the URB request to the bus. But Atmel_winusb driver does not care the difference as a avrmkii device are successfully created via usbip-win.
Of course, a device programming application failed to detect my virtual avrmkii device. Even though a physical device object name was forced to "USBPDO-5", it failed to detect.
So, is there any different device property other than physical device object name?

[kmvi-dev]

@cezanne
in the archive https://drive.google.com/open?id=1vxXhnRoYBAXwXNYEYeRYG-_m2fTzaTNc screenshots of the properties of the AVRISP mkII device that are read by usbdview (https://www.nirsoft.net/utils/usb_devices_view.html) during using virtualhere and usbip.

[cezanne]

@kmvi-dev : Indeed, your new screenshots nicely show the differences between usbip and virtualhere. I tried to use the same device name but the S/W could not detect. Other different factors(power or capability) will be tried. An empty power entry of usbip-win seems to be the highest probable cause of this issue but I can't figure out why usbip-win presents no power entry.

[kmvi-dev]

I think it still comes from the situation that you commented above
#111 (comment)

this may be due to that usbip-win does not deliver down the URB request to the bus

[cezanne]

@kmvi-dev : The vhci driver of usbip-win has not been regarded as a real USB host controller. Because vhci does not support GUID_DEVINTERFACE_USB_HOST_CONTROLLER. It's a very old weakness.(see #46) If it is implemented, usbdeview can find the power and usb version of a usbip-win device and empty entries of usbdeview will be resolved. Of course, device programming S/W is able to find a device virtualized by usbip-win via hub device interface.

So... I will have a try to implement

[kmvi-dev]

@cezanne
Did I understand you correctly? Will you try to implement this support?
if so, you can contact me if you need to check the driver on problem devices and get logs..

[cezanne]

@kmvi-dev :

Did I understand you correctly? Will you try to implement this support?

Almost correct. I hope that the mentioned implementation will resolve your issue.

if so, you can contact me if you need to check the driver on problem devices and get logs..

Sure, I will. Thanks.

[kmvi-dev]

@cezanne
I try according to your prompt #111 (comment)
to develop code for registering the usbip driver as a USB hub, but I can’t.
I have a very vague idea of how to do this.
Could you write me, what needs to be done for such registration of the driver (What kernel functions should be used?).
Or if it’s not difficult for you, indicate where I can read about it.

[cezanne]

@kmvi-dev : I'm trying to restructure usbip-win to support a virtual hub enumerated by vhci. I hope that a new branch will be published soon. Anyway, host controller and root hub interface have been already implemented at roothub branch. But it does not solve your issue because a location path of a device is not properly configured via GUID_PNP_LOCATION_INTERFACE.

[kmvi-dev]

@cezanne this is good news. Thank you. And thank you very much for the roothub branch.
👍

[cezanne]

@kmvi-dev : I'm still working but share the new_vhci branch. usbview seems to show usbip-win but other tools(device programming and usbdeview) cannot detect. More IOCTL's should be implemented or revised.

[cezanne]

@kmvi-dev : Please check the recent new_vhci branch and a release page. Although lots of IOCTL's have been implemented and usbview works well, device programming app does not detect a usbip-win device. usbdeview also fails to show correctly. So, I asked power detection method to the author of usbdeview.

[kmvi-dev]

@cezanne
Thanks, of course ,I will definitely check and write about the results

[kmvi-dev]

@cezanne
I can’t install the driver. I install the driver according to README.md in the manual install section, the screenshot is attached

http://prntscr.com/svc740
http://prntscr.com/svc6qk - error
http://prntscr.com/svcgbu- events
http://prntscr.com/svcgw6
I get the same thing when calling usbip.exe install

The project was build in VS-2017
This is the result of the build
http://prntscr.com/svcc1y

This is a list of built binaries
http://prntscr.com/svcah2

[cezanne]

@kmvi-dev : README.md has not been updated.
You can install manually as follows:

• you should first remove an old usbip_vhci.inf.
  CMD> pnputil /enum-drivers
  You can list up all drivers installed. If you find an old usbip_vhci.inf as oem2.inf, then
  CMD> pnputil /delete-driver oem2.inf
• install usbip_vhci.inf
  CMD> pnputil /add-driver usbip_vhci.inf
• Add legacy hardware. You should select usbip_root.inf

"usbip.exe install" will do upper procecdures. Please confirm that all files are v0.2.0(especially usbip.exe) and usbip_root.inf is copied. My screenshot is attached. (I had tested with binaries in the release page)

[kmvi-dev]

@cezanne
Thank you .
Ok,I will do according to your recommendation

[kmvi-dev]

@cezanne
I have done according to your recommendations
ok
http://prntscr.com/svdr2n
http://prntscr.com/svdrod
but still not working
http://prntscr.com/svdtjd

[cezanne]

@kmvi-dev : Please check a new vhci, which is based on KMDF UDE not WDM. A new UDE-based vhci driver is able to work with usbdeview.

[kmvi-dev]

@cezanne
I checked the version of KMDF UDE on my microcontroller programming device in IDE avr and confirm that this driver version is working with the programming device that is built on the microcontroller from Microchip Technology Inc.
Thank you very much.