search

openxc / vi-firmware

OpenXC-compatible firmware for PIC32 and LPC1768
http://vi-firmware.openxcplatform.com
BSD 3-Clause "New" or "Revised" License
197 stars 105 forks source link

Not enumerating as a USB device in Windows #34

Open peplin opened 11 years ago

peplin commented 11 years ago

The device will not enumerate properly in Windows 7. On first attach, Windows spins for a bit and then reports "Unrecognized device". After that, nothing shows up in the Device Manager. Looking at the translator itself, it's initializing and then getting reset over and over again.

I looked into which USB event codes are being received on the device, and oddly they are 117 once and 115 multiple times - not the EVENT_CONFIGURED that we expect on other platforms. The details of this are hidden in the Microchip USB stack, so I'm a little stuck there.

Also interesting is that it seems like it's resetting the entire PIC32, not just the USB stack. The green LED goes back to flashing for 5 seconds, which is what I usually expect when it first starts up.

This needs to be fixed before you can use the CAN translator directly from Windows, e.g. with the Python library.

peplin commented 11 years ago

This may be related to #10 and #11.

peplin commented 11 years ago

Something to test is one of the chipKIT example programs - see if that enumerates and then isolate the differences. Could be problems in the USB descriptor or in how/when we call the USB event handler.

peplin commented 11 years ago

On the master branch with the emulator flashed the device enumerates and I'm able to install a libusb-win32 inf driver. It works fine with openxc-dump. Switched back to next and it still works. Suspicious.

Power cycle it with the same next branch flashed and then it's back to the no-emueration loop.

Detached all cables, then attached only micro-USB (with power jumper in place) - works fine.

Detached all cables, detached power jumped. Attached micro, then attached mini. Non-enumeration loop.

Tried some more things and I couldn't really find a pattern. Is this a race condition?

peplin commented 11 years ago

I think I figured out the root cause. The way to trigger this bug is to have both the mini and micro USB ports attached to a Windows machine.

Previously I was testing with the min (virtual COM port) attached to Linux (where I was flashing it) and the micro (CAN translator device) attached to a Windows VM. That was where I was having trouble replicating the issue.

Attach both of them to the Windows VM (or native Windows machine), and it goes a little crazy. My suspicion is that the FTDI driver, when attached, is constantly sending the RESET signal, so it goes like this:

Next question: why is the FTDI driver trying to reset the device over and over again?

If someone has a fix for that, great. Otherwise, we already strongly recommend against attaching both the mini and micro USB cables at the same time because of power conflict issues, so I think this is safe to ignore.