-
-
Notifications
You must be signed in to change notification settings - Fork 390
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Serial Monitor sends spurious data #375
Comments
I faced similar problem with Arduino Due on Arduino IDE 2.0. |
Still seems to be an issue. Using Arduino UNO on COM3, the serial monitor sends out two bytes of 0xF0 (hex value of each byte) every second. |
Still a problem. |
Maybe switching to new API (#769) will help? Or at least should be done first, so testing and troubleshooting is done with new pluggable serial monitor? |
Some additional information that might help; with the given sketch
|
I faced a similar problem with Arduino Due at 9600 baud. The same code works fine on 1.8 |
Still an issue with RC9.3 |
Hello, I am currently having this issue with an Arduino Uno R3. It looks like the IDE is sending redundant changes in configuration data every second, and even more when you select the pulldowns on the serial monitor. (Not sure exactly what, but it could be like setting the baud rate, stop bits, etc.) For some boards, this has no ill effects. But for the ones with an ATMEGA16U2 at least, this can cause the firmware to momentarily reset the UART, putting spurious pulse out on the Serial receive to the 328P, in my case. I can clearly see the pulses on an oscilloscope. Note, the RXD light driven by the ATMEGA16U2 is not flashing - it's not "received data" being sent, it's something else causing spurious pulses. This is why they oddly seem to show up as mostly 0xf0 at 115200 baud - It's just the luck of the timing. Strangely, the only time it seems to stop is when you select 57600, which I can see is a special case in the ATMEGA16U2 firmware. Anyway, my Javascript is rusty but I think this could be fixed by finding and eliminating the redundant config information being sent by the Serial Monitor. Alternatively, I bet you could also update the ATMEGA16U2 firmware to check the incoming state changes to see if they are needed, and not reset the UART unless required. I want to learn how to build the new IDE, and then I can try to work on this some more. I'd also be happy to test any updates you may be evaluating. |
By the way, the pulses seem to come in pairs. Both of which usually, but not always, decode as an 0xf0 at 115200 baud. It may be the UART being turned off, and then turned back on? My guess is that this code is being triggered on the ATMEGA16U2: |
This is entirely a problem associated with the IDEv2 implementation of the Serial Monitor. Version 1 IDE - all is fine. I even built my own implementation of a Serial Monitor in C#/Windows Forms and had none of the issues we are seeing here. No issue when using putty either. |
Well, I've made some more progress. The Arduino-IDE program uses a component named arduino-cli.exe, which in turn uses another component named serial-monitor.exe to talk to the ATMEGA16U2 on the Arduino Uno. I have run serial-monitor.exe by itself, and after it executes the OPEN command, the 1Hz glitch pairs start appearing on the Uno's RXD line. There does not appear to be any command being executed every second, however. I am going to dig into the firmware on the ATMEGA16U2 next, and try to figure out what is really going on there. The IDE isn't completely off the hook, because it is still sending too much data to the board, especially when using the Line Endings pulldown - which shouldn't even affect the serial port. But the root cause of the periodic corruption has been narrowed down to an interaction between serial-monitor.exe and the ATMEGA16U2 firmware. |
Remove unnecessary code, originally for checking for disconnects when using non-overlapped I/O. getOverlappedEvent() returns all required error codes. Calling getCommState()/setCommState() every second in some applications contributes to other downstream issues. For examples: bugst#60 (comment) arduino/arduino-ide#375
|
Well done Frank Palazzolo. A solution in sight. |
Closes #375 Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Closes #375 Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
The old code is no more needed when using overlapped I/O, getOverlappedEvent() returns all required error codes. Calling getCommState()/setCommState() every second in some applications contributes to other downstream issues. For examples: bugst#60 (comment) arduino/arduino-ide#375
Closes #375 Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Closes #375 Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Closes #375 Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Closes #375 Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Closes #375 Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
I am reopening as the #1703 only partially fixes the issue: #1703 (review) Per, please close it if you think this is resolved. Thank you! |
Fixed by bugst/go-serial#147 + arduino/serial-monitor#31. These fixes are in the serial-monitor 0.11.0 release, which will be automatically installed the next time the user starts Arduino IDE 2.x. |
Describe the bug
🐛 Spurious data is sent by the Serial Monitor over the connected serial port.
To Reproduce
Equipment
Steps
🐛 The Serial Monitor's output field shows unexpected data is being received by the Arduino board and echoed back by the sketch. Something like this:
... and so on
Expected behavior
Data is only sent over the serial port by Serial Monitor when the user sends it via the input field.
Desktop
Date: 2021-05-15T03:10:15.375Z
CLI Version: 0.18.2 alpha [7b5a22a4]
Additional context
I have only been able to reproduce this on my Arduino Mega, Arduino Uno, and Arduino Due (via Programming Port only). Based on the commonality of their ATmega16U2 USB chip, I expected to also be able to reproduce it on my Arduino Uno Mini LE, but I was not able to.
On my Leonardo and Micro boards, the RX LED flashes at 1 Hz while the Serial Monitor is connected, indicating unexpected data is being received, but I don't get any output from the echo sketch.
I notice that the ~1 Hz frequency of the spurious data appears to match the frequency of the notification displayed repeatedly after the board is disconnected while Serial Monitor is open (#314):
This makes me wonder if already open ports are constantly being reopened at 1 Hz the whole time Serial Monitor is running. Further evidence supporting this is that I get the RX blink on the Leonardo whenever I do a manual
StreamingOpen
gRPC request to the port.It appears the data is sent at 115200 baud.
As reported at at #1297, changing the selection in the line ending menu triggers the immediate sending of additional spurious data in addition to the regular periodic data reported above.
I notice the same happens when you toggle the "Toggle Autoscroll" or "Toggle Timestamp" icons.
None of these should result in any data being sent to the board.
Originally reported at: https://forum.arduino.cc/t/serial-monitor-sends-random-f0/850819
The text was updated successfully, but these errors were encountered: