total current drain

Thanks for your message.

For what it's worth, my power draw came mainly from the 5V pins, not from any of the Atmel chip's pins. In other words, my problem -- if it is an overcurrent problem -- relates to the board, not to the chip. The 5V pins are closer to the voltage regulator than the fuse, but even so, I know that most voltage regulators overheat gracefully exactly as you describe, with or without fuses.

For all of that, this board has not failed gracefully at all. Even after it & I had cooled overnight, it is deeply dead, and it no longer accepts downloaded code. Curiously, and not altogether consistent with my power-supply theory, its red power LED works, even though nothing else does. Possibly its death was unrelated to the power I was drawing through it. It died after running a single app for 5 or 6 days.

The exact history of one Arduino's failure is not determinative of the merits of having more instrumentation hooks on a board that is meant for developers.

The exact history of one Arduino's failure is not determinative of the merits of having more instrumentation hooks on a board that is meant for developers.

I suppose that is correct. I would, however, also like to add that choosing a board with too small of a regulator in the first place, and burning it out does not necessitate an ECO.

Specs

5V regulator

Max 150mA output

Perhaps the full Arduino with the bigger MC332690-5.0 DPak Vreg would be a suggested option?

What's an ECO?

Engineering Change Order.

Typically in the field, we're not allowed to deviate from design. As soon as either us field techs, or engineering needs to make a change, an ECO is released. (If approved)

It's kind of the Adult version of getting permission to do something. Unless the ECO gets issued, nobody deviates from the design.

Once the ECO gets issues, everyone must adhere to the design.

At times someone will request an ECO to address an issue but all the other depts do not agree, and as such it will not get accepted into the design.

Kind of sucks when that happens - usually its because someone sees something of value that others do not perceive is of value.

If the power LED is working then your regulator is probably OK. You may have corrupted the bootloader when the overcurrent condition occurred. You could try to burn a new bootloader

This page has more on the bootloader: http://arduino.cc/en/Hacking/Bootloader?from=Main.Bootloader

And this shows how to build one using a few resistors and an old printer cable: http://arduino.cc/en/Hacking/ParallelProgrammer

Thanks. My pertinent background is software, not hardware, but there are exact analogies there. I don't need to be convinced that big projects can fail if changes are made without coordination. I just hadn't seen that acronym before.

I didn't think my problem "necessitated" an ECO, and certainly not the specific one I suggested. I was only drawing attention to a problem not likely to be unique, and I hoped only that the problem might be at least briefly contemplated by those directing the Arduino enterprise.

I thought about getting the big MC332690-5.0 DPak Vreg Arduino, but I prefer the bare-edged versions, so I can mount screw-clamping connector blocks on them (Digikey 277-1273-nd and the like). With more than a few connections in place, the combination of breadboard wires and headers is, for me, a never-ending struggle to replace wires that have jostled out. Headers are cheap, but I feel guilty when the first thing I do with a product is to pull out my solder wick and scrap the built-in headers.

Also, the bigger regulator is a quantitative change, but not a qualitative one. Probably my specific application would be taken care of by the larger vreg, but then someone will come along with an even more power-hungry app. Or not: after developing an application on the big Arduino, he might for reasons of economy want to know -- without doing the experiment -- if it could be implemented with lesser hardware. On-board instrumentation hooks would now & then be useful even if the product were some sort of gigaArduino with a 10A Vcc bus.

Robert, why do you think the regulator is the problem? It would appear to be working if the power LED is on.

All I know for certain is that

  • the board was working away for 130 straight hours or so, and then stopped dead;
  • in hindsight, the load I was putting on the 5V supply may have been excessive; and
  • the board is now completely unresponsive.

I tried to think of a failure mode that- disabled pretty much the whole board and - might have been slowly brought about by overdrawing current from a point proximal to the Atmel chip
and power-train failure was the only thing that seemed likely. I agree that the functioning power LED suggests, exactly opposite to my theory, that perhaps the power supply is the only part of the board that's working. I'm not happy with the diagnosis, but it is the best I can do.

I have now swapped in another Arduino board, just long enough to see that it works, but now I have removed it to keep it from being destroyed as the first one was. I am re-implementing the app to make use of an off-board 5V supply.

