Garbage using serial functions in Arduino Due

Does anybody know if Arduino Due has some issues with the Serial.print function?

I am running the following sketch taken from http://arduino.cc/en/Serial/Available :

int incomingByte = 0;   // for incoming serial data

void setup() {
        Serial.begin(9600);     // opens serial port, sets data rate to 9600 bps
}

void loop() {

        // send data only when you receive data:
        if (Serial.available() > 0) {
                // read the incoming byte:
                incomingByte = Serial.read();

                // say what you got:
                Serial.print("I received: ");
                Serial.println(incomingByte, DEC);
        }
}

and every time I invoke the serial monitor or any other like Hyperterminal, I am getting garbage in the first two lines like:

I??¥Ù?: 255
I r

I??¥Ù?'?Ê?j
I reã

I??¥Ù??Ê?j
I reÿ

I ran the same sketch in my UNO and no garbage came up!

Thanks!

I forget which board I had the problem with but, I had to put a delay() in setup to give the serial monitor a chance to come up before the board tried to communicate.

In my case, I think I was printing from the board early in the sketch.

cyclegadget:
I forget which board I had the problem with but, I had to put a delay() in setup to give the serial monitor a chance to come up before the board tried to communicate.

In my case, I think I was printing from the board early in the sketch.

Leonardo? For that board it was:

// while the serial stream is not open, do nothing:
   while (!Serial) ;

...or a delay(1) after a serial print. That said, since this is going through the 16u2, it should not be full speed (FIFO) through the USB and overloading the port buffer. Curious...

I tried delay(10) after the serial prints but the garbage still. The interesting that the garbage only shows up when the terminal window is open. If I press the reset button, no more garbage. It could be may machine. I will try to test it in another computer.

Edit: after I posted the stuff below, I changed the baud rate on your sketch to 115200 in Serial.begin. Now the garbage looks like this:

DDÄI recei?é 0
I received: 0

I have the same problem with many sketches. The problem also involves Serial.read(), there is garbage when you use Serial.available().

In your sketch, it appears to execute the code after this if statement:

if (Serial.available() > 0) {

Your output is garbled stuff from these print calls:

  Serial.print("I received: ");
  Serial.println(incomingByte, DEC);

Note how often you get "I re" as part of the garbage. The 255 suggests you read 0XFF.

I'm almost convinced there is something wrong with DUE's implementation of Serial.available() Serial.read() and so

As I've explained on some other threads this morning, I've got code running for years on MEGA, it does compile the download fine on DUE but will not work, in my case a Serial protocol called SerPro using HDLC on top of USB link. There are constant CRC errors hence the frames are rejected then re-sent, my core program

// Start of SERPRO implementation
struct SerialWrapper
{
public:
	static inline void write(uint8_t v){Serial.write(v);}
	static inline void write(const uint8_t *buf,int size){
		int z;
		for(z=0;z<size;z++) Serial.write(buf[z]);
	}
	static inline void flush() {}
};

struct SerProConfig {
	static unsigned int const maxFunctions = MAX_SERPRO_FUNCTIONS;
	static unsigned int const maxPacketSize = 32;
	static unsigned int const stationId = 3;
	static SerProImplementationType const implementationType = Slave;
};

DECLARE_SERPRO(SerProConfig,SerialWrapper,SerProHDLC,SerPro);

void setup()
{
// protocol initialization
  Serial.begin(BAUD_RATE);

// Testing leds
  pinMode(ledLinkUp,OUTPUT);
  pinMode(ledCRCerror,OUTPUT);
  pinMode(ledRcv,OUTPUT);
  pinMode(ledXmit,OUTPUT);
}

void loop()
{
  if (Serial.available() > 0) SerPro::processData(Serial.read() & 0xff);
}

// End of SERPRO implementation
IMPLEMENT_SERPRO(MAX_SERPRO_FUNCTIONS,SerPro,SerProHDLC);

Here is a sketch with a counter. Looks like Serial has several, maybe 6, bytes of garbage input when a reset from opening a Serial monitor happens.

Load this sketch into the Due:

int n = 0;
void setup() {
  Serial.begin(115200);
}
void loop() {
  if (Serial.available()) {
    Serial.read();
    Serial.write('N');
    Serial.println(++n);
  }
}

then open a serial monitor and you get this:

þþN5
N6

Close and open the serial monitor again and you get a similar result. Almost always ending with the "N6" line.

Adding a delay(2000) after Serial.begin seems to fix it after reload but not on a reopen of the monitor.

I tried this but still get the problem.

while (!Serial);

So if you write for Uno, Leonardo, and Due what is the correct answer to avoid this?

I did more testing and the junk you get is sent to serial before the reset done by opening the serial monitor.

If you run this sketch and open a serial monitor at 115200, you will see some junk printed from loop() before the HI printed in setup().

void setup () {
  Serial.begin(115200);
  Serial.println();
  Serial.println("HI");
}
int n = 0;
void loop() {
  if (Serial.available()) {
    Serial.println();
    Serial.print(++n);
    Serial.write("c=");
    Serial.print(Serial.read(), HEX);
  }
}

output:

öþ
5c=0
6c=0
HI

This seems to indicate that when the serial monitor is opened, some junk is sent to serial, and then the reset restarts the program which prints "HI".

This can cause big problems with a sketch that tries to wait for input like this:

void setup() {
  Serial.begin(115200);
  Serial.println("Type any character to start");
  while (Serial.available() == 0) {}
}
int n = 0;
void loop() {
  Serial.println(++n);
}

The output is:

Êa
F??
1
42
j
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
ÿType any character to start

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