Yet another TI3410 serial<->usb talk

[FCPK]

Sorry to actually open up this issue again, but I've been noticing
lots of issues with my launchpads under linux. The serial port(/dev/
ttyACM0) does seem to work just after being plugged, but somehow,
randomly, within a minute or two after working it stops working and
gives i/o error.
Some people suggested it might be HID detection messing up, but even
after disabling it I still see the issue.

Typical symptoms are: tty_port_close_start: tty->count = 1 port count
= 0
while trying to do any operation on ttyACM0(which then i/o errors). If
I read that error correctly it's basically complaining there's no more
port available.


PS: I usually test using: P=/dev/ttyACM0;stty 2400 -ixon<$P;cat $P

Also as far as I can see, it only breaks if you interrupt a program
reading the port and then try to reopen it after it was badly closed.
So maybe there's some missing logic in cdc_acm when closing?


Any hints in this quest to make that usb port usable are welcome;)

[FCPK]

Okay, one more hint to the issue:
If you close and open the port fast enough then it doesn't freak out.
However if I wait more than 3-4s, then it goes input/output error.
That looks like a buffer going full to me. Maybe the TI device, once
it starts sending data, needs to keep it sending or a buffer explodes?

Easy to test with:
P=/dev/ttyACM0;while (true); do stty 2400 -ixon<$P;cat $P|perl -
e'read(STDIN,$_,1);printf"Temp:%0.2f$/",(((unpack C,
$_)-32)*5/9)';sleep 1;done
(works)
P=/dev/ttyACM0;while (true); do stty 2400 -ixon<$P;cat $P|perl -
e'read(STDIN,$_,1);printf"Temp:%0.2f$/",(((unpack C,
$_)-32)*5/9)';sleep 5;done
(breaks)

[FCPK]

After some debugging this morning I am finding out that the cdc_acm
driver gets a 0x22 code(which I believe is disconnect) leading to the
issue. More investigation still seem to indicate a buffer on the ti
chip's side fills up and then asks for a disconnection.(between 8 and
16 bytes non-read create the issue and disconnect everything)
Here is a transcript of a working bucket:
[496322.249690] drivers/usb/class/cdc-acm.c: Entering acm_read_bulk
with status 0
[496322.249706] drivers/usb/class/cdc-acm.c: Entering acm_rx_tasklet
[496322.249710] drivers/usb/class/cdc-acm.c: acm_rx_tasklet: procesing
buf 0xee8ab388, size = 1
[496322.249718] drivers/usb/class/cdc-acm.c: acm_rx_tasklet: sending
urb 0xef112800, rcv 0xee8ab248, buf 0xee8ab388
[496322.249771] drivers/usb/class/cdc-acm.c: Entering acm_tty_write to
write 1 bytes,
[496322.249774] drivers/usb/class/cdc-acm.c: Get 1 bytes...
[496322.249777] drivers/usb/class/cdc-acm.c: acm_write_start
susp_count: 0

And the transcript of when it all goes wrong:
[496322.483695] drivers/usb/class/cdc-acm.c: acm_control_msg: rq: 0x22
val: 0x0 len: 0x0 result: 0
[496322.485283] drivers/usb/class/cdc-acm.c: acm_ctrl_irq - urb
shutting down with status: -2
[496322.486934] drivers/usb/class/cdc-acm.c: Entering acm_read_bulk
with status -2
[496322.486939] cdc_acm 2-1:1.0: Aborting, acm not ready

I'll keep on searching for an easy fix, but if someone has a simple
suggestion to keep that buffer clean, please do tell.
(adding something kernel side so it'll wipe the buffer at regular
intervals just seems very complicated)

[FCPK]

My bad, I misread the message, it's actually when opening the tty that
the 0x22 is sent, and then the disconnect occurs. So TI's TU3410 must
be acting weirdly there. Not sure how can one fix it.

[simpleavr]

i've also spend time on and off on this issue. i am getting similar
results, same logs and errors, erc. so there's nothing much to add to
your findings. i saw u also post in gmane.linux.usb.general on this
issue.

my use case is different though, i had my LP only sends data after
receiving a "command" byte from a perl script, and when the host side
perl script exits, it also sends another "command" byte to ask the LP
firmware to stop sending. i can get a good session running but once i
quit the host side perl script, i cannot run another session w/o
unplug and replug the LP.

i think u may find useful is to load the usbmon module to dig deeper.
it may help u post more details to the gmane group.

http://www.mjmwired.net/kernel/Documentation/usb/usbmon.txt

[FCPK]

I've had some more time to experiment and talk to linux-usb guys.
I did find a way to make the device not freeze so badly it'll stop
being usable, at least most of the time.

In cdc_acm.c
disabling the bailout in acm_tty_open:
> if (0 > acm_set_control(acm, acm->ctrlout = ACM_CTRL_DTR | ACM_CTRL_RTS) &&
> (acm->ctrl_caps & USB_CDC_CAP_LINE))
> goto full_bailout;

and acm_set_control in acm_port_down:
> acm_set_control(acm, acm->ctrlout = 0);

This has an unwanted effect though of not "resetting"/"stopping"
incoming bytes while there are no readers, and that when you connect a
reader(minicom, cat, whichever) you get up to 250-ish bytes suddenly.
(my guess is that it's because the driver isn't polling during that
time)

Anyone wanting to get his hands a little dirty to fix that is
welcome:)

[simpleavr]

thanks a lot for the info and follow-up.
i am not pursuing this anymore though. i am now getting reliable comms
by always have a host side script to start / stop communication, and
do clean-up on the port before exit.

i.e. on host side, use write_drain() to always drain out the serial
buffer.

for faster apps, i now uses a nokia phone cable w/ pl2303 chip.

thanks again for sharing.