Robert, there are only two active components on your board, the regulator and the controller chip. The regulator drives the LED so that is probably working. If you are not getting a response from the controller chip then it is likely that the problem is related to that.
Because your chip is not easily replaced, your remedial action is limited but there is a chance that the bootloader got corrupted when the overcurrent occurred, and if so this can be fixed using the information I posted above.

Most 7805 type regulators are self protecting for over current or over temperature, they simply shut down until the load problem is corrected. I think you will have to look farther for your problem.

I have you tried the 'loop back' trick to check out the USB serial FTDI chip? Simply wire a jumper from ground to the reset pin and then another jumper from pin1 and pin0. When you plug in to your PC's USB it should see the device and if so then you can launch the Arduino IDE and then select the serial monitor, what you type on the keyboard should be echoed back to the serial monitor receive window. If this fails then you have a problem not easy to fix. If it does work then the next thing to try is to reburn the Arduino bootloader into the AVR chip with a programmer.

Lefty

have you tried the 'loop back' trick to check out the USB serial FTDI chip? Simply wire a jumper from ground to the reset pin and then another jumper from pin1 and pin0. When you plug in to your PC's USB it should see the device and if so then you can launch the Arduino IDE and then select the serial monitor, what you type on the keyboard should be echoed back to the serial monitor receive window.

That's a nice trick, and I'll remember it. Unfortunately, I used it and got no echo. The board is dead, except for its power LED. It might have value as a nightlight in a dollhouse, but that's about it.

There seems to be consensus here that this couldn't have been a vreg burnout, so I have to conclude that it was just a random deep failure.

One easy way to burn up the FTDI USB convertor chip is by misuse of the 3.3vdc pin on the Arduino connector. This regulated voltage comes directly from the FTDI chip and is limited to 50ma or less I think. Several users seemed to have fried their board using this voltage pin incorrectly, don't know if that relates to what you were doing but it's one possiblity.

Lefty

PS: it is possible if all that is wrong is the FTDI chip, is to use an external USB convertor module and wire it to pins 0 and 1 and power pins. Not sure it's worth the effort as they cost almost as much as some of the Arduino clone boards.

One easy way to burn up the FTDI USB convertor chip is by misuse of the 3.3vdc pin on the Arduino connector.

Good thought, and my app does have a 3.3V section, but it it is externally powered.

it is possible if all that is wrong is the FTDI chip, is to use an external USB convertor module and wire it to pins 0 and 1 and power pins

Another good thought, but my app was already doing its communicating through pins 0 & 1 (and an XBee module); I used the USB connection only for downloading & debugging.

Sorry to dig up this almost ancient topic, but I realized I'm having similar problems with some arduino pros ordered back in august.

These arduino pros are embedded into some interactive objects, and work without problems for weeks. then, all of a sudden, the device shuts down and becomes completely unresponsive. even reprogramming the bootloader with an isp programmer does not revive the chip. I've lost 3 boards so far.

I can't find problems in my wiring, so the only things im thinking of right now are:

  • brownout when shutting down (can this demolish the chip?)
  • overheating atmega (through overheating the regulator?)
  • overcurrent on i/o pins, they are not protected by a resistor

so, i'm wondering whether any of you recognise these symptoms. I can replace the faulty devices, but the problem seems to be coming back. So, when does the device actually fail from overheating? (That is, in your experience, i know the datasheet specs)

Mark,

Does your app happen to be putting stuff into the EEPROM on the chip? Most people forget that EEPROM can only support so many rewrites. Might be totally unrelated. But worth a look.

Cynar

Nope, EEPROM is not used in this application. But if it was used, would that mean the chip becomes totally unresponsive to anything?

So, when does the device actually fail from overheating?

When the silicon temperature exceeds the maximum. This is not case temperature.

In general for every 10C rise in temperature the expected life time of a semiconductor device half's.

  • brownout when shutting down (can this demolish the chip?) NO

  • overcurrent on i/o pins, they are not protected by a resistor Only if the design is wrong and then I would expect to see just the output pin go not the whole chip. I expect the chip is dead as it won't re program.

  • overheating atmega (through overheating the regulator?) one does not follow the other, an overheating regulator should just shut down. It can overheat the whole box but that depends on how the box is physically constructed. Do you have any air movement over the electronics?

If you have two boards, like you seem to have. You can check your cpu, if you take a cpu from a dead board and put it into a working board. If your regulator is bad, your new board will work with the old cpu.

At least on my Duemilanove board have a socket under the cpu.

.. not the pros... They are SMT