Teensy 3.2 with Raspberry Pi: USB stops working when ignored too long?

Status
Not open for further replies.

JBeale

Well-known member
This seems like a beginner question, I thought I'd passed that stage but apparently not!

I have a Teensy 3.2 which prints one line of text (data from ADC) every half-second or so, using Serial.println() so this goes out using its USB and not a true serial port.
The exact code is this https://github.com/jbeale1/DataAcq/blob/master/FMES-ADS1115.ino and it works 100% OK when connected to my Linux Mint "fitlet2" MiniPC. I can run the receiving program, stop it for any length of time and restart and there is no problem.

Now I unplug my Teensy's USB cable from the miniPC, and plug it into a Raspberry Pi. I have already installed the 49-teensy.rules file in /etc/udev/ and 'dmesg' shows ttyACM0 is there:

Code:
[  914.149878] usb 1-1.5: new full-speed USB device number 8 using dwc_otg
[  914.282643] usb 1-1.5: New USB device found, idVendor=16c0, idProduct=0483
[  914.282659] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  914.282668] usb 1-1.5: Product: USB Serial
[  914.282676] usb 1-1.5: Manufacturer: Teensyduino
[  914.282684] usb 1-1.5: SerialNumber: 1231730
[  914.283801] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device
and the Teensy shows up with 'lsusb'
Code:
pi@rp48:~/FMES $ lsusb
Bus 001 Device 008: ID 16c0:0483 Van Ooijen Technische Informatica Teensyduino Serial
Bus 001 Device 005: ID 413c:2005 Dell Computer Corp. RT7D50 Keyboard
Bus 001 Device 004: ID 04f2:0939 Chicony Electronics Co., Ltd 
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I am running the same Python3 program on the miniPC and the Raspberry Pi to log the serial data from Teensy to a file,
this is the code: https://github.com/jbeale1/DataAcq/blob/master/serial_log.py

It always works on the MiniPC, but it does NOT always work on the Pi. In particular it will work after a physical unplug-usb-replug cycle. It will still work if I stop the receiving Python program on the Pi for a short time (few seconds) and restart it quickly. If I stop for several minutes, and then restart the program on the Pi (while the Teensy has been continuing to run), then the Python program sees nothing from the serial port and always just times out on read. There is no error, the /dev/ttyACM0 port is present and can be opened, but no data is coming from the Teensy, However I can see from my use of pin 13 LED that the Teensy continues to cycle through its code just as before. Unplug/Replug the USB and restart the Python and it works again.

I guess this has to do with how USB buffering is handled (after some buffer size is filled, it looks like somebody just "gives up") but I'm not sure where exactly the problem lies or how to work around it. Is it because stopping Python with Control-C doesn't close the port, that it gets lost? Is the difference that Linux Mint auto-fixes that for me on the fitlet MiniPC, unlike the Raspberry Pi? Does this ring any bells with anyone? Thanks for any advice!
 
I would try minicom, picocom, and screen (sudo apt install minicom picocom screen). See if enabling/disabling hardware flow control and DTR make a difference. This is USB serial versus UART serial so SHOULD not make a difference but they might. Or modify the Python program to toggle the same options.
 
Thanks for the reply, I will try that. I have since found that my Python program sometimes still does work after longer delays "off" on the Pi- but not always.
There is apparently something "funny" about the DTR and RTS lines when opening a USB serial port using pySerial in Linux, if I'm reading this right: https://github.com/pyserial/pyserial/issues/124
 
Update: I have tried each of the suggested serial programs (minicom, picocom and screen). They all work in the same manner as my Python program, that is, they show the data coming from Teensy as expected once it has been freshly reset by re-plugging the USB, but they also show no data when the port has become blocked somehow, even though Teensy continues to run sending data, and there is no error on the R-Pi side and the /dev/ttyACM0 port opens normally from what I can tell. Odd.
 
Well this is definitely a workaround (hack) rather than actually fixing whatever the problem really is. However, it has the cardinal virtue of just working.
Basically, reset the USB device from the R-Pi side just prior to using it. Seems to work as well in this case as physically unplugging the Teensy USB cable.

Code:
#!/bin/bash
# reset Teensy device, knowing its USB VENDOR:PRODUCT id numbers

VENDOR=16c0
PRODUCT=0483

for DIR in $(find /sys/bus/usb/devices/ -maxdepth 1 -type l); do
  if [[ -f $DIR/idVendor && -f $DIR/idProduct &&
                $(cat $DIR/idVendor) == $VENDOR && $(cat $DIR/idProduct) == $PRODUCT ]]; then
            echo "Resetting USB Device $DIR"
            echo 0 > $DIR/authorized
            sleep 0.5
            echo 1 > $DIR/authorized
  fi
done
 
Status
Not open for further replies.
Back
Top