Go Down

Topic: Mega 2560 R3 not uploading any sketch (Read 4022 times) previous topic - next topic

kuba

Guys,

I've run out of ideas of what might be wrong.

I have Mega 2560 board R3. I connect it via USB to a Windows 7 machine (I tried two win 7 PCs and one running linux ubuntu)
I think I installed the environment (1.0.1) and drivers correctly My Arduino appears in Device Manager as installed on COM Port4. In the IDE I select "Mega 2560 or Mega ADK" in the Board Menu and COM4.
When plugged in the board's L led blinks (around 1 sec interval)
My board passed the loopback test as  described in the "Loop-Back Test Instructions" post http://arduino.cc/forum/index.php/topic,73748.0.html That is, it replied back what I typed.

However, when I upload any sketch (I tried Blink and BareMinimum), I get the following

Code: [Select]
Binary sketch size: 1,624 bytes (of a 258,048 byte maximum)
g:\install\arduino\hardware/tools/avr/bin/avrdude -Cg:\install\arduino\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega2560 -cstk500v2 -P\\.\COM4 -b115200 -D -Uflash:w:C:\Users\kuba\AppData\Local\Temp\build7322163887359083181.tmp\Blink.cpp.hex:i

avrdude: Version 5.11, compiled on Sep  2 2011 at 19:38:36
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "g:\install\arduino\hardware/tools/avr/etc/avrdude.conf"

         Using Port                    : \\.\COM4
         Using Programmer              : stk500v2
         Overriding Baud Rate          : 115200
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14]
avrdude: Recv:
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14]
avrdude: Recv:
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14]
avrdude: Recv:
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14]
avrdude: Recv:
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14]
avrdude: Recv:
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14]
avrdude: Recv:
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_getsync(): timeout communicating with programmer
         AVR Part                      : ATMEGA2560
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    10     8    0 no       4096    8      0  9000  9000 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           flash         65    10   256    0 yes    262144  256   1024  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : STK500V2
         Description     : Atmel STK500 Version 2.x firmware
         Programmer Model: Unknown
avrdude: Send: . [1b] . [01] . [00] . [02] . [0e] . [03] . [90] . [85]
avrdude: Recv:
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14]
avrdude: Recv:


The RX led occasionally blinks, TX stays quiet. I upload the program without anything connected to the board. I tried this tutorial http://arduino.cc/en/Tutorial/Blink before but learnt that it might be worth to try to upload to an empty board.

I think I tried everything -


And now I'm stuck. My only side-note observation is that the board is recognized within the OS as "Mega 2560" not "Mega 2560 REV3", even though from physical perspective it looks ok - it has Mega 16U2 chip, and additional pins.

Any help would be appreciated. Is there anything I could test to see if the board is faulty?

Thanks,

Kuba


Nick Gammon

Do you have another board, like a Uno? If so you could try the "board detector" described here:

http://www.gammon.com.au/forum/?id=11633

It won't resolve the exact issue you are having but would show if the main part of the board is live. If the L light blinks I guess it is.
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics

kuba


Do you have another board, like a Uno?  (...)


Hello,

No, I don't , but I do have a USB-UART converter (AVR programmer) - based on FT232R chip, that I use as serial console for odroid-x board. Would that allow me to read into the Arduino?

Thanks,

Kuba

Without SPI/ICSP access, your kinda stuck.  The FTDI is only handy with the bootloader working, and it does not sound like this is the case.  Your 16u2 sounds like it is ok, but I know of no one that has a sketch for the 8u2/16u2 to SPI out to the Atmega2560.  Could be handy, but most seem to fry the 8u2/16u2...

You are either going to have to:

a) Get a ICSP programmer (No TinyISP)
b) Get a *new* Mega2560 board
c) Get that Uno you should have had before the Mega2560 ;)

Sorry about the death in the family.
http://www.spcomputing.com

dougiel

I dont think the gent has a "death in the family". I am having exactly the same problems. At least one other here has said he has. Rather than just say his Mega died why not get him to install 0022 and test again. Thats what I did and the Mega can be uploaded to with no problems !.
I think its the software or installation thats wrong, not the Mega.
Dougie L

kuba

Guys,

Thanks for your replies. I forgot to mention what I haven't tried yet - which is the bootloader burning.
The reason I'm "contemplating" this step is because I don't know if my bootloader works ok - the L led flashes all the time with irregular intervals 1-2 seconds. I thought it should be either regular intervals or just once, twice. What is the "standard" behaviour of this led? Can I test/probe/verify this bootloader somehow?

