Go Down

Topic: UNO R3 and Ethernet Sheild R3 (Read 1 time) 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.


Thank you for all the help.   I received my chips yesterday.   The first thing I did was burn the bootloader to the bad chips using the application you recommended.   I was able to successfully write to the bad chips, but did not fix them as confirmed with the hardware test I mentioned.   The next thing I did was try to burn the bootloader to the new chips but I was getting verification errors  (200-350 errors).  I also tried using only a proto board for the chips w/ control sigs from one Arduino to the proto board and utilizing the clock on D9.   No luck there either... meaning I got the same results.   After pulling my hair out for an hour, I used the Arduino ISP sketch and that worked.  I then used the ISP you mentioned to verify the bootloader - that ran successfully with no errors.  Finally, I used the hardware test on the new chips and every thing is fixed now!   You guys rock!   Thanks for all the encouragement and help.   


Go Up

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

via Egeo 16
Torino, 10131