Driving Mega2560 from external 5V bricks USB port

I have an application that wants to use the extended ports and processing power of the Mega2560. Basically the Mega plugs into a backplane where it can have more than one shield , as well as other circuits that plug into the backplane by card slots.

So far, this arrangement works well. But if I power the backplane by way of the 5V supply on the Mega, there is less than 500mA available, which is not enough for some of my additional TTL circuits. I have been supplying 5V for the backplane and the Mega from an external supply. This works fine until I plug a USB cable into the Mega for programming. At that point there is 5V from the external supply on the Mega's 5V pin ( I am not using the Vin pin ) and 5V from the USB port. This works for about a day, then the Mega's USB port will brick. ( I went through 3 Megas before I figured this out. Ouch).The difference in voltage between the 5V supply and the USB port is from zero up to 100mv.

What I think I am going to have to do is adjust my external supply from 5V to 9V and apply it to the Vin pin. That way the internal power switch on the Mega should switch safely between external and USB power. I will then have to provide an additional 5V supply for any additional TTL.

Will this work or am I missing something here?

Thanks for that tip!! I was about to do the same thing. I would have been unhappy.

I would use the onboard regulator if it wasn't such a crappy, underrated, linear "POS".

Edit: I guess nobody that builds these got far enough in the voltage regulator datasheets to find this:
http://www.national.com/mpf/LM/LM2595.html

My second remark above is a little harsh. I did not mean that as derogatory as it appears. The regulator is fine for a Mega with no shield and a supply voltage less than 10v.

But my Mega with an ethernet shield and a power supply of 9v, and in just a few seconds, the regulator is too hot to touch. At 13 volt supply (minimum automotive) it would get twice as hot. :astonished:

Is it possible you blew the 500ma fuse on the usb power input? Since you have a couple bad boards, can you try connecting one the bad boards and check the voltage on the fuse. It appears to be the gold colored smd marked "500J" next to the usb port. See if you have 5v on each side of that. If not, the usb port will not get power. According to the schematic, that is the only way the usb chip gets power.

I used the usb case as ground for the volt check.

If it is blown, it appears you could "jump" that fuse with a second fuse.

SurferTim, Thanks for the response. Fuses look good. Both boards I tested are obviously getting power from USB; LEDs are on. One is recognized by XP device manager, but cannot communicate on TX/RX. The other cannot be recognized as a USB device. Both Mega's when powered up run the last sketch uploaded.

I do not see how using two power sources should damage the arduino. The difference between a regulated 5v power supply and the USB port should be minimal and not harmful.

smeezekitty:
I do not see how using two power sources should damage the arduino. The difference between a regulated 5v power supply and the USB port should be minimal and not harmful.

Do you have a Mega powered by 5v and the usb power supply and it does ok?
Is it guaranteed enough to be covered under the Arduino warranty if I try it?

Add: The schematic shows the fet T2 (lower right in schematic) connects the usb power supply and the 5v rail. The fet is controlled by Vin, not +5v. If Vin is less than 6.6v, the fet gate is low. I wonder what that does if the 5v rail is powered directly, rather than by the regulator from Vin?

Another thing about the schematic that concerns me. The IC5B next to it uses Vin as a comparator input to a LM358 powered by 5v. If Vin is higher than 10v, you are overdriving the IC5B positive input.

I can confirm this problem, as I too just fried the usb ports on three mega's, doing the exact same thing. And since it doesn't happen immediately upon plugging in both power supplies you get fooled into thinking you must have done something else wrong, thus you plug in another mega, it works, for awhile, then stops talking, and about this time you've got suspicions, but you're obligated to plug in and kill a third one to confirm it....ouch is right.

Here's the link to my post for what it's worth.
http://arduino.cc/forum/index.php/topic,98728.0.html

Does anybody involved in the mega r3's design have any thoughts on what's going on here?

I have now encountered a 4'th mega r3 that is encountering usb communication difficulties - and I'm about 99.9% certain I have NEVER plugged this one into two power supplies - only the usb power. The trouble began with seeing 'garble' when the mega was reset, my sketch should print 'status' to the serial port upon reset and 'sometimes' it was garbled. Huh...Maybe just trash on the line I thought. But then, when I pushed the reset button it began not writing to the serial port at all sometimes. I'd have to close the arduino ide's comm window, unplug/replug the usb cable back in, reopen the comm window, and then upon reset could get it to speak on an intermittent basis. Sometimes it would stop talking after 5 resets, sometimes after 3 resets, one one round I got all the way to 24 resets before it stopped talking.

At that point I moved from the macintosh over to the pc and found the exact same symptoms (ocasional garble, and dying after some low number of resets).

At that point I grabbed a mega rev2, loaded the exact same software onto it, and it works perfectly.
I went back to the mega rev3, reloaded the software - and it's intermittent, and it got worse the longer it was on. It looks to me like I'm catching the beginnings of a usb controller chip failure.

So, it's beginning to look like a bad batch of mega rev 3, or a design flaw, one or the other, to me. I'll be working on the mega rev2 all day and tomorrow, and will keep it continuously powered up and will report back later.

