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

Thread: T3.5 Serial Halting Problem

  1. #1

    T3.5 Serial Halting Problem

    I've used the T3.2 for years, and this is a strange problem that should be beneath me, but I can't figure it out.

    Teensy 3.5.
    Arduino IDE 1.8.9
    Teensy Loader 1.46

    Code:
    Code:
    void setup() {
      Serial.begin(57600);
      pinMode(LED_BUILTIN, OUTPUT);
    }
    
    void loop() {
      delay(1000);
      Serial.print("Hello  ");
      Serial.println(millis());
      digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
    }
    I am unable to get reliable serial data. The LED is flashing, and I must power cycle multiple times until the USB serial connection is reliable. kernel messages seem normal for the USB negotiation. The first cat of the port gives me a buffer full, then the next cat hangs waiting for more data. Miniterm gives the same result.


    Code:
    root@michalk-desktop:~# cat /dev/ttyACM0
    Hello  1300
    
    Hello  2300
    
    Hello  3300
    
    Hello  4300
    
    Hello  5300
    
    Hello  6300
    
    Hello  7300
    
    Hello  8300
    
    Hello  9300
    
    Hello  10300
    
    ^C
    root@michalk-desktop:~# cat /dev/ttyACM0
    ^C
    root@michalk-desktop:~# cat /dev/ttyACM0
    Update:
    If I use the Arduino serial monitor, it's initially grey, then when the Teensy boots, it shows the serial data. I can close the Arduino serial monitor, and open miniterm, or cat the device, and it functions as expected.
    If I replug the Teensy without the serial monitor running, Miniterm, or cat do not work. It seems there's some handshake that's happening when the program first starts, and the serial monitor is allowing it to work properly. How can I get this to work without the serial monitor?
    Last edited by brianmichalk; 10-16-2019 at 09:34 PM. Reason: Update

  2. #2
    It looks like the udev rules fixed this problem. I'm not sure when they changed, and a system update probably caused this problem. The udev rules from the install web page fixed this problem.

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,690
    Ubuntu recently changed the default ModemManager filter policy. Maybe other distros did too? In theory, it's the sort of settings change that's supposed to improve security or something.

    ModemManager has a documented behavior to ignore certain things in that mode. Whether you see that as a feature or bug is a matter of opinion. The ModemManager developers have made improvements so explicit udev rules will no longer be ignored in that mode (the stuff it's supposed to ignore has been renamed), but it will take years for those improvements to be updated to mainstream Linux distros.

    We updated the udev rules shortly after this problem began, to also tell ModemManager to not interfere in a 2nd way (ports vs devices). ModemManager still sees Teensy, but fortunately it does seem to prevent ModemManager from causing trouble. That's why updating the udev rule fixes this problem. It's all ModemManager misbehaving.

    Long ago, it seemed like every year another ModemManager bug or "feature" would haunt us. It's been a few years of quiet, but sadly ModemManager came back yet again this year to disrupt Teensy and Arduino and so many others. I really don't like ModemManager...

  4. #4
    Junior Member
    Join Date
    Oct 2016
    Posts
    19
    For all my Linux development I have removed ModemManager.
    sudo apt-get purge modemmanager

Posting Permissions

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