I'm reluctant to go on with burning because I haven't found a definitive guide how to do it for Mega 2560 R3 (or basically a confirmation that it helped to anyone having problem similar to mine, or at least to something other than "!!!" in the code) -  I don't want to mess with it if I'm not sure this is the problem with the board.

I think that if the board is responding to loopback test, the main chip seems to be working (correct assumption?)

Cheers,

K.



I think that if the board is responding to loopback test, the main chip seems to be working (correct assumption?)




Other way around.  Your loopback test passing shows basic communications with the 16u2.  The 16u2 "appears" to be functioning properly, so I suspect the bootloader on the Atmega2560 (main chip) somehow got zapped.

You are going to need one of the three things I mentioned before to get the bootloader back on.
http://www.spcomputing.com

Mozart

I have been experiencing similar issues.  I am running on Windows XP, the loop-back test works successfully, the ATmega2560 is enumerated within the list of available devices.  I have an AVRISPmkii and an AVR One! in all cases I have been able to program the ATmega2560 with the ISP successfully.  However, I am unable to program the 16u2 in order to restore it to an initial state.  I am unable to program via USB in any of the Arduino Development environments going back to version 0022 so I don't think it is:

1> AVRISPmkii
2> AVR One!
3> Arduino Development environment
4> The ATmega2560

I am not sure if this helps but thought I would share my experiences in hopes that we can figure out why Arduino in conjunction with Atmel are turning out defective 2560 boards.

If you are AVRDUDE savy, you can use the README.txt in \hardware\arduino\firmwares:
Code: [Select]
avrdude -p at90usb82 -F -P usb -c avrispmkii -U flash:w:MEGA-dfu_and_usbserial_combined.hex -U lfuse:w:0xFF:m -U hfuse:w:0xD9:m -U efuse:w:0xF4:m -U lock:w:0x0F:m

Other than that, there is FLIP and the DFU tutorial:
http://www.atmel.com/tools/FLIP.aspx
http://arduino.cc/en/Hacking/DFUProgramming8U2

Or use the AVR ONE! and burn the MEGA-dfu_and_usbserial_combined.hex file...
http://www.spcomputing.com

Mozart

In this case I am "avrdude" savvy and have tried the code that you have provided:
Quote
avrdude -p at90usb82 -F -P usb -c avrispmkii -U flash:w:MEGA-dfu_and_usbserial_combined.hex -U lfuse:w:0xFF:m -U hfuse:w:0xD9:m -U efuse:w:0xF4:m -U lock:w:0x0F:m

with changes to fit my development environment...
And some of the additional derivatives on this theme have included:
Code: [Select]
avrdude -C avrdude.conf -p m16u2 -F -c avrispmkii -P COM8 -U flash:w:\arduino1\hardware\tools\avr\bin\Arduino-usbserial-atmega16u2-Mega2560-Rev3.hex  -U lfuse:w:0xFF:m -U hfuse:w:0xD9:m -U efuse:w:0xF4:m -U lock:w:0x0F:m
In the previous case I have tried a variety of Arduino hex builds as provided on their sourceforge site.

As stated I have an AVR One as well and although it can not program to the 16u2 in JTAG mode, when I add the ISP connector it does not work either.

I have also tried to use the programmer provided within Studio 5 and Studio 6 and although as stated I am able to program via the ISP to the 2560, the 16u2 remains a mystery, even with the hardware reset as indicated for the 8u2.

There seems to be quite a few users having a great deal of difficulty with the 2560 or rather Arduino's delivery and lack of support for the chip and its 16u2 R3 add-on.  I don't understand the total lack of support either by Arduino or Atmel.  I do understand the nature of open source but these boards are being sold in retail outlets and if plugging them in and simply trying to load a simple blink program onto them via the IDE causes this amount of difficulty then perhaps some thing need to be re-examined.  Either by Arduino or the consumer (you and me).

As you can see, there is some frustration here and I can sense it in the OP follow-on posts as well as other threads regarding the same issue.  However, I am not willing to throw in the towel just yet.  After spending as much time as I have in trying to figure this thing out I believe a certain form of stubbornness has settled in, on my part and giving up isn't an option.  So, like so many of you I shall sally forth and keep at it.

I apologize if I came off condescending.  It is no excuse, but there are a lot of instances of not RTFM.  Obviously your not one of these instances.

Back to the tech rudeness ;)
Do you have the current fuse settings of the 16u2?  Does  AVRDUDE or AVR ONE! read anything from the 16u2 chip (SIG, etc)?

