Go Down

Topic: UNO R3 and Ethernet Sheild R3 (Read 492 times) previous topic - next topic


Hi all.   I'm thinking this is the best place to post though my problem might be caused by my circuit.    I'm on my second UNO and I think I blew pins again on this board.   I observe that digIN pin 5 connected to a switch with a 15k pull down causes an unconnected Pin4 (dig IN) to follow pin 5, as viewed on the oscope.   I also seem to have done the same to Pin3 now (pin 3 DigOut is now affected by pin 5).     Pin 3 was connected to a relay with 28mA coil draw.   My questions are:  can failed pins be corrected with a new boot loader and can simply replace the ATMEGA328?   I'm still not sure what I'm doing wrong with my circuit, but I though I'd start here with getting the UNO back up and running.  One more question but maybe in the wrong forum, would it be normal practice to place a fast blow 40mA fuse on the inputs to prevent further issues?    Thanks in advance for any assistance.


Feb 07, 2013, 03:40 am Last Edit: Feb 07, 2013, 03:53 am by Coding Badly Reason: 1
Either it was a really dumb set of questions or I'm in the wrong thread.   I thought I follow up for anyone else who has similar issues since I found no other related topics.   I used this gentleman's stuff to test both boards and yep, they're both shot ... or at least the atmega is.   (http://arduino.cc/forum/index.php/topic,50203.0.html).    Thanks to him for his very helpful post.   (I did need to update the LED.h which called Wprogram.h rather than Arduino.h).   Pretty slick stuff.   Then I tried reflashing one of the boards with no change.  Tomorrow I will receive new chips and I expect that will solve my issue.    I also think I found the cause of my problem which was something I was interfacing to on a DigIN port.   Though the vendor said the equipment was a 'dry-contact', my suspicion is that it's using a circuit to emulate a relay since I can look into the circuit and measure a resistance.    Either way, I hope something here might be helpful to someone.  


I'm on my second UNO and I think I blew pins again on this board.

So, do you have a working UNO?  If you do, you can try to bootload it:

The first handy thing the sketch does is identify the chip and the fuse settings.  You can also connect to the ATmega 8/16u2 header to see if your USB2TTL is pooched as well.  If the ATmega 8/16u2 got zapped, it is a little more difficult to recover since the ATmega Board Programmer is not setup to upload the firmware for that chip.  It will need to be done through AVRDUDE.

I would start there before the test shield.


Thank you for the reply.   Well, I have two boards which do communicate to the PC via USB but have failed digital/analog points.   I am able to upload sketches to both which is how I ran that test sketch on the test circuit.   I was also able to use one board as a programmer to the other (I needed to add a cap to the the programmer board - grnd to reset).   That ran successfully, but did not change the state of the board.    I hoped to get my new Atmega328s today, but they aren't scheduled for delivery until tomorrow; wishful thinking on my part for today.   

Thank you for the link too.  I will use it to further test the chips I think are bad.   Just to be sure, I intend to use http://arduino.cc/en/Tutorial/ArduinoISP on my new chips.  Is your post suggesting that I would better test my failed chip(s) with your sketch or do I need to use your sketch to properly burn the new chips as well?     Thanks again for your response.


I use the Atmega Board Programmer all day long and it works beautifully.  Success with non-bootloaded chips on the Arduino as ISP is less than half, unless you have a 1 MHz signal to XTAL1.  If you use Nick's programmer, all you need is a jumper from the programmer board D9 to get the 8 MHz signal that works perfectly.  Also, it uses the same Optiboot and it has a 8MHz internal (Lilypad) and it will program the bootloader for the 328P, 1284P, 2560, 1280.

Anyhow, if you have an Uno that you can upload to and D13-D10 (Port B) operating, try the Atmega Board Programmer on the other board D13-D11 and Reset.  Then open the serial monitor @ 115200 and see if you can recover with a bootloader install.  What is interesting is the UART (Communications for programming) is on PORTD (D0-D7) as well as you D3 and D5 but they seem to work.

Go Up