[quote user="Frank McKenney"]
This condition appears to persist until the LaunchPad is unplugged andreplugged. In particular, pressing the LaunchPad RESET button (S1)
does not clear the condition, indicating that the problem is either in the host driver or the LaunchPad firmware (e.g. the TUSB3410 USB
interface chip).
This forum post describes it as a driver problem:
Linux Serial Driver for the Launchpad Bugs
http://forum.43oh.com/topic/935-linux-serial-driver-for-the-launchpad-bugs/
but I'm not sure I agree. I reproduced the problem on an embedded Linux system (OpenWrt), then unloaded and reloaded theti_usb_3410_5052 driver using rmmod and insmod. This did not clear the error condition, which makes me suspect that it might be a TUSB3410firmware problem.
<SNIP>
I attempted to reset the /dev/ttyACM0 device using a Linux utility called 'usb_modeswitch':
usb_modeswitch -R -v 0x0451 -p 0xf432
but only succeeded in making /dev/ttyACM0 disappear. Fortunately, unplugging and replugging the LaunchPad brought it back. <grin!>
[/quote]
I'm running a Forth compiler (noforth) on the board, with a communication program written in Forth on Linux Debian stable.
This means total control! I can ask the Launchpad to generate primes till 10,000 and then disconnect, i.e.
not reading the output, and close the filedescriptor. This is a surefire way to hang up the device forcing a powercycle.
Attempts to flush the device (so using the communication driver to program around problems in the 3410) also meets with problems, I see a defect in the select system call. (A return before the timeout with no devices activated.) The communication program sees no data for 5 seconds, so it thinks it can safely close the connection. However, it draws that conclusion before 5 seconds have passed, go figure.
It is no wonder that it is flaky. There are independant defects in the 3410, the linux driver and also in the software that generates entries in the /dev directory. It keeps deleting and regenerating the /dev/ttyACM0 device, which should not happen, whatever the state of the device.
The problem lies, of course, with usb, which is one big design error if you ask me. Humans can't make usb work.
Groetjes Albert