Skip to content
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

Bugfix for garbage data coming from serial port after reset. (Arduino Due) #1267

Merged
merged 2 commits into from Feb 26, 2013

Conversation

cmaglie
Copy link
Member

@cmaglie cmaglie commented Feb 5, 2013

After reset garbage may show up from Serial port due to a firmware bug on the atmega16u2.

Here the relevant forum topic:
http://arduino.cc/forum/index.php/topic,134847

Here the updated .hex for the 16u2:
https://github.com/arduino/Arduino/blob/976f7588b7f68bd3c5fce52c15ccfe738589085a/hardware/arduino/sam/firmwares/atmega16u2/Arduino-DUE-usbserial-prod-firmware-2013-02-05.hex

Please check if the updated firmware fix the issues and report back here.
Thanks.
C

@ghost
Copy link

ghost commented Feb 12, 2013

atmega16u2 is not known with latest macports package http://www.macports.org/install.php#pkg version 0.5.4 even if using latest Xcode 4.6 running with Mac OS Lion.

Maybe it is works on PC or Linux but right now, if really the DUE has the atmega16u2, can't erase it neither flash new firmware on the USB chip from a Macintosh.

Please communicate another erase and flash DFU programmer running on Macintosh.

@PeterVH
Copy link

PeterVH commented Feb 19, 2013

I tested the firmware with Albert's test program. I run linux 3.0.0. The test program seems indeed to work (per the description in the aforementioned thread) with the 2013-02-05 and not with the 2012-11-05 firmware.

If I slide any other then the two leftmost bars, the crc error led briefly lights up. But I guess that is normal, because I see the same behavior if I modify the sketch to use the native usb port. Albert, can you confirm this is normal? Can you also post the java code for the gui?

Speaking of which, on the native port (ide 1.5.2), after some time the crc err lights up. I will test with Stimmer's version that reportedly works correctly with this test.

@cmaglie: the fix seems to just reset the Due a little bit longer. Can you explain why this fixes this problem or the problem of garbage sent after reset?

@ghost
Copy link

ghost commented Feb 20, 2013

Hello PeterVH,

Thanks to have made these tests. I'm still waiting for ISP mega-due shield spec from arduino team so I could actually upload the new firmware.

I've created very lately a github account, made a fork from Alvaro initial SerPro and hopefully, will publish soon the IDE along with java sources, just need to verify some legal issues on java part since it is using USB libraries.

Wether you've my java sources or not, I can comment your results.

If you do not slide any GUI's sliders (two sliders on left of timer's check box or multiple sliders on right of timer's checkbox), the crc-LED should never light neither the Link-LED should never light. Only when you slide them, briefly the crc-LED or LinkUp-LED will briefly light per your your hand movement.

About stimmer test 1, namely to hold reset then stop, it does work on my side with old firmware but i do not consider fully working because the LinkUp-LED and CRC-LED do stay faintly light up even though i admit the java GUI correctly received some internal parameters from arduino (Full H-brdige PWM frequency, duty cycle, boost-buck parameters,...). This specific lighting is really faint, you need to look in front of LED's but again, they should NOT light up at all if no GUI sliders action.

As for using native USB after a while light-up crc-LED, this is not normal. Please remember that if you do NOT use any sliders, the crc-LED is a real 16-bit CRC inspecting any frame errors included in the HDLC protocol supporting the serial-deserail SerPro protocol. If it lights up then USB still has a problem for sure !

@cmaglie
Copy link
Member Author

cmaglie commented Feb 20, 2013

@PeterVH
The old fimware asserts reset when ResetTimer is between 25 and 1. When DTR was detected the variable ResetTimer was set to 30 that leads to a little time with no reset (30 to 25) and a reset (25 to 1). This was not a problem if the DTS signal is set once, but for some strange reason the RXTX library toggles DTR many times during port setup. This has the side effect to assert reset many times due to the small time with no reset (30 to 25).

So the issue was not on the length of the reset, but on the fact that the reset sequence started from 30 and not 25.

I don't know if my explanation is clear, the issue was really tricky to solve...

