Garbage using serial functions in Arduino Due

Does this happen at 9600? Does "while (!Serial)" do anything?

In my case, it happens at 112500 bauds. I could change easily my software which consist to make dialog a Java GUI on MacBook Air with my Mega or my Due but i don't feel loosing anymore time on this since it is obvious in this thread or other recent related threads the Serial.libs function in 1.5 IDE are the root cause of this issue... Sorry !

It happens at 9600.

"while (!Serial)" does nothing since the Due library always return true:

    operator bool() { return true; }; // UART always active

I spent many hours because of this bug. Many of my test examples for SdFat have somthing like this:

  Serial.println("Type any character to start");
  while (!Serial.available());

Examples that write to the SD were getting a corrupt file system. This happens because opening the serial monitor causes some junk input. The program then executes for about 30 ms before a reset happens. This is just enough time to have the reset happen during a critical sequence of writes to the SD.

I thought I had a bug in the new Due version of SdFat that caused the problem.

P.S. Another thing that I've noticed, maybe i'm not doing something right with IDE but i've noticed two differences between same code compile/load on MEGA versus on DUE:

  • both compilation times seem similar

  • downloading into DUE takes more than 10 or 20 times than downloading into MEGA

Do you think this could be related to the same issue we're discussing here ?

The only connection between download time and this problem is the ATmega16U2. It handles the download and the USB/serial communication to the serial monitor.

I tried adding some error checking to the UART driver. I rejected characters with framing or overrun errors but it didn't help my problem. I still get at least one junk character when I bring up the serial monitor.

I think I have a work around for what I need. This seems to prevent the problem of my examples executing on junk input:

void setup() {
  Serial.begin(9600);
  while (!Serial) {}  // wait for Leonardo
  Serial.println("Type any character to start");
  while (Serial.read() <= 0) {}
  delay(200);  // Catch Due reset problem
  // assume the user typed a valid character and no reset happened 
}

It seems a bug in the firmware of the 16u2 that does USB-2-serial conversion.

Can you check if the updated firmware above solves the issues?

What method is the best way to load that hex file? I have the program called Flip but, I am not sure if I am using it correctly because, it does seem to want to connect to the 16u2.

cyclegadget:
What method is the best way to load that hex file? I have the program called Flip but, I am not sure if I am using it correctly because, it does seem to want to connect to the 16u2.

I used an ISP (well, actually the ArduinoISP sketch running on a Mega). I don't think the Due has a DFU firmware.

The firmware is better but I still get occasional odd results. For example, after uploading (fixed) AnalogReadSerial then uploading ASCIITable then opening the serial monitor, I get this:

453
457
454
451
26, oct: 46, bin: 100110
', dec: 39, hex 24, oct: 44, bin: 100100
%, dec: 37, hex: 25, oct: 45, bin: 100101
&, dec: 38, hex: 26, oct: 46, bin: 100110
', dec: 39, hex: 27, oct:44, bin: 100100
%, dec: 37, hex: 25, oct: 45, bin: 100101
&, dec: 38, hex: 26, oct: 46, bin: 100110
', dec: 39, hex: 27, oct:ASCII Table ~ Character Map
!, dec: 33, hex: 21, oct: 41, bin: 100001
", dec: 34, hex: 22, oct: 42, bin: 100010
#, dec: 35, hex: 23, oct: 43, bin: 100011
$, dec: 36, hex: 24, oct: 44, bin: 100100
%, dec: 37, hex: 25, oct: 45, bin: 100101
&, dec: 38, hex: 26, oct: 46, bin: 100110
', dec: 39, hex: 27, oct: 47, bin: 100111
(, dec: 40, hex: 28, oct: 50, bin: 101000
), dec: 41, hex: 29, oct: 51, bin: 101001
*, dec: 42, hex: 2A, oct: 52, bin: 101010
+, dec: 43, hex: 2B, oct: 53, bin: 101011
,, dec: 44, hex: 2C, oct: 54, bin: 101100
-, dec: 45, hex: 2D, oct: 55, bin: 101101
., dec: 46, hex: 2E, oct: 56, bin: 101110
/, dec: 47, hex: 2F, oct: 57, bin: 101111
0, dec: 48, hex: 30, oct: 60, bin: 110000
1, dec: 49, hex: 31, oct: 61, bin: 110001
2, dec: 50, hex: 32, oct: 62, bin: 110010
3, dec: 51, hex: 33, oct: 63, bin: 110011
4, dec: 52, hex: 34, oct: 64, bin: 110100
5, dec: 53, hex: 35, oct: 65, bin: 110101
6, dec: 54, hex: 36, oct: 66, bin: 110110
7, dec: 55, hex: 37, oct: 67, bin: 110111
8, dec: 56, hex: 38, oct: 70, bin: 111000
9, dec: 57, hex: 39, oct: 71, bin: 111001
:, dec: 58, hex: 3A, oct: 72, bin: 111010
;, dec: 59, hex: 3B, oct: 73, bin: 111011
<, dec: 60, hex: 3C, oct: 74, bin: 111100
=, dec: 61, hex: 3D, oct: 75, bin: 111101
>, dec: 62, hex: 3E, oct: 76, bin: 111110
?, dec: 63, hex: 3F, oct: 77, bin: 111111
etc.

