On Sun, 9 Sep 2012, Florian Wöhrl wrote: > > Clearly the device doesn't like your RPi system. There's some sort of > > hardware-level incompatibility; it may even be a question of available > > power as Greg suggested. You should try adding a powered hub between > > the computer and the device, just to see if it helps. > > > > As for the desktop systems, there's no way to tell what's happening. > > As far as I can see, the device should work okay with both of them all > > the time. The only reason I can imagine for it not working with Ubuntu > > 12.04 is that the RPi somehow left it in a weird invalid state. But > > that doesn't explain why plugging it into the other computer would > > clear out that state. > > > > By the way, I also get the impression that what matters is the computer > > hardware and not the kernel version. That is, I bet if you would use a > > different kernel on the RPi the device would still fail, and if you > > would switch the kernels on the desktop machines then the behavior > > would follow the machine, not the kernels. > > > > Alan Stern > > I don't think, that it was the RPi - because now it even works on the > RPi. Furthermore I had the problems before RPi with Ubuntu 12.04 on the > same desktop machine I used to run with 10.04. In order words, the device now works with the same computer and OS that it used to fail with before. Then this could be a problem in the device itself or in the USB connection. > Now with my RPi: > > # dmesg: > [95542.802826] usb 1-1.3: new full-speed USB device number 34 using dwc_otg > [95542.907487] usb 1-1.3: New USB device found, idVendor=04d8, > idProduct=000a > [95542.907531] usb 1-1.3: New USB device strings: Mfr=1, Product=2, > SerialNumber=0 > [95542.907550] usb 1-1.3: Product: CDC RS-232 Emulation Demo > [95542.907564] usb 1-1.3: Manufacturer: Microchip Technology Inc. > [95542.914838] cdc_acm 1-1.3:1.0: This device cannot do calls on its > own. It is not a modem. > [95542.915160] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device > [95543.000841] USB Serial support registered for FTDI USB Serial Device > [95543.004692] usbcore: registered new interface driver ftdi_sio > [95543.004721] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver > > I still think, that some change in the code is responsible. Did you change the software on the RPi between this run and the earlier runs? If a software change is responsible, the most likely place is in the dwc_otg driver. > So - how can the kernel/drivers change the behavior of the device on > other machines? They can't. > I don't get it. Is there some kind of firmware uploaded > by the drivers? If there were, it would show up in the usbmon traces. The failure traces showed that the device failed during initialization long before any firmware could be uploaded. > It seems like some driver coming with 3.2.x left the > Board in a strange state. Maybe the newer driver(s) contain a new > "feature" introduced for other boards (initialization / firmware upload) > that doesn't jar with my "older" board ? > > Do you think it's possible to get the "faulty state" if the board is > unplugged for a while? I think I never tried to plugin the device within > seconds after using it with my Ubuntu 10.04 machine. Can the "good > state" be lost if the board has no power for some time? Will try that > over night... Does the device have its own power supply, or does it run off of USB bus power? Removing all power from the device should clear out its state very quickly (like a fraction of a second) unless it has some sort of battery or flash memory. > Whats the purpose and functionality of firmware in that case? Has that > chip some kind of Flash ROM? How would I know? It's _your_ device. :-) > Afaik there's some basic "programming" on > the board because the chipset needs programming. ( > http://www.microchip.com/pagehandler/en-us/family/8bit/) > > I'll now continue with programming the interface with python and > pySerial - to see if it's stable. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