@selfonlypath
The tutorial to reburn the 16u2 is almost ready!

C

@hektoven
Copy link

Hello Everybody,

do anaone know if the same problem with garage data or old data on serial bus could happen on arduino mega too?

I still get old data in my serial bus from arduino after a few readlines the new datra arrives. Flush of inputbffer and outputbuffer on host side did not solve the problem....

best Kai

@Fede85
Copy link
Contributor

Fede85 commented Feb 20, 2013

Hello, this is the tutorial for uploading the firmware on the 16U2 using an Arduino Uno/Mega as AVR-ISP programmer: http://arduino.cc/en/Hacking/Upgrading16U2Due

kind
F

@ghost
Copy link

ghost commented Feb 21, 2013

@hektoven
I happen to own and use mega 1280, mega 2560 rev 2, mega 2560 rev and due, all bought directly to arduino company so no 2nd source manufacturing with possible components issue.

Personally, I tend to suggest using my ElectroShaman SerPro GUI in RX/TX mode with any arduino because it covers so many cases of USB protocol since based on HDLC and so.

As of today, it works fine with all the arduino mega's revision wether 1280 or 2560 so I would rule out any USB garbage issue. I do notice much less efficiency with mega 1280 and sometimes freezing which do not occur with mega 2560's.

@Fede85
Thanks a lot for the tutorial, i'll make the firmware update soon and will let's know if it pass or fail ElectroShaman SerPro heavy duty testing.

Albert

@reppr
Copy link

reppr commented Feb 23, 2013

Thanks for the docu.

Typo in "The Arduino Due will took power from the Arduino Uno ...":
s/took/take/

@ghost
Copy link

ghost commented Feb 23, 2013

I'm starting to apply the firmware update between my mega and my due but noticed that http://arduino.cc/en/Hacking/Upgrading16U2Due requires pin 10 as SS to connect Due's ICSP.
Please confirm this pin allocation because I would taken instead pin 53 on mega ?
Thanks, Albert

@ghost
Copy link

ghost commented Feb 23, 2013

Another thing about locating avrdude then launch it from Terminal shell, I'm using a Macintosh where I only see arduino.app
Please be more specific, how can I find the avrdude because I can't get inside the arduino.app packet via Terminal shell

@ghost
Copy link

ghost commented Feb 23, 2013

OK I've found the trick to call from Terminal Shell avrdude from a Mac
/folder-hosting-arduino/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude

About mega SS-SPI signal, I really think the tutorial should mention pin 53 where for UNO, it is indeed pin 10

Will let you know the result of flashing the firmware

@ghost
Copy link

ghost commented Feb 23, 2013

aie aie aie... Something must have gone wrong, my Due's USB is not recognized or seen anymore by Arduino IDE :(

Here is what I did from a Terminal Shell where before launching that command, I did load arduinoISP sketch into my mega 1280 then connected the 6 wires per the tutorial...

new-host-3:desktop selfonlypath$ /Developer/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude -C/Developer/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -c arduino -P /dev/tty.usbserial-A6008igj -b 19200 -p m16u2 -Uflash:w:16u2.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9489
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "16u2.hex"
avrdude: writing flash (4314 bytes):

Writing | ################################################## | 100% 5.27s

avrdude: 4314 bytes of flash written
avrdude: verifying flash memory against 16u2.hex:
avrdude: load data flash data from input file 16u2.hex:
avrdude: input file 16u2.hex contains 4314 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 3.21s

avrdude: verifying ...
avrdude: 4314 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.

new-host-3:desktop selfonlypath$

@PeterVH
Copy link

PeterVH commented Feb 23, 2013

It looks like it worked ok though.
Did you remove the wires? You should either remove the wires or also power the mega. Personally I power both the mega and the due via usb and leave away the connection between the 5V of both boards.

@ghost
Copy link

ghost commented Feb 23, 2013

Well glad to have confirmation the new firmware has been flashed correctly but hey guys, you need to help me because for whatever reason, my arduino DUE cannot download anything from the IDE !