I guess the first few lines are remnants of what is stuck in the OS serial input buffer from AnalogReadSerial, but I'm not sure what's going on before ASCIITable starts properly.

stimmer:
The firmware is better but I still get occasional odd results. For example, after uploading (fixed) AnalogReadSerial then uploading ASCIITable then opening the serial monitor, I get this:

Would you mind run my Java ElectroShaman SerPro as discussed on other thread http://arduino.cc/forum/index.php/topic,146696.0.html to see if firmware update helps ?

I suggest this because a real RX/TX with 16-bits CRC detection provides many diversity of USB links so in a way, is tough or heavy duty test.

Thank you, Albert

stimmer:
I guess the first few lines are remnants of what is stuck in the OS serial input buffer from AnalogReadSerial, but I'm not sure what's going on before ASCIITable starts properly.

How can it be? I mean... there is a sketch upload beetween AnalogReadSerial and ASCIIITable output, the only way is that RXTX keeps the last read buffer even if you close and open the serial port.

Hello!

I am bitten by the same bug. I want to update the firmware. Can anybody point me to any easy to follow recipe for updating the firmware on Linux (or Windows)? Thanks.

Stephan

I only have a Mac and i'm stuck, it seems no DFU-programmer exist for Mac, see http://arduino.cc/forum/index.php/topic,147639.0.html

A friend of mine told me of this site that reports a DFU for the atmega16u2, maybe it works for you on PC http://dfu-programmer.sourceforge.net

Otherwise cmaglie wrote me this private mail

The 16u2 doesn't have DFU firmware inside, you must program it with an AVR-ISP (or equivalent programmer) from the ISP connector (the 6-pin header near the power jack).
If you don't have an ISP programmer you can emulate one using an Arduino Uno or Mega loaded with the ArduinoISP sketch.
http://arduino.cc/en/Tutorial/ArduinoISP
Arduino Playground - MegaISP

So I'm confused, Albert

The only way to upgrade the 16u2 firmware on the Due Board is with an ISP programmer.

You can use DFU-programmer, Flip, or similar only if the "DFU bootloader" is burned into the 16u2, but this is not the case.

Ok cmaglie,

I happen to have an Arduino Uno. The tutorial at http://arduino.cc/en/Tutorial/ArduinoISP does not mention how to update the Due firmware from an Arduino Uno. And I do not want to connect it as shown in the tutorial because of the 5V intolerant inputs of the Due. Can you describe how to connect these two boards?

Sorry, I am more on the programming side and not so much on the hardware side (that's why I opted for the Arduino).

Thanks,
Stephan

The 16U2 is running from 5v. It should be safe to program from 5v programmers via ICSP. Just make sure you use the 6-pin header next to it.

Would anyone of you gurus go the extra mile and enlighten us not that bright users which pin on the Uno we have to connect to which pin on the Due? Thanks!

Stephan

sphh:
I happen to have an Arduino Uno. The tutorial at http://arduino.cc/en/Tutorial/ArduinoISP does not mention how to update the Due firmware from an Arduino Uno. And I do not want to connect it as shown in the tutorial because of the 5V intolerant inputs of the Due. Can you describe how to connect these two boards?

Sorry, I am more on the programming side and not so much on the hardware side (that's why I opted for the Arduino).

I asked one of my collaborator to write a step-by-step tutorial for that, more info coming in a short while.
Thanks for the patience.

Here the tutorial to upload new firmware on the ATmega16u2:

please report any issue/success by posting a comment here:

All right, working much better now with new USB firmware Bugfix for garbage data coming from serial port after reset. (Arduino Due) by cmaglie · Pull Request #1267 · arduino/Arduino · GitHub