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