About powering modes, i'm a bit new to these ISP stuff so just did per the arduino tutorial, namely connect both 5V and GND from my mega to the due, the mega receiving power from my Mac via USB.

Please note that I've not saved the previous firmware, in fact I would have not known how to do it so now I'm really stuck :(

@PeterVH
Copy link

PeterVH commented Feb 23, 2013

...so just did per the arduino tutorial, namely connect both 5V and GND from my mega to the due
That is ok. But I meant, afterwards, when you tried to upload sketches to the due, did you remove the connections to the mega? (sorry if this questions sounds obvious). If not, the atmega16u2 mght be kept in reset by the connections to the mega.

...Please note that I've not saved the previous firmware.
No problem. It is in your arduino-1.5.2 directory, here: hardware/arduino/sam/firmwares/atmega16u2/Arduino-DUE-usbserial.hex.

@ghost
Copy link

ghost commented Feb 23, 2013

Frankly i don't remember what I did withe wires after the avrdude flashing was done.

Maybe i can try again to flash the new firmware and you teach me precisely what wires disconnection, powering down has to be done, IDE disconnected... Maybe more details of the global procedure described in the tutorial.

P.S. Good to here I can recover the previous firmware but I guess in all cases, one has to teach me exactly all the steps to properly de-power, disconnect wires...

Thank you in advance

@PeterVH
Copy link

PeterVH commented Feb 23, 2013

Remove all 6 isp wires from the due (and remove everything else connected to the due).
Hook up the due to your pc via the usb programming port.
Can you upload sketches, now?

@ghost
Copy link

ghost commented Feb 23, 2013

When should I remove the USB generating power to mega then routing 5V and GND to due ?
What is still not clear to me, the wires removal and USB-power removal of mega and due to prevent any USB hang up

@PeterVH
Copy link

PeterVH commented Feb 23, 2013

The firmware upload succeeded. I think the due will work if you connect it to your pc with nothing else attached to it. I want to be sure about that before doing further trouble shooting.

@ghost
Copy link

ghost commented Feb 24, 2013

Please find my new attempt with details on each step, maybe i'm doing something wrong

Building the 6 wires between Due and mega...
ONLY powering mega via USB of my MacBook Air
Download ArduinoISP sketch using IDE 1.51. into mega NOT being connected to DUE
Quit IDE where mega still USB powered from MacBook Air
Disconnect USB so NO power on mega
Connect 6 wires between DUE and MEGA
Reconnect MacBook Air's USB to mega so now both mega has power and DUE receives power FROM mega
Open Terminal shell then launch avrdude to flash new firmware

new-host-3:desktop selfonlypath$ /Developer/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude -C/Developer/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -c arduino -P /dev/tty.usbserial-A6008igj -b 19200 -p m16u2 -Uflash:w:new-16u2.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9489
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "new-16u2.hex"
avrdude: writing flash (4314 bytes):

Writing | ################################################## | 100% 5.28s

avrdude: 4314 bytes of flash written
avrdude: verifying flash memory against new-16u2.hex:
avrdude: load data flash data from input file new-16u2.hex:
avrdude: input file new-16u2.hex contains 4314 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 3.22s

avrdude: verifying ...
avrdude: 4314 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.

new-host-3:desktop selfonlypath$

Disconnect USB from MacBook Air so mega does not receive power implying DUE does not receive power from mega
Disconnect 6 wires between mega and DUE
Connect directly DUE to MacBook Air USB
Launch IDE 1.5.1
Arduino DUE is correctly powered but its serial USB is NOT shown on IDE so I cannot download anything

@ghost
Copy link

ghost commented Feb 24, 2013

OK here is the situation, i've recovered the OLD firmware per PeterVH instructions then applied same step by step above instructions and USB works from IDE again... See below firmware log so I think the new firmware has a BUG or something preventing USB to work

new-host-3:desktop selfonlypath$ /Developer/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude -C/Developer/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -c arduino -P /dev/tty.usbserial-A6008igj -b 19200 -p m16u2 -Uflash:w:old-16u2.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9489
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "old-16u2.hex"
avrdude: writing flash (4352 bytes):

Writing | ################################################## | 100% 5.30s

avrdude: 4352 bytes of flash written
avrdude: verifying flash memory against old-16u2.hex:
avrdude: load data flash data from input file old-16u2.hex:
avrdude: input file old-16u2.hex contains 4352 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 3.23s

avrdude: verifying ...
avrdude: 4352 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.

new-host-3:desktop selfonlypath$

@ghost
Copy link

ghost commented Feb 24, 2013

OK finally great news, i've found why it did not work with new firmware and did work with old firmware.

It seems an issue with Apple's Textedit so I've noticed different encoding on old firmware as published by arduino team and how I constructed the new firmware, namely it made a RTF instead of Occidental (Mac OS Roman). So I took old-firmware.hex then copy pasted inside the new firmware, of course downloading firmware from Terminal shell did work, it does not care the encoding.

Now i've downloaded my ElectroShaman simplified IDE and simplified java GUI, the USB-SerPro link establishes correctly except a few details: RX and CRCerror LED's are BOTH faintly lighting

This seems to not affect the proper LED's response to GUI's sliders change but I suspect still an USB garbage issue because obviously, I've no problem of 5V or 3.3V or drivers feeding 1K resistor in serie with LED under sink mode.

Many thanks for your help and let me know if ElectroShaman can help confirm or infirm some remaining USB issues even though thanks to the new firmware, things work much better in my private lab using DUE. So I let you guys decide if the ElectroShaman and SerPro using HDLC and serializer-Deserializer higher protocol are reliable. I would conclude some USB data garbage still manifest once in a while because CRCerror computes a 16-bit error detection so some frames are corrupted then re-send and finally get through.

Albert

@PeterVH
Copy link

PeterVH commented Feb 24, 2013

Funny, if I add a a blank line anywhere in the hex file e.g at 10% or at 70% of the file, I get the same flash size reported by avrdude as in your first posts: "4314 bytes of flash verified".
Well, you're up and running again, that is what counts.

@PeterVH
Copy link

PeterVH commented Feb 24, 2013

...USB-SerPro link establishes correctly except a few details: RX and CRCerror LED's are BOTH faintly lighting
I see another behavior;
When sliding the two leftmost sliders: linkup led + rx + tx leds light up.
When slidng any other slider: crc error led + rx +tx leds light up.

In the latter case, I can't believe these are real crc errors (it happens every time). I'll have a look in the sketch.

let me know if ElectroShaman can help confirm or infirm some remaining USB issues
I think a minimalist serpro sample (say with 1 slider) app that sends and receives some data and lights a led on crc errors is indeed a good tool to test serial communications.

@ghost
Copy link

ghost commented Feb 25, 2013

@PeterVH Let me clarify, there was clearly a firmware issue with so much USB data garbage that SerPro would never establish RX-TX link between ElectroShaman GUI and arduino. That part is now solved thanks to the new firmware provided by Cristian.

When you slide leftmost sliders or any other sliders on right, my IDE is setup in a way to reflect these actions with either LinkUp led or CRCerr led. This works fine now where of course, it is normal or functional to have faint lighting of Rx led and Tx led. These Rx and Tx just visualize some date communication, namely sliders value being transferred.

Now I can assure you that if you do NOT move any sliders then, the RX and TX led should stay OFF, that is the case if you port SerPro with arduino UNO, arduino MEGA and partially true on arduino DUE. With DUE, the RX and CRC led are faintly ON so this is result of small garbage USB data !!!

If you happen to have an arduino MEGA, please try my sketch and see by yourself !

Maybe there is another explanation because I've just used my tektronix tek2445 (4 channels at 150 MHz) to actually probe all the led's activity while sliding, not sliding GUI. It is true their voltage reflects what the SerPro protocol sees, namely even if CRCerr and RX led are faintly lighting ON, their respective arduino pin's acting as a sink indicates NO activity. Not sure about arduino pin's driver max mA or technology compared to arduino mega, maybe there is specific driver affecting pins 28 and 32 but not affecting pins 24 and 36 !

It would be interesting to understand why these 2 led's among the 4 are not correctly working or displaying the SerPro communication status, USB data garbage or just pin's output driver electronic effect !

@ghost
Copy link

ghost commented Feb 25, 2013

P.S. Just checked the DUE's pin document of Graynomad, obviously all pins 24-28-32-36 outputs can manage same sinking current (my led's are wired to +5V via 1K pullup resistor). I can't prove it, need to find special T&M method but we cannot prove or disprove some residual USB data garbage since the RX and CRC led's should not even faintly light ON when we do not move any GUI slider !

