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

Thread: Teensy 3.2 freezing while printing to Serial

  1. #1
    Junior Member
    Join Date
    Dec 2019
    Posts
    9

    Teensy 3.2 freezing while printing to Serial

    Hello. I am trying to do a very simple measurement of a sensor and both
    Code:
    analogRead()
    and
    Code:
    digitalRead()
    output to the console for a very short moment and then the program becomes irresponsve until I press the button and reboot the teensy. The code I'm running is very simple. The sensor is a QRE1113 (reflective sensor), which is connected to pin 21, to GND and to 3.3V. What I'm I doing wrong?

    Code:
    const int sensor = 21;
    
    
    void setup() {
    pinMode(sensor, INPUT);
    Serial.begin(115200);
    }
    
    void loop() {
    Serial.println(analogRead(sensor));
    }

  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,602
    Printing too fast for the computer to keep up perhaps. Try working with something like this:
    Code:
    const int sensor = 21;
    
    void setup() {
    //pinMode(sensor, INPUT);
    	Serial.begin(115200);
    	while (!Serial && millis() < 4000 );
    	Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
    }
    
    uint32_t aLast = 0;
    void loop() {
    	uint32_t aNow = 0;
    	aNow = analogRead(sensor);
    	if ( aNow != aLast ) {
    		aLast = aNow;
    		Serial.println( aNow );
    		delay(1);
    	}
    }

  3. #3
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,211
    Yes printing too fast can actually lag the java window enough that the IDE freezes to a halt
    Same thing happens with full page refreshing in canbus debugger im working on, 1ms can lock up the IDE but 10ms is ok, depending on line length (i ran into the full page looong line length issue that was ressolved by introducing more delay)

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,330
    Printing too fast from Teensy 4.0 with 480 Mbit/sec speed is definitely an issue on Windows.

    But Teensy 3.2 with only 12 Mbit/sec USB should not be able to overwhelm the serial monitor, especially if using 1.48 or 1.49-beta3 with the new serial monitor speedup.

    I'd look at what's happening with the power supply. Is it stable?

  5. #5
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,602
    Indeed 'current' SerMon on Modern computer should have no trouble with 12 Mbit/sec USB - though in the past it could. And currently on this machine with a Teensy 4 running post #2 code without delay(1) it causes no trouble

    One anomaly - perhaps also a historical or random remembrance - is that full throttle printing before Serial is actually online can result in issues after the transition to SerMon online. Not seeing that as an issue now on this T4.

    p#2 code will assure SerMon is online before printing and limit output to no more than 1,000 message Print()'s per second with changing values - still too fast for human consumption.

    If that still fails there is another issue with the SerMon connection.

    Also in that p#2 code was the removal by comment of the setup() of the analog pin to digital prior to use - which the analog code reverts on use.

    @Paul: if that line " //pinMode(sensor, INPUT); " is not removed the analog value read is changed - using a Teensy 4 - it floats HIGH after that rather than LOW? Suggests that setting as INPUT changes something not unchanged in analog setup? The pin does exhibit full range 0-1023 in both cases when fed GND or 3.3V. And that persists until the T4 is re-powered.

  6. #6
    Junior Member
    Join Date
    Dec 2019
    Posts
    9
    Thank you all for your answers. I think the power is stable, but I am not 100% sure. I'm running it from the USB port though: I had a whole PCB but it was thought for an arduino nano, until a friend recommended me the teensy so I have basically just rewired my existing board to it with jumper wires (sorry for the ugly picture). That means that I haven't connected anything to the VIN pin, since the 12V that I have would damage the teensy, right? Is there an easy way to check if the power from the USB is stable? Also, I am running Linux and the arduino IDE is 1.8.10

    Click image for larger version. 

