Pages: [1] 2 3 4   Go Down
Author Topic: Driving Mega2560 from external 5V bricks USB port  (Read 10052 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Jr. Member
**
Karma: 1
Posts: 58
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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?

Logged

Miramar Beach, Florida
Offline Offline
Faraday Member
**
Karma: 149
Posts: 6117
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.  smiley-eek
« Last Edit: December 08, 2011, 08:49:00 am by SurferTim » Logged

Miramar Beach, Florida
Offline Offline
Faraday Member
**
Karma: 149
Posts: 6117
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Offline Offline
Jr. Member
**
Karma: 1
Posts: 58
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Washington
Offline Offline
God Member
*****
Karma: 38
Posts: 804
Firefox & Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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. 
Logged

Avoid throwing electronics out as you or someone else might need them for parts or use.
Solid state rectifiers are the only REAL rectifiers.
Resistors for LEDS!

Miramar Beach, Florida
Offline Offline
Faraday Member
**
Karma: 149
Posts: 6117
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
« Last Edit: December 11, 2011, 08:18:58 am by SurferTim » Logged

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

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?
« Last Edit: March 28, 2012, 07:58:36 pm by kurt6string » Logged

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

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.
« Last Edit: March 29, 2012, 09:02:41 pm by kurt6string » Logged

Washington
Offline Offline
God Member
*****
Karma: 38
Posts: 804
Firefox & Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Avoid throwing electronics out as you or someone else might need them for parts or use.
Solid state rectifiers are the only REAL rectifiers.
Resistors for LEDS!

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

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.
 
« Last Edit: March 29, 2012, 11:39:38 pm by kurt6string » Logged

Washington
Offline Offline
God Member
*****
Karma: 38
Posts: 804
Firefox & Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
http://arduino.cc/en/Hacking/DFUProgramming8U2
Quote

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?
Quote
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.
Quote
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?
Logged

Avoid throwing electronics out as you or someone else might need them for parts or use.
Solid state rectifiers are the only REAL rectifiers.
Resistors for LEDS!

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

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...
Logged

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

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
« Last Edit: April 02, 2012, 09:23:07 pm by kurt6string » Logged

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

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...
Logged

Austin, TX
Offline Offline
God Member
*****
Karma: 12
Posts: 524
carpe diem
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Pages: [1] 2 3 4   Go Up
Jump to: