Teensy 3.2 freezing while printing to Serial

Status
Not open for further replies.
A

acastles91

Member
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));
}
 
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);
	}
}
 
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)
 
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?
 
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.
 
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

teensy.jpg
 
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?
 
PaulStoffregen said:
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?
Click to expand...

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.

teensy-sensor.jpg

teensy-no-sensor.jpg
 
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.
 
manitou said:
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.
Click to expand...

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.

teensy-3.jpg
 
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.
Click to expand...

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!
 
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?
 
acastles91 said:
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 to expand...
this works for me: sudo apt-get purge modemmanager
 
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!
 
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.
 
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.
 
Status
Not open for further replies.
Back
Top