Go Down

Topic: Garbage using serial functions in Arduino Due (Read 8 times) previous topic - next topic


It happens at 9600.

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

Code: [Select]
    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:
Code: [Select]

  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:

Code: [Select]

void setup() {
  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.

Go Up