While I have yet to have an issue with the 8u2/16u2, I shall tear into one of them and share your pain.

Check back tomorrow for my Arduino cursing ;)
http://www.spcomputing.com

Mozart

Absolutely no apology necessary.  Please don't feel bad.  My experience and that of many others that I have talked to including, I think, the OP of this thread, is one of frustration with the R3 2560 and its union with the 16u2. My post was not, at least in my case, meant to be directed towards anyone. Especially someone such as yourself willing to help out...so if anything I owe you an apology.

So, I have attached three screen shots taken from the AVR Studio 6 Device Programming menu.  These snap shots could have just as easily been taken from any of the Atmel Studio IDE's.  The first snapshot represents  current interface settings, the second represents current fuse settings and the third represents current lock bit settings.  These settings were read from the board using the AVRISPmkII.  The AVR One set in ISP mode reads the exact same thing.

When I try to flash any hex file it always returns the same confirmation indicating that the program has been transfered correctly and I should be ready to go, however, this is never the case since I immediately de-activate the Jungo devices, then pull up any of a number of Arduino IDE's and try to program the board via serial USB connection.  Inevitably I receive a string of timeouts...I receive the same response when I go to a command prompt and run avrdude.  My goal is simply to get the 2560 and 16u2 back into a start state and load a stupid simple program such as blink.

I am able to program the 2560 (bypassing the 16u2) with the ISP both the AVRISPmkii and the AVR One.  Any assistance would be GREATLY appreciated.

Thanks!!

Ok, I just realized I do not have an R3 but R2 Mega2560 (8u2).  But I do have an Uno R3, so we are half way there...

Anyhow, I uploaded the 8/16u2 usbserial hex files successfully to an Uno R2(8u2) and R3(16u2) with AVRDUDE and an USBasp.

(8u2)
Code: [Select]
C:\WinAVR-20100110\bin>avrdude -p at90usb82 -F -P usb -c usbasp -U flash:w:Ardui
no-usbserial-uno.hex -U lfuse:w:0xFF:m -U hfuse:w:0xD9:m -U efuse:w:0xF4:m -U lo
ck:w:0x0F:m


(16u2)
Code: [Select]
C:\WinAVR-20100110\bin>avrdude -p at90usb[b]162[/b] -F -P usb -c usbasp -U flash:w:[b]Ardu
ino-usbserial-uno.hex[/b] -U lfuse:w:0x[b]EF[/b]:m -U hfuse:w:0xD9:m -U efuse:w:0xF4:m -U l
ock:w:0x0F:m


What I am wondering now, did you burn your Bootloader back onto the Mega2560 after you uploaded sketches with your AVRISP?  Try burning the 16u2 hex with whatever gives you no errors and then through the IDE, burn the Bootloader with your AVRISP on the other header.
http://www.spcomputing.com

kuba

#13
Sep 10, 2012, 10:25 pm Last Edit: Sep 10, 2012, 11:42 pm by kuba Reason: 1

Do you have another board, like a Uno? If so you could try the "board detector" described here:

http://www.gammon.com.au/forum/?id=11633

It won't resolve the exact issue you are having but would show if the main part of the board is live. If the L light blinks I guess it is.


Hello Nick,

I managed to get hold of a UNO board (which works ok) and wired it to the Mega2560 according to your aforementioned post. I thought it wasnt working at first but just noticed the wiring for Mega 2560 is different.
I attach output of the program. Does that help?

Thank you,

Kuba

Mozart

spcomputing,

As things turned out I had a bad 16u2, which I suspect is a pervasive issue with the 2560 board, but that is just an opinion.  I received a full refund for the board and then bought two UNO R3's.  Funny but everything simply behaves a LOT better as in everything works properly now.  It really is a breeze vs. the amount of work the 2560 required to do the simplest da_m_n thing.  Any way, my recommendation is to choose option (c) in you multiple choice comment stated earlier in this thread.  Thanks for trying to help, I really appreciate it.

Kuba,

In my humble opinion I think you are pounding a lot of dirt to get the 2560/16u2 to work.  The spec sheet on the MC is awesome but I don't think the makers have worked out the defects in production and there just doesn't seem to be critical mass support for that particular chip.  I would encourage you to keep trying but perhaps it should be a 2nd or 3rd hobby because that dog (2560) just don't bark.  Again, my opinion and I do apologize to anyone that is offended and or disagrees.

Go Up