Common problem on MEGA R3

Development Tools IDE 1.x
1

Hi guys,
i'm posting as in the italian forum we're having many issues with the mega r3 board.

The problems seems to be related with the auto-reset of the board when loading the sketch.

Using the 0022, 0023, 1.0 and 1.0.1 IDEs the problem doesn't change.

after some tries with the IDE we decided to help our members using AVRDUDE scripts.
here is the result trying to read the signature of the micro

avrdude.exe -C "C:\avr\etc\avrdude.conf" -p m2560 -c stk500v2 -P COM3
avrdude.exe: stk500v2_ReceiveMessage(): timeout
avrdude.exe: stk500v2_ReceiveMessage(): timeout
avrdude.exe: stk500v2_ReceiveMessage(): timeout
avrdude.exe: stk500v2_ReceiveMessage(): timeout
avrdude.exe: stk500v2_ReceiveMessage(): timeout
avrdude.exe: stk500v2_getsync(): timeout communicating with programmer

on an MEGA ADK the result seems like this

"C:\avr\bin\avrdude.exe" -C "C:\avr\etc\avrdude.conf" -p m2560 -c stk500v2 -P COM5
Device signature 0x1e9801
FUSE OK
thank you

I know there's an issue trying to upload a sketch wich sends "!!!" via the serial but we're trying to upload only the blink sketch so no serial has been used up to now.

Actually i don't have a MEGA board so i'm only reporting the issues found on the italian topic.

One user found a solution replacing the reset capacitor.

One last thing:
i found a user who has received the MEGA board with the atmega16u2 in DFU mode and not with the "firmware started"

Are these known issues?

(sorry for my bad english)

2

My analysis: I get
avrdude: stk500v2_ReceiveMessage(): timeout
and
avrdude: stk500v2_getsync(): timeout communicating with programmer

My solution was to remove some of the many Serial.Print statements.

I had over 100 Serial.print statements.
After reducing that to less than 70, I was able to run my program

It was either too many print statements or the length of the strings in the total set of print statements.

Cheers!
Robert

3

Try reducing the number of Serial.print statements

4

I think there are 2 problems with the mega r3, the chinese clones are very low quality and there is something about timing or similar with the 16u2/8u2 and WinAVR.

I tried to remotelly fix a bad mega owned by a user in this forum (he provided remote desktop access), and after testing everything, everytime we upload a new firmware for the 16u2 (even if we used the wrong version, like 8u2 to 16u2) the mega worked for couple of minutes. No firmware checksum was corrupted, we checked atmega and 16u2 firmwares and it is something with the board+WinAVR (I have 3 italian boards and all other ones are clones, and lastly I was having issues with the 2560 clone. But in my case the new WinAVR fixed all my issues)