One Crazy Sketch

The hardware...

  • 328P processor on a breadboard.
  • Jumper from pin 3 to pin 8.

The environment...

  • Windows Vista
  • Arduino iDE 0022
  • All libraries removed.

The code...

void setup( void )
{
  Serial.begin( 115200 );
  analogWrite( 3, 127 );
}

void loop( void )
{
  static bool DoOnce = true;
  static unsigned Loops;
  
  if ( DoOnce )
  {
    ++Loops;
    Serial.println( Loops );
    DoOnce = false;
  }
}

The expected result...

  • A single "1" should be output to Serial.

The actual result...

  • Lots of "1' output to Serial. (processor resets on its own)
  • Numbers greater than "1" output to Serial.

The question...

  • Can anyone reproduce the problem? (please try it on any 328 or 168 based board)

I am setting it up in my breadboard to try it.

Meanwhile are you using an external clock crystal?

I am setting it up in my breadboard to try it.

Thank you! This thing has been driving me batty. At this point, my only theory is that the stack is becoming corrupt. I believe, for the theory to be true, there has to be an interrupt service routine in the mix. But, I'm down to USART RX (which should never fire) and TIMER0 OVF (which is used in every Arduino application every written).

Meanwhile are you using an external clock crystal?

16 MHz. With the exception of no bootloader, it should be functionally equivalent to an Arduino.

If you think an ISR is involbed: add CLI() and see if the problem still happens.
Did you already try to disassemble it?

Well this is strange. For me nothing get's printed in the serial monitor.

I was using Atmega 328P

Thanks! Great idea...

void setup( void )
{
cli();
Serial.begin( 115200 );
...snip

...this is much worse. I'm starting to think this processor has been damaged.

void loop( void )
{
cli();
...snip

...this is much better. But it still fails.

Did you already try to disassemble it?

I did. I could not find anything suspicious.

I also tried Arduino 0021. The behaviour is a bit better (less frequent failures; that could be coincidence) but it too fails.

Well this is strange. For me nothing get's printed in the serial monitor.

What happens if you remove the jumper?

Try putting a 3 second delay at the top of setup.

For me, the three second delay has made the symptoms much worse.

What the heck is going on! :0 =(

What happens if you remove the analogWrite? What if you remove the jumper? What is you power supply?

Problem disappears.

What if you remove the jumper?

Problem disappears.

What is you power supply?

Powered USB hub. Consistently provides 5.12 volts.

I've also tried the latest version of WinAVR (20100110).

Another fun wrinkle. This seems to behave correctly...

#include <avr/io.h>

void HardwareSerial_write(uint8_t c)
{
  while (!((UCSR0A) & (1 << UDRE0)));
  UDR0 = c;
}

void HardwareSerial_begin( long baud )
{
  uint16_t baud_setting;

  UCSR0A = 1 << U2X0;
  baud_setting = (F_CPU / 4 / baud - 1) / 2;
  UBRR0 = baud_setting;
//  UCSR0B |= (1 << RXEN0);
  UCSR0B |= (1 << TXEN0);
}

void setup( void )
{
  HardwareSerial_begin( 115200 );
  analogWrite( 3, 127 );
}

void loop( void )
{
  static bool DoOnce = true;
  static unsigned Loops;
  
  if ( DoOnce )
  {
    ++Loops;
    HardwareSerial_write( '*' );
    DoOnce = false;
  }
}

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?