Name:	teensy.jpg 
Views:	7 
Size:	213.9 KB 
ID:	18515

  7. #7
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,330
    If you run that simple program (from msg #1) without Teensy connected to the other hardware, does it continue printing meaningless floating-input measurements forever?

  8. #8
    Junior Member
    Join Date
    Dec 2019
    Posts
    9
    Quote Originally Posted by PaulStoffregen View Post
    If you run that simple program (from msg #1) without Teensy connected to the other hardware, does it continue printing meaningless floating-input measurements forever?
    Thank you for your fast response. This is how it looks both with nothing apart from the sensor connected to GND, 3.3V and pin 21, and with nothing at all. In both cases the serial monitor is completely unresponsive and I can only close it once I press the reboot button.

    Click image for larger version. 

Name:	teensy-sensor.jpg 
Views:	8 
Size:	82.0 KB 
ID:	18520

    Click image for larger version. 

Name:	teensy-no-sensor.jpg 
Views:	5 
Size:	85.8 KB 
ID:	18521

  9. #9
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,322
    So as mentioned in earlier posts, did you try adding delay(10); to the loop() ?

    what OS/version are you running? your photos seem to show ModemManager running ... I don't think the "kill" will get rid of ModemManger, it just restarts. You could try using your package manager to remove/purge modemmanager.

  10. #10
    Junior Member
    Join Date
    Dec 2019
    Posts
    9
    Quote Originally Posted by manitou View Post
    So as mentioned in earlier posts, did you try adding delay(10); to the loop() ?

    what OS/version are you running? your photos seem to show ModemManager running ... I don't think the "kill" will get rid of ModemManger, it just restarts. You could try using your package manager to remove/purge modemmanager.
    Hello @manitou. I am running Ubuntu 18.10. I did add the delay to the loop but it didn't help, the monitor now shows less readings but is still frozen nonetheless. I don't know why but when I try to uninstall ModemManager through my package manager it doesn't find it.

    Click image for larger version. 

Name:	teensy-3.jpg 
Views:	8 
Size:	76.4 KB 
ID:	18522

  11. #11
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,330
    Maybe you have an older version of the udev rules file? This is the latest:

    https://www.pjrc.com/teensy/49-teensy.rules

    It was updated several months ago when Ubuntu changed ModemManager's default filter policy, to supposedly make it more secure, but that change had a terrible side effect of again causing ModemManager to interfere with Teensy and Arduino and many other types of boards. The old 49-teensy.rules file had only ID_MM_DEVICE_IGNORE, which was supposed to tell ModemManager not to interfere with Teensy. But the settings change Ubuntu pushed to all users several months ago caused it to disregard ID_MM_DEVICE_IGNORE. The new version has both ID_MM_DEVICE_IGNORE and ID_MM_PORT_IGNORE.

    So even if you already have this file installed in /etc/udev/rules.d/49-teensy.rules, perhaps you have the old version?


    I don't know why but when I try to uninstall ModemManager through my package manager it doesn't find it.
    Yeah, getting rid of ModemManager is so much harder than it should be. Even if you think you've completely removed ModemManager, make sure you have the latest 49-teensy.rules, because ModemManager seems to a really annoying tendency to keep coming back and causing more trouble!

  12. #12
    Junior Member
    Join Date
    Dec 2019
    Posts
    9
    I just copied the new version udev rules but the problem persists. I tried to upload my main code from platformIO and it says
    Code:
    Hangup
    *** [upload] Error 129
    ================================================= [FAILED] Took 2.57 seconds =================================================
    The terminal process terminated with exit code: 1
    Did I brick my teensy? How can I check if my USB port is providing enough energy?

  13. #13
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,322
    Quote Originally Posted by acastles91 View Post
    Hello @manitou. I am running Ubuntu 18.10. I did add the delay to the loop but it didn't help, the monitor now shows less readings but is still frozen nonetheless. I don't know why but when I try to uninstall ModemManager through my package manager it doesn't find it.
    this works for me: sudo apt-get purge modemmanager

  14. #14
    Junior Member
    Join Date
    Dec 2019
    Posts
    9
    Thank you all for your help, it works now! with the help of defragster's code I have a constant reading of the sensor and the IDE doesn't freeze anymore. I have a separate question now that this is working, I will post it soon in a new thread, thanks!

  15. #15
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,330
    Looking at your screenshots again, I see you've selected from the "Serial ports" part of the Tools > Ports menu. Your Teensy should appear twice in that menu, also in a "Teensy ports" section.

    If you use the "Teensy ports" selection, a highly optimized version of the serial monitor is used. A small "teensy_serialmon" helper program runs, which does all the communication with the hardware in an optimized way. No Java code ever talks to the hardware.

    If you use the "Serial ports" selection, you get the ordinary serial monitor where Java and the JSSC java library talk to the hardware. None of the special Teensyduino optimizations for serial monitor performance are used.

    Maybe not an issue if you've already solved the problem another way, but wanted to just mention this in case you need more speed later, or use Teensy 4.0 (which has 480 Mbit/sec USB), or anyone else with a similar problem later finds this thread.

  16. #16
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,602
    Indeed the "Teensy Ports" is the right one to use. Not only the better throughput - but it also reconnects better after going offline it will come back online when the Teensy returns more reliably. Using the IDE "Serial Ports" version often requires SerMon window Close and Open to reconnect.

Posting Permissions

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