kurt6string:
I have now encountered a 4'th mega r3 that is encountering usb communication difficulties - and I'm about 99.9% certain I have NEVER plugged this one into two power supplies - only the usb power. The trouble began with seeing 'garble' when the mega was reset, my sketch should print 'status' to the serial port upon reset and 'sometimes' it was garbled. Huh...Maybe just trash on the line I thought. But then, when I pushed the reset button it began not writing to the serial port at all sometimes. I'd have to close the arduino ide's comm window, unplug/replug the usb cable back in, reopen the comm window, and then upon reset could get it to speak on an intermittent basis. Sometimes it would stop talking after 5 resets, sometimes after 3 resets, one one round I got all the way to 24 resets before it stopped talking.

At that point I moved from the macintosh over to the pc and found the exact same symptoms (ocasional garble, and dying after some low number of resets).

At that point I grabbed a mega rev2, loaded the exact same software onto it, and it works perfectly.
I went back to the mega rev3, reloaded the software - and it's intermittent, and it got worse the longer it was on. It looks to me like I'm catching the beginnings of a usb controller chip failure.

So, it's beginning to look like a bad batch of mega rev 3, or a design flaw, one or the other, to me. I'll be working on the mega rev2 all day and tomorrow, and will keep it continuously powered up and will report back later.

Usually digital chips do not go intermittent (they can but usually dont).
Make sure the USB cable is good, may sure nothing is connected to pins 0 & 1. If that fails, you can try reloading the firmware on the 8U2.

It's not the cable, tried two, and nothing at all was connected to the board except the usb cable during the tests - no shields, nothing. I've got an AVRISP MKII and would love to know how to rewrite the firmware onto the 8u2 just to see if it can a) revive the three that had been plugged into two power supplies and b) to see if it helps the one that's become unstable.

Do you know where I can find instructions for reloading the 8u2's firmware? I looked for that info but failed to find it when the boards began going bad.

Regarding "Usually digital chips do not go intermittent (they can but usually dont)" - I understand and agree but that's what appears to be happening. But something weird is happening that's for sure. In the case where the boards were plugged into the two power supplies it doesn't make sense that the 8u2's would be damaged when the processor wasn't, unless it's the size of the chips? The 8u2's are a lot smaller and if something bad was happening in power supply land then their smaller size might have dissipated less heat? And caused them to self-destruct before the processor did?

There are mysteries here folks. Could the the design team of the mega r3 please run some tests using dual supplies or talk about the circuit theory issues that are relevant here please?

The power supply I used was an OKI-78SR 5v dc-dc regulator being powered by a wall wart 12vdc power supply which measured about 16vdc unloaded, and about 15v when plugged into the arduino/shield stack.

And while I've got your ear, could someone please fix the broken eagle file .zip download so I can see exactly where things are going on the board please? (The .zip downloads is corrupted and neither a mac or a pc can open the download)

Thanks.

kurt6string:
Do you know where I can find instructions for reloading the 8u2's firmware? I looked for that info but failed to find it when the boards began going bad.

Regarding "Usually digital chips do not go intermittent (they can but usually dont)" - I understand and agree but that's what appears to be happening. But something weird is happening that's for sure. In the case where the boards were plugged into the two power supplies it doesn't make sense that the 8u2's would be damaged when the processor wasn't, unless it's the size of the chips? The 8u2's are a lot smaller and if something bad was happening in power supply land then their smaller size might have dissipated less heat? And caused them to self-destruct before the processor did?

What about cold solder joints or a fried trace from the voltage differential?

There are mysteries here folks. Could the the design team of the mega r3 please run some tests using dual supplies or talk about the circuit theory issues that are relevant here please?

Unfortunately the design team is usually not all that receptive.

The power supply I used was an OKI-78SR 5v dc-dc regulator being powered by a wall wart 12vdc power supply which measured about 16vdc unloaded, and about 15v when plugged into the arduino/shield stack.

Did you test the regulator output loaded and unloaded to make sure it never exceeds 5.5v?

Aloha, thanks for the help, and I'll check the items you mentioned as soon as I can and report back, working against a software deadline at the moment...

Hi Folks, I need some crystal clear, can't fail instructions. I've got several mega's whose usb ports are not recognized anymore. So I decided to try reloading the firmware onto the 16u2 on the mega r3. The instructions available, from various sources conflict with each other, or don't specifically address EXACTLY what to do, in EXACTLY what sequence. What I have managed to do is to brick one of my remaining good mega's such that it's serial port no longer appears.

What I did (that bricked my mega) is to plug an avrispmkii into the icsp socket in the corner of the board, next to the 16u2 and then did the following from avrdude, according to the instruction in the firmware section of github, which didn't work and had to be modified to use the correct hex file name, and reference the avrdude config file:

/Applications/Dev/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude -C /Applications/Dev/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -p at90usb82 -F -P usb -c avrispmkii -U flash:w:Arduino-COMBINED-dfu-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

And here, is what avrdude told me, note that the device signature is not what it was expecting....


avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9489
avrdude: Expected signature for AT90USB82 is 1E 93 82
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "Arduino-COMBINED-dfu-usbserial-atmega16u2-Mega2560-Rev3.hex"
avrdude: input file Arduino-COMBINED-dfu-usbserial-atmega16u2-Mega2560-Rev3.hex auto detected as raw binary
avrdude: writing flash (8192 bytes):

Writing | ################################################## | 100% 2.53s

avrdude: 8192 bytes of flash written
avrdude: verifying flash memory against Arduino-COMBINED-dfu-usbserial-atmega16u2-Mega2560-Rev3.hex:
avrdude: load data flash data from input file Arduino-COMBINED-dfu-usbserial-atmega16u2-Mega2560-Rev3.hex:
avrdude: input file Arduino-COMBINED-dfu-usbserial-atmega16u2-Mega2560-Rev3.hex auto detected as raw binary
avrdude: input file Arduino-COMBINED-dfu-usbserial-atmega16u2-Mega2560-Rev3.hex contains 8192 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 2.34s

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

Writing | ################################################## | 100% 0.00s

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.00s

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

Writing | ################################################## | 100% 0.00s

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.00s

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

Writing | ################################################## | 100% 0.00s

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.00s

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

Writing | ################################################## | 100% 0.01s

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.00s

avrdude: verifying ...
avrdude: 1 bytes of lock verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.

Again, this bricked the mega.

My question is this, does anybody know EXACTLY what to do, in EXACTLY what sequence, omitting no steps (including where to plugin the programmer, as all the instructions I've seen assume you already know this, and yet to an experienced developer who's diving into this level of the arduino (reluctantly) - it's not so clear).

How do you do a total and complete factory level restore to an arduino mega rev3 ?

Frustrated, (but grateful for help I've received so far),
Kurt

The really frustrating part about this is that I know if you have the right files to burn, and the correct abra-cadbra spells to invoke that this 'reload' everything is a 5 minute procedure, and so far I bet I've burned up 6-8 hours over the last couple of days trying to find the correct magic spells to no avail...

I think you want to use at90usb162 instead of at90usb82 if you are trying to program a atmega16u2 part.

After another hour of experimentation I found something that worked:

The following instructions are for Macintosh/osX (Lion), with the Arduino IDE 1.0.0 installed in the applications folder.

  1. Plugin a usb cable to the arduino mega rev3 in order to supply it with power.

  2. Plugin an avrispmkII programmer into the 6 pin icsp1 jack located adjacent to the usb connector (observe pin1 orientation via the dot on the board).

  3. Open a terminal window, paste in the following command and execute it:

/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude -C /Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -p m16u2 -F -P usb -c avrispmkii -U flash:w:/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/firmwares/Arduino-COMBINED-dfu-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

  1. Unplug both the programmer and the usb cable, then plug the usb cable in and the mac (and the pc) should recognize the usb port as long as the arduino mega rev 3 is KNOWN TO BE GOOD.

Note that I had to alter the '-p' device code to 'm16u2', AND I had to use the .hex file that was contained in the arduino IDE's firmwares folder which was 21kb - The one I downloaded from git hub was 93kb, I have no idea why, but I do know that the instructions above work for me.

NOTE THAT THESE INSTRUCTIONS DID NOT REPAIR THE BOARDS THAT I THOUGHT WERE DAMAGED HOWEVER.

In one case the programmer indicated there were verify errors and did not restore the dead board.
In another case the programmer indicated the burn was successful but again did not restore the board.

The reprogramming only worked on the board that I bricked by apparently erasing the 16u2, or uploaded bad firmware.

Thus it still appears to me that I have 3 dead mega's and no clue as to WHY they're dead. Per-the-above-help, I have verified that the external regulator puts out a nice steady 4.98 volts both loaded, and unloaded and ripple is within the OKI-78's specifications.

Anybody have any other thoughts on the matter?

kurt6string:
In one case the programmer indicated there were verify errors and did not restore the dead board.
In another case the programmer indicated the burn was successful but again did not restore the board.

I find usually verification errors are not caused by a bad chip although they can be.
If the programmer indicated that the burn was successful, it is highly likely that the chip is ok.
I do not know why the USB port would not show up but it seems like in atleast the second case, the chip is likely still good.
At this point, I am totally confused.

I'm confused too! - But I'll retry the one that didn't have verify errors just to make sure, I'll report back on that. Thanks.

I just retried the 16u2 firmware reloads on two of the arduino mega rev 3's - one reports the burn was ok, one reports verification errors, and neither can be recognized. I don't think there's anything left to try....

Regarding my suspicion that simultaneously providing both usb power and external power to a mega2560 can damage the 16u2 (usb controller chip) I am now removing transistor T2 from the mega2560. This transistor is what allows usb power to be connected to the 5vdc bus. Removing it totally prevents usb power from being used.

Note that you cannot just clip the 5vdc wire (or an unpowered hub I think) because the usb power is applied to the 16u2 and is used to power an internal component which is used to provide power to the data lines. I tried this first, and it resulted in very very shaky usb connections. Sometimes it would connect, most times it wouldn't.

But removing T2 removes usb power from the 5vdc bus AND yet still allows usb communications to work properly.

to be continued...