@ghost
Copy link

ghost commented Feb 25, 2013

P.S.2. Strange because when using my SEFRAM 4410 frequency generator in counter mode, if sliders are moving then I see glitching frequency when probing each LEDs which is correct but if no slider movement, no frequency so it tends to confirm what my tek 2445 scope already showed, namely arduino DUE not sinking any current to CRCerr and RX led's... Really wierd why they faintly light ON whereas they do not if loading same sketch in MEGA !!!

@PeterVH
Copy link

PeterVH commented Feb 25, 2013

Now I can assure you that if you do NOT move any sliders then, the RX and TX led should stay OFF
They stay off on my due.

my led's are wired to +5V via 1K pullup resistor
You should pull them up to 3V3.
The due tries to shut off the led by driving the kathode to 3V3, if you pull up the anode to 5V, current will flow.

@ghost
Copy link

ghost commented Feb 25, 2013

BRILLIANT analysis so my scope or freq counter were correct, NO more USB data garbage with this new firmware... Case closed I guess, many thanks ;)

cmaglie added a commit that referenced this pull request Feb 26, 2013
… Due)

Fixed #1267

Merge branch 'fix-usbserial-firmware-due' into ide-1.5.x
@cmaglie cmaglie merged commit 1e1fce8 into ide-1.5.x Feb 26, 2013
@cmaglie cmaglie deleted the fix-usbserial-firmware-due branch February 26, 2013 16:38
@PeterVH
Copy link

PeterVH commented Feb 26, 2013

@cmaglie : yes the explanation is clear, thanks. I did not spot the 25/30 difference myself.
@hektoven : I have no mega but I am sure you can have that with a mega too. It has the same usb2serial converter, just with a firmware that is a bit different.
I did some effort to modify the firmware (for the due) such that it discards data from the previous session. It did not work, it is difficult to distinguish which data to throw away and which one to send out. I let it go, I think it does not make not a lot of sense. Actually in many situations I think it is better if you open the serial port to not reset the mcu and just read in what the mcu sends...
@Fede85 wouldn't it be better to start advocating the wiring using the isp header of the programming arduino? It works on the leonardo too. See here

@ghost
Copy link

ghost commented Mar 2, 2013

As a reminder since i've been using arduino MEGA, the SS-SPI pin is 53 and not 10 as found in arduino UNO

@ghost
Copy link

ghost commented Aug 13, 2013

@PeterVH : hello please find a new release of the sketch and javas as requested 6 months ago where now the java GUI offers much more sliders, checkboxes as well as LOG console directly communicating with arduino MEGA or DUE being the client

http://www.tantratron.tk/Arduino-Java-SerPro/GUI_MEGA_DUE_v2.05.zip

ElectroShaman v2.0.5

A communication tool between a host (Windows/Mac/Linux) and Arduino (as client),
to have life update of operational parameters from host to control Arduino behaviour.
ElectroShaman is primary focused on updating pin status, PWM configurations, digital potentiometers, ...
ElectroShaman consists of 2 parts:
- GUI on the host (written in Java)
- interface embedded within Arduino sketch

Copyright (C) 2010-2013
    Dan Combine (protocol & GUI enhancements)
    Selfonlypath (ElectroShaman foundations)
    Alvaro Lopes (SerPro protocol)
www.tantratron.tk

for Windows/Mac/Linux
Open Source software

runs on Arduino MEGA and Arduino DUE
is used to control ZPE boards
requires ElectroShaman v2.0.5 on Win/MAC to manage operational parameters

@soundanalogous
Copy link

