Hi Alan Thanks for this. I agree that the fault looks like it's in the aurora program (not mine, but I do have the source, and I've pulled some bugs out of it). Now I've got a much better handle on the robustness of the USB behaviour, I can start to focus on the aurora code. Thanks again Tim On 26 Jan 2012, at 16:28, Alan Stern wrote: > On Thu, 26 Jan 2012, Tim Coote wrote: > >> Well the inverter now seems to come up and want to play. ModemManager >> is certainly something that I took off the linux box and maybe that's >> all that was probing the device. > > There doesn't seem to be anything causing similar problems now. > There's only the usual issue of the device not getting enough power > until about 15 minutes after the Sun first comes up. > >> So maybe I've reached the point where I'm 'only' debugging the C >> program that thinks it's talking to a serial device. The device is >> not as reliable as if it's booted up unconnected to Linux, but I >> cannot quantify the variation, yet. My guess is that ModemManager was >> stopping the device dead, but something else is going wrong now >> (quite possibly the C program, but I wouldn't have thought that it >> was able to.) > > The worst error messages I see are a bunch of lines saying: > > Problem flushing before sending command: (5) Input/output error > Problem draining command: (5) Input/output error > > around 11:19:00. This was not caused by a disconnection; instead the > cause appears to have been noise in the USB signal. Whatever it was, > it cleared up in less than 1/2 second and the device started working > again. In the remainder of the wireshark trace, the device seemed to > work well. > >> I did manage to capture /var/log/messages (now called msg1) from the >> time of reboot until I managed to run a few tests by hand. I >> remembered to set up usbfs_snoop. I *think* that this shows that it >> took a while, but the inverter finally came up as device 91 on bus 3. > > That's right. > >> I also captured a typescript and the wireshark dump. The typescript >> has some timing information in it, but maybe not enough. >> >> I was essentially trying a couple of versions of the commands: >> /usr/local/bin/aurora -Y 10 -T -a 2 -v /dev/ttyUSB0 >> >> This should interrogate the inverter on through the serial port /dev/ttyUSB0 (which is of course the USB device behaving like a serial port, using the ti_usb_3410_5052 kernel module), -a 2 is the address of this particular inverter (dunno why it's 2), -Y 10 should try 10 times to get interrogate the device, -v just returns the devices type (the simplest thing that I think I can ask for. -T prints the current computer time - I should have put this in all commands, but forgot for some. >> >> other commands replace the -v with -d 0 or -e, which should return some data on the device status. >> >> as far as I can tell, -v usually works (but not always) and -e / -d 0 don't. I don't understand how to interpret the wireshark interactions that are going on, but they do seem to be excessively lengthy. At this stage, just getting a hint as to what's causing the interaction to be less robust than for windows would help. >> >> Here's the files: >> http://dl.dropbox.com/u/10589123/msg1 >> http://dl.dropbox.com/u/10589123/typescript >> http://dl.dropbox.com/u/10589123/usb3OverSunUpAndSomeInteractions >> >> It is possible to correlate most of the commands in typescript with >> msg1 and the wireshark file. However, working out what the command is >> in each case is not always so obvious, I don't think. > > There are a few lines saying "CRC receive error" or "No response". I > get the feeling they are the result of bugs in the aurora program > rather than problems in the device or the USB connection. Or maybe > there's a bug in the ti_usb_3410_5052 driver, but that seems less > likely. > > 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
