I'm not sure what went wrong with my Uno, but all of a sudden, when I upload a new test sketch over the current Blink sketch, the new sketch runs as it should, but once I remove power and reapply power, the Blink program is there, but not the one I uploaded over it.
Does this ring any bells for anyone? I am clueless.
Joe
Update: It has to do with the board, I changed the chip socket to one of a better quality. Now for the surprise that puzzled me even more.
I tried the program on another Uno I have and it retained the new program. So I removed the chip and swapped it with the one on the other board, and when I powered it up, it had Blink running on it, not the new program that ran my servo. So then I removed that chip and put it back the the Uno it came from, and low and behold, it was running the new program, not Blink. So there must be a short on the board I soldered on, even though it is not visible. What puzzles me, is that I always thought that writing a new program, would over write the old one. That contradicts the fact that both chips run the servo program when put in the good Uno board, and run the Blink program when put in the bad Uno board. The bad Uno board will run any new sketch until power is removed, then when power is reapplied, it reverts back to Blink, If I then take that chip and put it in to the good Uno board, it runs the new program, not Blink.
Wow, someone please explain this so it all makes sense, please.
When you reset an Uno (and most other Arduino boards) the bootloader runs for a second or two. On the Uno, this is signified by a fast triple blink. After this, the code you uploaded should run.
(note - your wording is ambiguous, so it's a little unclear whether you're saying blink is there, instead of the program, or blink is there, but not the one you had before)
If you're actually uploading without errors, and the sketch isn't changing, that is bizzare, since the upload process includes verification! Are you sure you're not getting some sort of error?
Select File:Preferences, enable Verbose Outputs.
Then expand the bottom window of the IDE and copy/paste what it says, use code tags (the < /> button) when you post it.
I was going to turn on verbose, but my findings got more bizarre, both 328 chips run, and hold any sketch i put into them when in the good Uno board.
When those chips are put into the bad Uno board, they run Blink, and not what was written to them on the good board. If they are over written with another sketch on the bad board, it runs until power is removed, then the board goes back to running Blink.
Now, if I take the chip from the bad board, that is now running Blink in the bad board after power was reset, when the chip is moved to the good Uno board, it runs the new over written program for my servo test. Move it back to the bad board and it will run Blink until a new sketch is written, then the new sketch runs until power is reset and it goes back to Blink. But move it to the good uno board and it runs the new servo sketch.
I hope this all makes enough sense for someone who knows it all to explain it.
Oh, and this is all done on the same PC, with the same IDE doing all the programming.
If it is not running blink, then why does a new written program run perfectly until the power is removed? If it was not running a program, and really had some other reason to flash the LED, say a hardware problem, that would interfere with the other program that ran over it.At the very least it would flash the LED while running my servo test, but it does not, it runs the servo test as it should.
Is anyway a shorted pin, any pin, could cause this? Can anyone think of a way to make this happen if they wanted to mimic it?
It has to be about the board that I changed the socket on, so that involves a more probable short, than an open of some pin on the processor.
Checked all socket pins to Ground and Vcc and all looked correct except for pin 28, it was the odd ball, showed no resistance to either ground or Vcc, where all others showed something reasonable.
So if pin 28 were open, does that make any sense to anyone?
I will check the board under a magnification and heat the pin to see if it might have a solder problem,
Pin 28... Are you sure it's not pin 1? (ie, you were looking at it from the bottom and were on the opposite side of the chip)? Pin 1 is reset, and it should have a 10k resistor to vcc on it, and that could produce weird behavior, possibly what you're describing.
Pin 28 is SCL/A5, and should be connected to those.
And wait - testing the socket, with the chip removed, the IO pins (everything except reset, power, ground) should not be connected to vcc or gnd - they should all be open, and should be connected to the corresponding pin on the board.
(note - on the TQFP version, pin 28 is reset - but you're talking about moving chips around, so I assume you're working with the socketed version with the DIP package)
DrAzzy:
When you reset an Uno (and most other Arduino boards) the bootloader runs for a second or two. On the Uno, this is signified by a fast triple blink. After this, the code you uploaded should run.
(note - your wording is ambiguous, so it's a little unclear whether you're saying blink is there, instead of the program, or blink is there, but not the one you had before)
If you're actually uploading without errors, and the sketch isn't changing, that is bizzare, since the upload process includes verification! Are you sure you're not getting some sort of error?
Correction, what I described as Blink running is not accurate, the LED is flashing 3 flashes repeatedly.
So whatever is causing it is on the board, because the chip runs on the other uno board.
Somebody else was mentioning the 3 flashes when attaching a shield to his Uno, and Grumpy Mike had this to say:
Grumpy Mike: Yes it sounds like the shield is holding the serial input low and preventing the boot load from concluding nothing is trying to program it. Then when you inject some real serial data the bootloader sees that byte and realizes it is not being programmed and goes and executes the main sketch.
I would say this is a poorly designed shield. You could arrange a switch to isolate the serial lines from the shield while downloading. But better yet get back to the supplier of the shield and complain.and
Grumpy Mike was right, when I put the chip into the bad board and got the repeating 3 flashes, i opened a serial monitor window, and low and behold, the servo program started running.
So when Grumpy Mike refereed to the serial input pin, what pin was that? I will check it for a short, although that might not be how I can find it because of previous testing.
In 1.6.8 there's a bug with the IDE that causes it to continually poll the serial while the IDE is open, preventing the sketch from running (unless serial monitor is open).
In further troubleshooting I disconnected pin 1 and 2 from the circuit by cutting the socket pins off. so the pins of the 328 are hanging in free air. The board works as it should.
Now I have to figure what is either pulling , or pushing, or shorting one or both of those pins.
DrAzzy:
In 1.6.8 there's a bug with the IDE that causes it to continually poll the serial while the IDE is open, preventing the sketch from running (unless serial monitor is open).
Use 1.6.5r5 until they do a working release.
It must not effect all Arduino Uno's, because the other boards I have work without causing the same problem.