This issue does not appear to be resolved. After updating the ATMega16U2 firmware I'm still seeing garbage on the input line whenever an initial serial connection is made from an external application.

Try this sketch on a Due:

void setup() {
  Serial.begin(57600);
  Serial.println("begin");
}

void loop() {
  if (Serial.available() > 0) {
    // Due will print a garbage character before "begin" upon
    // serial connection from serial monitor or external application
    // such as screen (OS X). Once the external application is open
    // resetting the Due will not print garbage. It only happens upon
    // the initial serial connection from an external app.
    // This issue appears to be specific to Due.
    Serial.print(Serial.read());
  }
}

You'll see a garbage character each time you open the Serial Monitor application or each time you create a new connection from Screen (OS X) or any external application making a serial connection with the Due.

I'm not seeing this issue on an Uno, Mega or Leonardo. It seems to be Due specific.

The problem here is that the first transmission from an external application will be corrupt unless the serial input is flushed. In Firmata I had to add the following line to the end of the Firmata.begin method:

void FirmataClass::begin(long speed)
{
  Serial.begin(speed);
  FirmataSerial = &Serial;
  blinkVersion();
  printVersion();
  printFirmwareVersion();
  // clear any garbage in the input stream (this fixes an issue with Due)
  while (FirmataSerial->read() != -1);
}

The line cannot be flushed immediately after Serial.begin is called. Here blinkVersion creates a sufficient delay. If blinkVersion is not called, then a delay of at least 800ms must occur after Serial.begin before the serial input can be flushed.

@dinvlad
Copy link

dinvlad commented Mar 25, 2016

I'm seeing this issue on 2 separate Mega's 2560 R3. More specifically, using

void setup() {
  Serial.begin(115200);
  delay(300);
  randomSeed(analogRead(0));
  Serial.print(F("Test output "));
  Serial.println(random(255));
}

If I remove the delay, after each upload it would show "Test output XX" from a previous connection:

Test otput 34
ðTest output 199

and more importantly, these numbers are generally different from those of the previous upload. If I set the baud rate in setup() to be different from what I use for the upload (e.g. 57600 vs 115200), "first output" still appears but in a completely garbled form:

`f†æø�~˜f�~f~`��x��˜�˜€Test output 59

suggesting that this trash output is a relic from the serial connection used for the upload. Could it be somehow discarded before the real desirable output? Of course, I could always discard anything that comes out of the board before sending the first command to it, but I was also hoping to log some initialization messages and use Serial 1..3 for communicating with third-party devices that may not react well to such output (provided it's not just 16U2). I also updated the firmware using Flip utility and https://raw.githubusercontent.com/arduino/Arduino/master/hardware/arduino/avr/firmwares/atmegaxxu2/arduino-usbserial/Arduino-usbserial-atmega16u2-Mega2560-Rev3.hex

@dinvlad
Copy link

dinvlad commented Mar 26, 2016

It looks like other ports are having the same issue:

HardwareSerial* serial[] = {&Serial, &Serial1, &Serial2, &Serial3};

void setup() {
  randomSeed(analogRead(0));
  long c = random(255);

  for (int i = 0; i <= 3; i++) {
    serial[i]->begin(115200);
    serial[i]->print(F("Test output port "));
    serial[i]->print(i);
    serial[i]->print(F(": "));
    serial[i]->println(c);
  }
}

Output from Serial0 (connected via USB to PC) after upload:

Test output port 0: 241
ðTest output port 0: 59

Output from Serial1 (connected via MAX235 and a third-party USB adapter to PC):

Test output port 1: 241                       
Test output port 1: 59

Does that imply that 16U2 is not responsible for such behavior? If I understand correctly, it only serves to translate TX0/RX0 to USB and programming Arduino. It looks like Arduino goes through 2 'soft resets'(?), and the contents of the Serial buffers is not cleared between them. Could that be an issue within HardwareSerial?

ollie1400 pushed a commit to ollie1400/Arduino that referenced this pull request May 2, 2022
… Due)

Fixed arduino#1267

Merge branch 'fix-usbserial-firmware-due' into ide-1.5.x
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants