Pages: [1]   Go Down
Author Topic: Mega2560 bricked? not detected, DFU failing  (Read 6640 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 0
Posts: 20
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hello!

I have two mega2650's. One is not detected by windows or linux. I can check that my computer and USB ports are working properly with the 2nd mega - so it's definately a problem with the board.

I believe the problem may be some errant serial code flooding serial0. It stopped working when I was working on some data collection code, which involved Serial.println("no data") inside loop(), and I'm not sure if I had a delay in there at all. It's also possible that I've just hit the upload limit... but I'd be very surprised if I've uploaded to it more than 2000 times, and I'd imagine the device would still be detected. Almost more likely that a wire inside the USB connector is broken.

- It was working for months (and an hour before), swapping between an externally powered application and usb power/connection to program it
- I uploaded slightly different code (removing a delay perhaps; the code was to read bytes from Serial2 and print them to Serial), successfully I believe; it is possible this upload failed due to forgetting to disattach an Xbee shield
- I moved the board to my application (external power, connected to some Serial devices and possibly LEDs), it didnt perform as expected (I dont' remember if it was getting data from the serial devices)
- when I returned the board to USB power to change the code again, it was no longer detected by the computer (within a 1 minute period from when I uploaded the previous code)
- It hasnt been detected since

This was a few months ago, I'm sorry if I'm a little uncertain about the details, it was very busy at the time.


I've tried putting it into DFU mode (using http://www.wayneandlayne.com/blog/2011/02/16/fixing-linux-firmware-issues-on-arduino-mega-2560/ this lovely picture to assist) and it does not respond to either Flip (though I'm not sure I was using Flip correctly) on Windows, or dfu-programmer 0.5.1 on linux Ubuntu2.6.28-11-generic (Flip says "No USB Device" or something similar, dfu-programmer says "dfu-programmer: no device present."; I couldnt get 0.5.4 to compile on Ubuntu, something about missing a LIBUSB_1_0 declaration). It's also not showing up in the USB Hardware device list on Windows (neither XP or 7) or through lsusb or dmesg on linux (dmesg output below), ie no difference with it plugged in or not, and it makes no difference if it's in DFU mode either.

When I plug it into any USB port (I've tried 5 computers or so) the ON led comes on, and pin13 LED flashes twice and then remains on in this pattern: ---- -- ---------------------...... The other working mega2560 pin 13 flashes like this, turning off at the end: ---- -- --------

On Ubuntu, lsusb shows
 Bus 002 Device 007: ID 2341:0010
when the good mega is plugged in, nothing similar for the bad one.

The pins all look normal. The board reacts to a reset button as if power has been cycled. When I try to put it in DFU mode, and touch the two small pads for HWB and GND together (green in this picture http://www.wayneandlayne.com/blog/2011/02/16/fixing-linux-firmware-issues-on-arduino-mega-2560/ ) with a wire, the board acts as if power has been cycled (lights flash); interestingly though, no lights flash when I touch reset and ground (the larger pads closest to the USB, red in the picture).

Anyone have any ideas for other things to check? Or ideas on what I did to get it into this state? Right now my mega is a very nice paperweight smiley-sad

Thanks everybody smiley
Chris

Quote
$ dmesg | grep usb
[    0.416538] usbcore: registered new interface driver usbfs
[    0.416538] usbcore: registered new interface driver hub
[    0.416538] usbcore: registered new device driver usb
[    1.996076] usb usb1: configuration #1 chosen from 1 choice
[    1.996363] usb usb2: configuration #1 chosen from 1 choice
[    1.996568] usb usb3: configuration #1 chosen from 1 choice
[    1.996769] usb usb4: configuration #1 chosen from 1 choice
[    1.996968] usb usb5: configuration #1 chosen from 1 choice
[    1.997078] usbcore: registered new interface driver libusual
[    1.997100] usbcore: registered new interface driver usbserial
[    1.997119] usbcore: registered new interface driver usbserial_generic
[    1.997121] usbserial: USB Serial Driver core
[    2.508510] usb 4-1: new low speed USB device using uhci_hcd and address 2
[    2.694796] usb 4-1: configuration #1 chosen from 1 choice
[    7.040234] usbcore: registered new interface driver hiddev
[    7.053894] input: GenesysLogic USB Mouse as /devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0/input/input5
[    7.054128] generic-usb 0003:05E3:1205.0001: input,hidraw0: USB HID v1.10 Mouse [GenesysLogic USB Mouse] on usb-0000:00:1d.2-1/input0
[    7.054144] usbcore: registered new interface driver usbhid
[    7.054161] usbhid: v2.6:USB HID core driver

Directly after putting in DFU mode (I plugged  in my functioning mega first), I noticed a difference:

Quote
$ dmesg | grep usb
[    0.416538] usbcore: registered new interface driver usbfs
[    0.416538] usbcore: registered new interface driver hub
[    0.416538] usbcore: registered new device driver usb
[    1.996076] usb usb1: configuration #1 chosen from 1 choice
[    1.996363] usb usb2: configuration #1 chosen from 1 choice
[    1.996568] usb usb3: configuration #1 chosen from 1 choice
[    1.996769] usb usb4: configuration #1 chosen from 1 choice
[    1.996968] usb usb5: configuration #1 chosen from 1 choice
[    1.997078] usbcore: registered new interface driver libusual
[    1.997100] usbcore: registered new interface driver usbserial
[    1.997119] usbcore: registered new interface driver usbserial_generic
[    1.997121] usbserial: USB Serial Driver core
[    2.508510] usb 4-1: new low speed USB device using uhci_hcd and address 2
[    2.694796] usb 4-1: configuration #1 chosen from 1 choice
[    7.040234] usbcore: registered new interface driver hiddev
[    7.053894] input: GenesysLogic USB Mouse as /devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0/input/input5
[    7.054128] generic-usb 0003:05E3:1205.0001: input,hidraw0: USB HID v1.10 Mouse [GenesysLogic USB Mouse] on usb-0000:00:1d.2-1/input0
[    7.054144] usbcore: registered new interface driver usbhid
[    7.054161] usbhid: v2.6:USB HID core driver
[ 6597.592015] usb 2-1: new full speed USB device using uhci_hcd and address 2
[ 6597.792335] usb 2-1: configuration #1 chosen from 1 choice
[ 6597.840092] usbcore: registered new interface driver cdc_acm
[ 6602.176041] usb 2-1: USB disconnect, address 2
[ 6603.904015] usb 2-1: new full speed USB device using uhci_hcd and address 3
[ 6604.105308] usb 2-1: configuration #1 chosen from 1 choice
[ 6609.864041] usb 2-1: USB disconnect, address 3
[ 6611.344016] usb 2-1: new full speed USB device using uhci_hcd and address 4
[ 6611.543802] usb 2-1: configuration #1 chosen from 1 choice
[ 6613.088043] usb 2-1: USB disconnect, address 4
[ 6615.756012] usb 2-1: new full speed USB device using uhci_hcd and address 5
[ 6615.956209] usb 2-1: configuration #1 chosen from 1 choice
[ 7285.416036] usb 2-1: USB disconnect, address 5

and
Quote
$ dmesg | grep cdc_acm
[ 6597.837230] cdc_acm 2-1:1.0: ttyACM0: USB ACM device
[ 6597.840092] usbcore: registered new interface driver cdc_acm
[ 6597.840096] cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters
[ 6604.116606] cdc_acm 2-1:1.0: ttyACM0: USB ACM device
[ 6611.548016] cdc_acm 2-1:1.0: ttyACM0: USB ACM device
[ 6615.959079] cdc_acm 2-1:1.0: ttyACM1: USB ACM device
Logged

Left Coast, CA (USA)
Offline Offline
Brattain Member
*****
Karma: 361
Posts: 17301
Measurement changes behavior
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Anyone have any ideas for other things to check? Or ideas on what I did to get it into this state? Right now my mega is a very nice paperweight


Well you can 'half split' the problem to either the 82U or the avr2560. Press and keep holding down the reset pin (or wire a jumper from ground to the reset pin) and plug it into the PC's usb port. If the PC still doesn't see it then it has nothing to do with the last sketch loaded on the board and the problem has to be with the USB side of the board. I assume the power led lights up when you plug in the board?

Lefty

Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 20
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Thanks! The power LED is on. I think I tried holding reset, and it wasn't detected by Linux... but I will double-check again tomorrow when I have the board, and with Windows.

- Chris
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 20
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I tried holding reset, the mega still doesn't show up in Device Manager. So I suppose I'm dealing with a problem with the 8u2 chip then. Is it possible the chip is fried? Is there any way to check this, or to reload it's firmware?

Cheers,
Chris
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 20
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I'm going to try following this http://arduino.cc/en/Tutorial/ArduinoISP to reflash the firmware with my megas. This post http://www.forums.adafruit.com/viewtopic.php?f=25&t=19438 mentions that on an Uno they've successfully used ISP to bypass the 8u2. I'll see what I can find to test the atmega2560 with ISP. Keep you all posted smiley
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 20
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Following http://arduino.cc/en/Tutorial/ArduinoISP didn't work. I connected pins 50 to 53 of both mega2560s together (as per http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1279287827 this recommendation) and 5V and GND together.

When I select Burn Bootloader -> w/ Arduino as ISP the output is:
Burning bootloader to i/o board...
Error while burning bootloader.
 avrdude: stk500_getsync(): not in sync: resp=0x00

The RX light on the ISP arduino flashes twice right after I select Burn Bootloader -> w/ Arduino as ISP; no other lights flash. The L light on the dead mega is still lit constantly when the live mega is plugged into USB; when the power is cycled, the two megas flash their L lights identically, and then the good mega shuts off the L light, the bad mega leaves it on. Both power leds (ON) are lit.

Some similar ArduinoISP with atmega2650 posts:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1287952386 this post mentions there could be some updates to ArduinoISP sketch necessary to program a mega, due to the increased address space of a mega; its been added as a googlecode issue.
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1279287827 this person was having trouble using ArduinoISP on a mega as well... though perhaps it was a power problem.

I'd like to check the voltages on the 8u2 chip, but since it's surface-mount that seems very difficult...

Out of ideas for the moment, other than maybe getting an ISP programmer, maybe this one http://www.adafruit.com/index.php?main_page=product_info&cPath=16&products_id=46 to try with avrdude. There's a few people working on using ISP direct to the 8u2 (http://arduino.cc/forum/index.php?topic=55790.0 )
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 20
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset



Alright, one more thing to try. Added a header to the 8u2 ISCP port, and connected it to my ArduinoISP.

From https://github.com/arduino/Arduino/tree/master/hardware/arduino/firmwares/ readme.txt, I'm using the following line:

>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
 avrdude: AVR Part "at90usb82" not found.

 Valid parts are:
  m6450 = ATMEGA6450      [C:\WinAVR-20100110\bin\avrdude.conf:11732]
 .... big list

 I also tried executing avrdude.exe with the same parameters from within \arduino-0022\hardware\tools\avr\bin after removing the WinAVR directories from the PATH variable, with the hope it would use the avrdude included with Arduino, and would include at90usb82... still seemed to be referencing the WinAVR installation though. Reinstalled WinAVR from sourceforge to the latest version. Now, "did not find any USB device "usb"", so that seems to have solved the "valid part" issue.

So, I changed the port to COM4,
>avrdude -p at90usb82 -F -P COM4 -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

 avrdude: stk500_2_ReceiveMessage(): timeout

Now it just times out. Any ideas? I have to go now, will research when I get back smiley
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 20
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Solved the avrdude issue, the proper call to get avrdude to work with the 8u2 (for me) is this, it wasnt working before because I had the wrong programmer selected (ArduinoISP is -c avrisp):

avrdude -p at90usb82 -F -P com4 -c avrisp -v -e -b 19200 -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

So that worked, output was
Code:
avrdude: Version 5.10, compiled on Jan 19 2010 at 10:45:23
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "C:\WinAVR-20100110\bin\avrdude.conf"


         Using Port                    : com4
         Using Programmer              : avrisp
         Overriding Baud Rate          : 19200
         AVR Part                      : AT90USB82
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC6
         RESET disposition             : possible i/o
         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  Max W   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- --- -- ---------
           eeprom        65    20     4    0 no        512    4    128  9000  90 00 0x00 0x00
           flash         65     6   128    0 yes      8192  128     64  4500  4500 0x00 0x00
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0 0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0 0 0x00 0x00

         Programmer Type : STK500
         Description     : Atmel AVR ISP
         Hardware Version: 2
         Firmware Version: 1.18
         Topcard         : Unknown
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.13s
avrdude: Device signature = 0x1e9389
avrdude: Expected signature for AT90USB82 is 1E 93 82
avrdude: safemode: lfuse reads as EF
avrdude: safemode: hfuse reads as D9
avrdude: safemode: efuse reads as F4
avrdude: erasing chip
avrdude: reading input file "MEGA-dfu_and_usbserial_combined.hex"
avrdude: input file MEGA-dfu_and_usbserial_combined.hex auto detected as raw binary
avrdude: writing flash (8192 bytes):
Writing | ################################################## | 100% 9.42s
avrdude: 8192 bytes of flash written
avrdude: verifying flash memory against MEGA-dfu_and_usbserial_combined.hex:
avrdude: load data flash data from input file MEGA-dfu_and_usbserial_combined.he
x:
avrdude: input file MEGA-dfu_and_usbserial_combined.hex auto detected as raw bin
ary
avrdude: input file MEGA-dfu_and_usbserial_combined.hex contains 8192 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 9.41s

avrdude: verifying ...
avrdude: 8192 bytes of flash verified
avrdude: reading input file "0xFF"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.11s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xFF:
avrdude: load data lfuse data from input file 0xFF:
avrdude: input file 0xFF contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.03s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xD9"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.03s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xD9:
avrdude: load data hfuse data from input file 0xD9:
avrdude: input file 0xD9 contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.05s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xF4"
avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.03s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xF4:
avrdude: load data efuse data from input file 0xF4:
avrdude: input file 0xF4 contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.03s

avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: reading input file "0x0F"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.13s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x0F:
avrdude: load data lock data from input file 0x0F:
avrdude: input file 0x0F contains 1 bytes
avrdude: reading on-chip lock data:
Reading | ################################################## | 100% 0.03s
avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as D9
avrdude: safemode: efuse reads as F4
avrdude: safemode: Fuses OK

I unplugged the USB from the ArduinoISP mega, unplugged the wires, and tried plugging in the bricked mega. Still wasn't detected though... more in next post smiley
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 20
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

So then I tried to flash the atmega2560 firmware with the Arduino IDE, connecting to the other ICSP connector with my ArduinoISP; selecting "Burn Bootloader -> w/ Arduino as ISP gives "avrdude: stk500_getsync(): not in sync: resp=0x00". Selecting w/ AVR ISP gives "avrdude: stk500_getsync(): not in sync: resp=0x00 ; avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51"

So I switched back to using avrdude, same wiring; this was the result:

Code:
> avrdude -p m2560 -P com4 -c avrisp -b 19200 -v -e -U flash:w:Arduino-usbserial-mega.hex -U lock:w:0xCF:m
avrdude: Version 5.10, compiled on Jan 19 2010 at 10:45:23
        Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
        Copyright (c) 2007-2009 Joerg Wunsch
        System wide configuration file is "C:\WinAVR-20100110\bin\avrdude.conf"
        Using Port                    : com4
        Using Programmer              : avrisp
        Overriding Baud Rate          : 19200
        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  Max W   ReadBack
          ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- --- -- ---------
          eeprom        65    10     8    0 no       4096    8      0  9000  90 00 0x00 0x00
          flash         65    10   256    0 yes    262144  256   1024  4500  45 00 0x00 0x00
          lfuse          0     0     0    0 no          1    0      0  9000  90 00 0x00 0x00
          hfuse          0     0     0    0 no          1    0      0  9000  90 00 0x00 0x00
          efuse          0     0     0    0 no          1    0      0  9000  90 00 0x00 0x00
          lock           0     0     0    0 no          1    0      0  9000  90 00 0x00 0x00
          calibration    0     0     0    0 no          1    0      0     0    0    0x00 0x00
          signature      0     0     0    0 no          3    0      0     00       0x00 0x00
        Programmer Type : STK500
        Description     : Atmel AVR ISP
        Hardware Version: 2
        Firmware Version: 1.18
        Topcard         : Unknown
        Vtarget         : 0.0 V
        Varef           : 0.0 V
        Oscillator      : Off
        SCK period      : 0.1 us
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.13s
avrdude: Device signature = 0x1e9801
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as D0
avrdude: safemode: efuse reads as FD
avrdude: current erase-rewrite cycle count is 1191250039 (if being tracked)
avrdude: erasing chip
avrdude: reading input file "Arduino-usbserial-mega.hex"
avrdude: input file Arduino-usbserial-mega.hex auto detected as raw binary
avrdude: writing flash (65096 bytes):
Writing | ################################################## | 100% 63.13s
avrdude: 65096 bytes of flash written
avrdude: verifying flash memory against Arduino-usbserial-mega.hex:
avrdude: load data flash data from input file Arduino-usbserial-mega.hex:
avrdude: input file Arduino-usbserial-mega.hex auto detected as raw binary
avrdude: input file Arduino-usbserial-mega.hex contains 65096 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 55.05s
avrdude: verifying ...
avrdude: 65096 bytes of flash verified
avrdude: reading input file "0xCF"
avrdude: writing lock (1 bytes):
Writing |                                                    | 0% 0.00s ***failed;
Writing | ################################################## | 100% 0.36s
avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0xCF:
avrdude: load data lock data from input file 0xCF:
avrdude: input file 0xCF contains 1 bytes
avrdude: reading on-chip lock data:
Reading | ################################################## | 100% 0.03s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
        0xcf != 0x0f
avrdude: verification error; content mismatch
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as D0
avrdude: safemode: efuse reads as FD
avrdude: safemode: Fuses OK

This seems to have had an error in writing, right from the start of the code. I tried again, on the same PC, same result. I'm not sure if I should be writing fuse values as well, http://arduino.cc/forum/index.php/topic,52544.0.html this person seems to not have, and they also seem to have had an issue with the same verification error; I'll have to try a different PC I suppose.

Now when I plug in my bricked mega, it is still not detected, and the L (pin 13) light no longer turns on at all. I assume that was the bootloader that turned it on? So it seems my mega is more lifeless than before now that I've uploaded garbled code smiley. Also, it's still not detected in DFU mode. I'll probably get a programmer and try again with that sometime later, since there was a possible issue with using ArduinoISP to program atmega2560's.

I am a bit confused that I can upload successfully to the 8u2 (indicating that it's alive), but the board isn't detected. It almost seems like there's a broken trace to the actual USB connector.

I hope this speil helps people who's arduino's arent as broken as mine and just need new firmware smiley I'll probably write up a more concise version later with a troubleshooting section for how to upload via ICSP to the 8u2 and the atmega2560.
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 20
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Just a note that the verification error shows up for both Blink and the bootloader uploads:
 
> avrdude -p m2560 -P com4 -c avrisp -b 19200 -v -e -U flash:w:Blink.cpp.hex -U lock:w:0xCF:m
  avrdude: Verification error.

> avrdude -p m2560 -P com4 -c avrisp -b 19200 -v -e -U flash:w:stk500boot_v2_mega2560.hex -U lock:w:0xCF:m
  avrdude: verification error.

Cheers!

Edit: Just noticed that pin13 LED is flashing when the board is powered, since loading the bootloader.. So it's possible that I can use the chip via ICSP programmer, without the USB working. Will look into this further, since it didnt seem to flash with just the Blink sketch uploaded.
« Last Edit: April 16, 2011, 02:35:13 am by CBlair » Logged

Forum Administrator
Cambridge, MA
Offline Offline
Faraday Member
*****
Karma: 12
Posts: 3538
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

So you can reflash the 8U2 but it's still not detected when you connect it to the computer?  You don't have the HWB solder jumper on the back of the board connected, do you?  Or is it possible that the 8U2 reset pin is being tied to ground (e.g. stray solder on its ISP header)? 
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 20
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Yeah, seems to be the case, avrdude would have shown an error if flashing failed(??). Unless I have the wrong file? I used MEGA-dfu_and_usbserial_combined.hex off of github

Interesting.

No jumper, HWB and ground on the back of the board show 2.9 volts, high impedance. On my healthy mega this is 4.8V. Problem?

Other things look fine.

Measuring the resistance on the 8u2 ISP pads themselves, between reset and ground, shows kiliOhm impedance. Voltage of the reset pin is 4.71 V with the Arduino's reset button held, and 4.68 without it held (this is the same for my healthy mega). With my voltmeter on a continuity setting its showing a short between reset and ground though (I feel this is a factor of my voltmeter though, it doesn't make sense to me there would be 5V difference if it was shorted? and the same thing happens on my healthy mega).

I went and poked around the board a bit with the voltmeter:
- The solder jumper labelled RESET-EN beside the capacitors is showing 0V and 10 ohms, same for healthy mega.
- The unlabelled solder jumper under the USB B connector is showing 0V and 10 ohms, same for healthy mega.
- 8u2 crystal is showing 0.1V, 2560 crystal 0V (and I'm not seeing anything oscillating on my 20MHz scope... though I would not be surprised if my strategy of poking wires attached to my aligator-clip BNC connector onto the crystal pads failed to properly measure)
- PCB pins are connected to USB-B connector's internal friction pins
- I measure 36 to 400 ohm resistance from USB D+ (bottom left when looking into it) to end of the 220R closest to the MADE IN ITALY stamp on the 8u2 side, the resistance varies if I move it around, usually settles around 70.
- 36 ohm from USB D- (top left when looking into it) to the other end of the 220R
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 29
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Try to program the 2560 chip itself on Arduino IDE
-before of all initalize serial at 57600 on a sketch on the working arduino
-conect TX and RX of the working on RX and TX of that dont work
-solder or add a piece of wire on the reset-en pins of the working to avoid auto reset(a piece of wire is good because you dont need to desolder the pads after and its only for a few seconds)
-Now, try to upload any sketch (blink is good for testing);
-click on upload
-when the code is complied (Shows up "Binary sketch size "xxxxBytes")
-quick press reset on the dead arduino

If the upload was suceful and the dead arduino recivied the sketch, ther problem is the usb-to-serial atmega8u2. buy a usb serial converter (like FTDI basic on sparkfun), and conect TX,RX to RX,TX and DTR to RESET, and you have a "semi working" arduino mega.

« Last Edit: April 20, 2011, 08:24:07 pm by Luigi_xp » Logged

Forum Administrator
Cambridge, MA
Offline Offline
Faraday Member
*****
Karma: 12
Posts: 3538
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

If the board never worked, you can return it for a refund or replacement.  It sounds like this is some sort of hardware failure.  Sorry that you ran into it!
Logged

Pages: [1]   Go Up
Jump to: