One Crazy Sketch

On a Uno, the problem does not occur.

What is your wiring, exactly? Maybe put a 0.1uF capacitor there for decoupling.

What is your wiring, exactly?

10K resistor from +5 to RESET. Pushbutton to ground so I can reset the processor.

TX and RX connected to a Pololu AVR Programmer.

0.1uF capacitor across VCC and GND at the processor.

16 MHz crystal + capacitors from Evil Mad Science connected to XTAL pins.

AVCC connected to +5 volts.

Analog side GND connected to ground.

AREF unconnected.

SCK, MOSI, and MISO connected to the Programmer.

I've tried with and without and LED + series resistor on pin 3.

Maybe put a 0.1uF capacitor there for decoupling.

Across VCC and GND?

On a Uno, the problem does not occur.

Thank you for testing!

A single "1" was output? Anything different if you click the Reset button?

I got a single 1, as you would expect. Pressing reset produces another 1.

Output (pressing reset a few times):

1
1
1
1
1

Across VCC and GND?

Yes, but you say you have that.

I took a logic analyzer measurement, see attachment. I can't say that a 489 Hz frequency introduced in your circuit should cause major problems.

I believe, for the theory to be true, there has to be an interrupt service routine in the mix.

My guess is that an interrupt is indeed behind it. Judging by what you posted you are not using the standard "back end" library:

All libraries removed.

Perhaps the serial output causes an interrupt which hits random data where the serial interrupt handler should be. This seems to be confirmed by the fact that your alternative serial output routine does not have this problem.

Screen shot 2011-04-17 at 7.26.29 PM.png

I got a single 1, as you would expect. Pressing reset produces another 1.

Hmm. Me thinks it's time to try another processor. I starting to suspect this one may have gone insane.

I can't say that a 489 Hz frequency introduced in your circuit should cause major problems.

There's something special about pin 8 being fed a PWM signal. If the wire is connect to another (unused) pin, the problem does not occur. If pin 3 is simply set high, the problem does not occur.

My guess is that an interrupt is indeed behind it.

I wish it was. Then I could fix it. Unfortunately, testing does not bear that out.

I tried the Sketch posted with a "catch all" interrupt handler. The handler did fire. Proof that an unhandled interrupt may be the culprit.

I tried a different Sketch that produced the failure with the "catch all" interrupt handler. The handler did not fire. Proof that an unhandled interrupt is not the culprit.

I tried a Sketch with individual handlers for all the interrupts that were not otherwise hooked. None of the them fire. Proof that an unhandled interrupt is not the culprit.

I tried "cli" in various places. The failure still occurs but the behaviour is different. Proof that an unhandled interrupt is not the culprit.

As far as I can tell, interrupts effect the symptoms but are not the root cause.

Judging by what you posted you are not using the standard "back end" library:

I'm using the standard "core". I made certain that the "libraries" (e.g. Servo, EEPROM, SoftwareSerial) were not part of the build. I've tried with and with out the libraries and it makes no difference (which is the one thing I expected to happen that actually did happen).

In other words, the Sketch built with a standard Arduino 0022 installation crashes.

This seems to be confirmed by the fact that your alternative serial output routine does not have this problem.

It's a good theory but it doesn't hold up to the interrupt tests I did. Interrupts seem to change the symptoms but just don't seem to be the cause.

The failures seem to be dramatically effected by the timing (one more line of code might be far fewer failures; two more lines of code result in many more failures). I suspect the "serial test" hit a magic timing spot with no failures.

Thank you for your time, your effort, and your comments! If you (or anyone else reading this) think of anything else, please let me know!

For what it's worth, just tested on a Bare Bones Board (using the Duemilenove bootloader). Same results as before for me, that is it worked correctly.

I presume by pin 3 you mean D3.

Thanks again for your effort!

For what it's worth

It's worth a great deal...

At this point, I think it's safe to say that the IDE, compiler, core, and processor family are not the problem. That leaves my processor (damaged?) or my wiring (loose? antenna like?).

I presume by pin 3 you mean D3.

Yes. "Arduino pin 3". The other pin is "Arduino pin 8" (PB0). Sorry about the ambiguity.

If I read the circuit correctly pin 8 on the board is pin 14 (ICP/PB0) of the Atmega.

Now assuming I am understanding that correctly ICP is the Input Capture Pin. See page 120 of the manual. In particular:

When a change of the logic level (an event) occurs on the Input Capture pin (ICP1), alternatively on the Analog Comparator output (ACO), and this change confirms to the setting of the edge detector, a capture will be triggered.

Just stabbing in the dark here, and bearing in mind I can't reproduce any of this. But perhaps a rogue interrupt (or misbehaviour) is occurring because of input on that pin?

Just tried also on my Mega 2560, same results as before.

So, at each start of loop you set doOnce true, the if is executed, and inside the duOnce is set false, them loop well loops and doOnce is once again true, so what will happen?
The if is executed!!!!!!!!!!!!!!!!!!!!!
Is it that hard to read the code?

Is it that hard to read the code?

Well apparently it is for you.

Senso:
... them loop well loops and doOnce is once again true ...

Perhaps you can explain why, when I tried it, it only printed "1" once. You could try the code yourself.

So, at each start of loop you set doOnce true, the if is executed, and inside the duOnce is set false, them loop well loops and doOnce is once again true, so what will happen?
The if is executed!!!!!!!!!!!!!!!!!!!!!

I see why with a quick look you might think it would do this but it's not doing quite what you think it is.

So, at each start of loop you set doOnce true,

Nope. "static".

How about another 0.1uF on the AVCC/AGND side?

Also try configuring the other unused pins with pull-ups. Maybe more noise there than you expect.

If you have a scope, try measuring VCC to look for unexpected ripple/voltages.

And check the pin 3/8 combo to see if you have the signal you expect there.

After that, replace the chip and see if the problem goes away? If it's breadboarded that should be simple enough.

I believe I have found the culprit. Nick, you were on the right trail.

I'm using a largish breadboard. On one half I have the 328 and it's stuff. On the other half I had a "4-Bit Bus Switch". The two things shared power lines but were otherwise not connected. I had the bus switch connected to four LEDs (+resistors) so I could prove my SOIC + pigtail soldering had gone well. I had four loose jumpers connected to the enable lines of the bus switch. 10K pull-down resistors were also connected to the enable lines. My guess is that the loose jumpers acted as antennas, caused the bus switch to rapidly trigger, creating digital noise on the power line. This is, by far, the strangest hardware problem I've ever encountered.

I thank all of you for your help! Especially you, Nick! Without your decoupling suggestions I would have come to the conclusion that the processor was damaged and tossed it.

Glad I could help. And I learned something too, so next time I go to breadboard a processor I'll pay more attention to those pesky decoupling caps. :slight_smile:

Actually the funny thing is, a little while back I was reading the VCC line with a scope and saw what I thought was a crazy amount of noise on it, so I can see why those things are needed. I'll see if I can reproduce it.

I have to admit, I am curious to know exactly what was happening but I just can't spend anymore time on it.

I'll see if I can reproduce it.

Please don't spend (waste) too much time trying. The bus switch has been on the breadboard for several days not causing problems. The failure is because of some bizarre combination of the bus switch, the dangling jumpers, PWM, the ICP pin, and the software.