Pin overvoltage

I made a mistake and put 12 voltages dc right to one of the IO pins on an Arduino Uno. My question is did i damage the whole board or do i just need got get a new atmel chip. The 12 volts was only applied for a a second or so max. The usb controller still shows up when i plug my Arduino board into my computer but goes right to DFU mode.

Remove the ATmega328. If you can reprogram the ATmega8u2 then the rest of the board is salvageable.

If you're using the standard jumper wires with male pin on the end to make connections to the
board headers, you might take a bunch of them, cut them in half, and solder a small value resistor
in the leads, 220 to 330 ohms. Put some tape or tubing over the connections to isolate the bare
connections. Goes a long way towards protecting I/O pins from overvoltage and short-circuits.

If you short one of the IO pins for just a short while what are the changes that the rest of the board has been damaged? I haven't bought a new ATmega8u2 chip yet.

oric_dan(333):
If you're using the standard jumper wires with male pin on the end to make connections to the
board headers, you might take a bunch of them, cut them in half, and solder a small value resistor
in the leads, 220 to 330 ohms. Put some tape or tubing over the connections to isolate the bare
connections. Goes a long way towards protecting I/O pins from overvoltage and short-circuits.

I'll keep that in mind. I just happened to make a dumb wiring mistake.

co2shaun:
I'll keep that in mind. I just happened to make a dumb wiring mistake.

Compared to smart wiring mistakes? :wink:

I'll keep that in mind. I just happened to make a dumb wiring mistake.

The probability of making a 'dumb' wiring mistake increases with the #of bare copper
points one has on a board - unfortunately boards have nothing but bare copper
points. Too easy to "accidentally" short out everything when you're putting systems
together.

Sometimes, this kind of mistake is just that - a mistake, no getting around it. I would suggest though, that sometimes, this mistake is more the result of lack of lack of planning in the design and assembling of a project, most especially non-trivial ones.

  1. Power should be the -last- thing connected, and the first thing disconnected, when working with the project.

  2. Free-hand probing with test equipment should not be done, if possible, while a device is under power; if necessary, then extreme care should be taken, and only a single probe used, with the free-hand not holding a probe placed in a pocket or otherwise restrained from wandering near the other probe or the chassis of the project.

  3. If test equipment needs to be used, then the project should be powered off, the test equipment attached, then the project re-powered.

  4. Before (re-) applying power, all connections which have been changed or added should be triple inspected to verify that no shorts or opens, or other changes, have occurred.

  5. A project should begin with a design, ideally a drawn schematic. This schematic (actually, a copy of the original schematic) should be referenced to construct the physical design. Test points should be identified and noted early in the schematic for future probing needs.

  6. Using a defined layout and color-coding scheme for power, ground and signal busses, as well as identifying test points, when prototyping on a breadboard, can be extremely helpful (though time consuming); granted, this generally precludes the use of any currently sold "jumper wires", as they tend to be color coded by length.

  7. Marking power busses with voltage levels (using a marker or other means) can be helpful as well; this, used in combination with an identifiable color code for voltages (common is black for ground, red for 5 volts, yellow for 12 volts, which is from PC power supplies), can help prevent mistakes.

  8. If your breadboards have power busses that can be separated from the board, doing so can also help prevent problems (mount everything on a non-conductive backer-board of wood or plastic, using double-stick tape or other means).

  9. As you construct the project from your schematic, mark off the connection on the schematic using a highlighter or felt marker of the same or similar color as your wire color-coding scheme. This does two things: a) it notes you have made the connection, b) you can reference the color to your wiring at a later point to verify that things match as you change them. If changes are made, the color coding should be changed to reflect this (I realize that this would become unwieldy on very large designs).

I'm sure more could be added to the above list; I'm also sure much could be changed or updated to reflect different design realities (and if you have suggestions, please post them). Ultimately, though, reducing the potential for mistakes involves careful planning, meticulous up-front design, and lots of documentation before, during, and after implementation. It is the bane of any electronics project, but also tends to be the marker of successful projects.

This same kind of attention to process and design should be applied to software as well, but it too seems to suffer the same lack of attention, as any experienced veteran of software development can relate (take heed).