Serial Issue with Teensy

Status
Not open for further replies.
Oh, wow, really looks like something within the Arduino IDE. Wouldn't have guessed that!

Can you try one more test?

Teensyduino makes changes to Arduino's serial monitor. Maybe they're related? If you look at the title bar of the serial monitor window, it says "TeensyMonitor". That means you're running Teensy's modified serial monitor.

If you close the serial monitor window, then select a non-Teensy board in Tools > Boards, and open the serial monitor again, you should get the original serial monitor without Teensyduino's patches. You'll know it's Arduino's original version when the title bar shows only "/dev/cu.usbmodem2397461 (Teensy)" without the word "TeensyMonitor".

If that makes a difference, then I'll start trying to figure out what I might have done that's messing up the serial monitor. If both fail, then at least we'll know it's something deeper in the Arduino IDE or Java or JSSC. Either way, I really do want to get to the bottom of this, if you're willing to keep doing tests and help narrow down where the problem really is.



Of course I`m willing to keep testing and if I can I will help to isolate this Bug.
It does not change, in both cases TeensyMonitor: /dev/cu.usbmodem2397461........ is written in the title bar.

View attachment 12172
View attachment 12173
 
Last edited:
i have now not only restarted the Serial monitor, but also restarted the Arduino IDE.
now the Titlebar looks like you said, only "/dev/cu.usbmodem2397461 (Teensy)"
Still the same Problem..
 
now the Titlebar looks like you said, only "/dev/cu.usbmodem2397461 (Teensy)"
Still the same Problem..

Hmmm... ok, looks like the project is somewhere in the IDE, Java or JSSC.

I'm out of guesses for the moment, but I'll be thinking on this.....


But what confuses me is that under / Library / Java / Extensions no RXTX extension can be found.

Arduino switched from RXTX to JSSC a couple years ago. As I recall, they've since had to patch or maintain JSSC, though I don't recall the details. It's all buried somewhere on the old github issues.
 
PeterG - prior post had link to old TyCommander - it moved to github - between working with Paul if you want to see if this works - to find a solution to show your machine can be usable. The link updated in prior post is : github.com/Koromix/tytools/releases. Version is 0.8.8-11 - I wondered why I linked to something like 0.8.0 :(
 
PeterG - prior post had link to old TyCommander - it moved to github - between working with Paul if you want to see if this works - to find a solution to show your machine can be usable. The link updated in prior post is : github.com/Koromix/tytools/releases. Version is 0.8.8-11 - I wondered why I linked to something like 0.8.0 :(



I do not understand what you mean by this sentence. " to find a solution to show your machine can be usable." ??
TyCommander works perfect... It is especially funny that they work at the same time.
while TYCommander works properly and arduino not. ;)

Bildschirmfoto 2017-12-07 um 02.14.58.jpg
 
Awesome - It seems: "You have shown your machine to be usable"
> Awkward wording to avoid pointing any fingers ... - Showing it wasn't some hardware problem causing the trouble or an id10t error - but a failure from the software at hand where functionality is possible.

When using BOTH - only one can claim the USB 'port' of course. That applies to Teensy Loader too - you may also see contention with Teensy Loader if both are loaded - you certainly need to click the blue 'Serial' icon to gray it to allow upload. I assume on MAC the 'Tools / Integrate to Arduino' will take Teensy Loader out of the picture ( when closed ) it will have the IDE defer to TyCommander to perform the upload and coordinate with the Serial connect of course since it is the self same program.
 
not true, Xport can split a com port so two devices can connect
used this back in carPC days to use a single GPS bluetooth to feed both speedometer and nmea data for two different apps..
 
Dual connect isn't standard on Windows - and never looked for it. One connection gets it - the other cannot. I wonder if that is behind the earlier issues?

tonton81 - have you tried TyCommander? You noted (on other thread IIRC) buffers get too large with SerMon - TyCommander allows limiting their size so they don't get out of hand. Also it used to be faster than SerMon - but last I saw they were in the same magnitude.
 
normally this is not possible on OSX. Well ofcourse with special Soft- or Hardware it is.

What makes it even more funny is that I not only can Read simultaneously, it is also possible to send Serial commands simultaneously! :)
 
not yet, i dont seem to have issues with teensy and sermon even when flooding it in a tight loop, i figure usb speed is fast enough to cope, doing it with an esp8266 for example would lock up the IDE itself within seconds, requiring the user to force close via task manager :p
 
Grasping ...

1) looking for other processes using USB port: with serial monitor open, do: lsof | grep modem

2) when just printing value of i in loop, if you switch from monitor to "Serial Plotter" in IDE, i presume you still have missing values?

3) you said you switched languages, but seems like i've read about arduino IDE problems that were sensitive to language ??? IDE has language preference, as does MAC OS

4) do you have UNO or non-teensy arduino MCU you can test
 
Grasping ...

1) looking for other processes using USB port: with serial monitor open, do: lsof | grep modem

2) when just printing value of i in loop, if you switch from monitor to "Serial Plotter" in IDE, i presume you still have missing values?

3) you said you switched languages, but seems like i've read about arduino IDE problems that were sensitive to language ??? IDE has language preference, as does MAC OS

4) do you have UNO or non-teensy arduino MCU you can test

1) only Arduino is connected to the USB port.

Bildschirmfoto 2017-12-07 um 12.24.51.jpg

2) Yes same error.
3) i have not switched! I have tried different Languages to find out if there is an connection between the error and the Language.
I have changed System Language, and Arduino Language, I have done an OSX update, an Arduino and Teensyduino update & downgrade, I have updated JS.
I have disconnected Bluetooth stuff, mouse, Trackpad, Keyboard, etc. Nothing else connected to The iMac at all.
I have tried with and with out WLan...... and many more.

4) Arduino Nano no problems tried it many times!
Teensy LC Same Problem!

Bildschirmfoto 2017-12-07 um 12.44.36.jpg
Bildschirmfoto 2017-12-07 um 12.40.25.jpg
 
I was going to suggest trying Arduino 1.0.6. That old version uses RXTX instead of JSSC. But perhaps 1.0.6 can't even run on modern Macs?
 
Tried it with Arduino 1.0.6, Teensy Loader 1.4, Teensy 3.5

Samer error

Bildschirmfoto 2017-12-07 um 12.58.29.jpg


edit:
system restart after installing Arduino v1.0.6 does not have any positive effect, still same error
 
Last edited:
From what I allow to deduce that it's neither an Arduino IDE, nor a Teensyduino, nor a Teensy loader issue. Which means that the OSX / macOS installation might be corrupted by whatever not correctly functioning kext module which under several conditions might interfere with the serial communication.

Any chance to reboot your Mac in safe mode with only the strict minimum of drivers and background tasks loaded?
 
Ok, here's a new theory. Maybe the data loss is somehow happening inside Arduino when the raw incoming data is getting translated to unicode?

I'm not sure how to test this theory (well, "guess" would be a better word). Maybe try using the "defaults" command which was the workaround for the High Sierra non-US menu bug before Arduino 1.8.5.

https://blog.arduino.cc/2017/10/02/arduino-ide-1-8-5-hotfix-for-macos-high-sierra-users/

For a copy of Arduino that has Teensyduino installed, you'll probably need to use this command:

Code:
defaults write cc.arduino.Arduino.teensyduino AppleLanguages '(en)'

But I must admit, how Java really handles the language settings isn't something I really know. It could be other settings that influence how bytes are turned into unicode chars.

The Java code in question, where I think this data loss might be happening, is serialEvent() at line 174 in arduino-core/src/processing/app/Serial.java.

https://github.com/arduino/Arduino/blob/master/arduino-core/src/processing/app/Serial.java#L174

At line 177, data is obtained from JSSC as an array of 8 bit bytes. It seems the bytes are copied to a byte buffer, though I'm not sure what the "ByteBuffer" object really does. At line 186, the data gets converted from bytes to chars. I believe Java is using 16 bits for char, but again I'm not 100% sure on that. My guess is there many be some sort of bug at this point. Really, what we want to know is whether that byte array really is receiving the missing messages.

Maybe the next step, if fiddling with language settings is fruitless, might involve me compiling some copies of arduino-core.jar with verbose debug info printed from that function. On a Mac, you'd need to dig into the app bundle (control-click on Arduino and "Show Package Contents") and replace the jar file. This might also cause Mac Gatekeeper to get upset, so you may have to control-click to run Arduino, or somehow disable Gatekeeper (Apple has made this harder to do recently).
 
From what I allow to deduce that it's neither an Arduino IDE, nor a Teensyduino, nor a Teensy loader issue. Which means that the OSX / macOS installation might be corrupted by whatever not correctly functioning kext module which under several conditions might interfere with the serial communication.

Any chance to reboot your Mac in safe mode with only the strict minimum of drivers and background tasks loaded?

I will try this on weekend ( need to organize Keyboard with cable :))....
 
Ok, here's a new theory. Maybe the data loss is somehow happening inside Arduino when the raw incoming data is getting translated to unicode?

I'm not sure how to test this theory (well, "guess" would be a better word). Maybe try using the "defaults" command which was the workaround for the High Sierra non-US menu bug before Arduino 1.8.5.

https://blog.arduino.cc/2017/10/02/arduino-ide-1-8-5-hotfix-for-macos-high-sierra-users/

For a copy of Arduino that has Teensyduino installed, you'll probably need to use this command:

Code:
defaults write cc.arduino.Arduino.teensyduino AppleLanguages '(en)'

But I must admit, how Java really handles the language settings isn't something I really know. It could be other settings that influence how bytes are turned into unicode chars.

The Java code in question, where I think this data loss might be happening, is serialEvent() at line 174 in arduino-core/src/processing/app/Serial.java.

https://github.com/arduino/Arduino/blob/master/arduino-core/src/processing/app/Serial.java#L174

At line 177, data is obtained from JSSC as an array of 8 bit bytes. It seems the bytes are copied to a byte buffer, though I'm not sure what the "ByteBuffer" object really does. At line 186, the data gets converted from bytes to chars. I believe Java is using 16 bits for char, but again I'm not 100% sure on that. My guess is there many be some sort of bug at this point. Really, what we want to know is whether that byte array really is receiving the missing messages.

Maybe the next step, if fiddling with language settings is fruitless, might involve me compiling some copies of arduino-core.jar with verbose debug info printed from that function. On a Mac, you'd need to dig into the app bundle (control-click on Arduino and "Show Package Contents") and replace the jar file. This might also cause Mac Gatekeeper to get upset, so you may have to control-click to run Arduino, or somehow disable Gatekeeper (Apple has made this harder to do recently).

Hey Paul, do you sometimes sleep too? :)

Code:
defaults write cc.arduino.Arduino.teensyduino AppleLanguages '(en)'
I will try this tomorrow or later this day... it is 2am here in Switzerland...
English system language had no positive effect. I had already tested that.

Gatekeeper should not be a problem.
In any case many thanks for your efforts!!!
 
Hey Paul, do you sometimes sleep too? :)

Code:
defaults write cc.arduino.Arduino.teensyduino AppleLanguages '(en)'
I will try this tomorrow or later this day... it is 2am here in Switzerland...
English system language had no positive effect. I had already tested that.

Gatekeeper should not be a problem.
In any case many thanks for your efforts!!!


Language doesn't fix the problem....
 
Ok then, let's try digging deeper to see where the problem is really happening.

Here's a copy of arduino-core.jar which prints the number of bytes it's actually getting for each serial event.

https://www.pjrc.com/teensy/beta/arduino-core.jar

MD5 = 32c3ae4c34c320b0d16f2ba16738568d

Here's how it looks when I run it.

sc.jpg

To use this, download the JAR file. I recommend running "md5 arduino-core.jar" in a Terminal window, to make sure you have the right file.

Quit Arduino, if it's running. Control-click Arduino and click "Show Package Contents". Then navigate to Contexts/Java. Replace the copy of arduino-core.jar with this one.

When you run Arduino again and open the serial monitor, you should see the messages printing in the console panel. The big question is whether Arduino on your Mac really is receiving all the incoming bytes and somehow losing them internally, or perhaps they're not ever coming into the serial event handler. This test should let us know.
 
From what I allow to deduce that it's neither an Arduino IDE, nor a Teensyduino, nor a Teensy loader issue. Which means that the OSX / macOS installation might be corrupted by whatever not correctly functioning kext module which under several conditions might interfere with the serial communication.

Any chance to reboot your Mac in safe mode with only the strict minimum of drivers and background tasks loaded?


Still working on rebooting in safe mode... I removed Firmware protection and now decrypting my Harddrive (FileVault).
Didnt know that this has do be done before rebooting in safemode is possible.
Have to wait until decryption is completed.
 
Status
Not open for further replies.
Back
Top