Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 5 of 5

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

Hybrid View

  1. #1
    Senior Member
    Join Date
    Oct 2012
    Location
    Portland OR
    Posts
    593

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

    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/b...ES-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/b.../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!

  2. #2
    Member
    Join Date
    Jul 2018
    Posts
    38
    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.

  3. #3
    Senior Member
    Join Date
    Oct 2012
    Location
    Portland OR
    Posts
    593
    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

  4. #4
    Senior Member
    Join Date
    Oct 2012
    Location
    Portland OR
    Posts
    593
    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.

  5. #5
    Senior Member
    Join Date
    Oct 2012
    Location
    Portland OR
    Posts
    593
    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •