Ignore the part about having to reburn the bootloader. That only applies if the watchdog fuses were set which isn't a normal Arduino occurrence.

You will still get into an annoying reset loop, but it can be cured by power cycling the chip (which is annoying if your trying to upload a program).

Well I guess you can use it for a "time-based" interrupt. But that's what the hardware timers really are for. They can also generate a number of different interrupts based on how you configure them.

The watchdog timer is really designed to allow some event to happen if the watchdog doesn't get reset before it expires. Normally the "something" is reset the chip. The code then must reset the timer frequently (at least faster than the timeout) to prevent the watchdog from firing. This is sometimes referred to as "feeding the dog". Then if the chip crashes or the code goes awry, the watchdog timer will expire and fire the "something" (reset the chip).

The other problem with using the watchdog is that if it triggers a reset it's still enabled when the chip restarts. The bootloader doesn't disable it or regularly "feed the dog" since it doesn't expect the watchdog to be enabled. This can then lead to an endless loop of resets that can only be resolved by reburning the bootloader with a programmer.

So the short answer is the hardware timers are designed to be used for what you're trying to do, not the watchdog timer.

I think you're confusing the hardware timers (TIMER0 & TIMER1) with the watchdog timer.

The watchdog is mainly designed to reset the chip if it freezes. The hardware timers are meant for programmatic events (like being triggered every second).

Well where did it go? When you buy a Duemilanove it comes with an ATmega168 (or more recently a ATmega328).

Without it it's like taking the CPU out of your computer (and about as useful).

Good thing you can always buy another:

http://www.nkcelectronics.com/arduino-ready-avr-atmega328-microcontrol328.html
http://www.sparkfun.com/commerce/product_info.php?products_id=9217
http://www.adafruit.com/index.php?main_page=product_info&cPath=17&products_id=123

The picture you posted shows a XBee module, plugged into a XBee shield which is plugged into the Arduino. So if you want to see if a XTmega chip is installed (and which one), you'll have to remove the XBee shield (by pulling straight up).

[crisfuga]

Well I was actually replying to crisfuga who seems to be ignoring the advice.

But if you don't have an ATMega chip installed, then I have 100% confidence that you're not going to be able to upload a sketch. Your image post didn't work so I can't tell you for sure what you have (or don't have).

The chip on a standard Arduino is located as indicated by the yellow box:

i want to solve this problem as soon as possible.

second try to give you the answer...

Then read the other posts in this topic (<< it's a link) that tell you how to solve the problem. If you don't want to click on the link, then just scroll up.

I am working with the same board, and i have this problem too.

I bought Arduino+Xbee board last week. When I tried to upload a example, this message appeared:

avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

I saw the recommendations in Arduino website but I can´t solve it.

Some information about my enviroment:
OS: Windows XP
Serial Port: COM3
Board: Arduino Duemilanove + XBee (Squidbee)

I am new in Arduino.I need your help. Thanks!

Read some of the earlier replies in this topic.

remove the module before uploading.

What he said.

The Xbee is connected to RX/TX pins on the chip. This is interfering with the upload because the data from the FTDI chip also connects to the the same pins.

Another solution would be to remove both jumpers on the Xbee shield that control how the Xbee's serial lines are connected when you want to upload. You didn't say which Xbee shield you have so I assume you have the jumpers.

If you just want the computer to talk directly and only to the Xbee, then you need to set the jumpers in the "USB" position and remove the ATmega chip from it's socket.

Yes, you can change the receive buffer to save some RAM. This presumes that you are not receiving a large amount of serial data. The buffer is there so that if you don't do Serial.read() quickly enough you don't lose data (by overrunning the buffer).

Another thing you can look into is moving your string literals into PROGMEM. This moves them from RAM to the flash program space. There is a Flash Library that can make this easier.

Next, look at your variable definitions and make sure you're using appropriate types. Don't use an int when all you need is a byte (like for the pin definitions). Avoid floats unless you really really need floating point results. Use "const" or #define for constants instead of using variables (once again for things like pin definitions or other fixed values). If the value is defined as a constant (or #define) the compiler uses the value where appropriate at compile-time only. This eliminates it's RAM footprint. It all comes down to optimization to preserve a very limited resource.

Lastly, remember that there is a difference between the variables that are static and consume a constant fixed amount of space in the heap, and dynamic usage in the heap and stack - both of which reside in RAM. As you call functions in you sketch, the arguments (and result from the function) are placed on the stack, causing it to temporarily grow. Also, any variables defined in the local scope of the function are added to the heap - also causing it to grow. When the function exits, this stack space and heap usage is released. The problem is that if you're close to running out of RAM from your static usage, the dynamic amount used during function calls can push you over the limit and cause the heap and stack to collide and corrupt data (causing crashes, weird results, etc.). This is very difficult to diagnose since the dynamic usage is only temporary. So the general rule of thumb is to not let your static usage get too high so that you have minimal free RAM.

You're probably running out of RAM and that's making your program misbehave.

All of those literal strings get stored in RAM along with the stack, heap and various predefined buffers. It's very easy to use up 1K.

The tabs are not different sketches. The tabs are all part of the one sketch you have open. When you compile, the contents of the tabs are assembled into the complete program. The tabs are just a way to separate your code in to more manageable sections.

My ethernet shield is working fine and the Wiznet chip does get a little warm as well so I'm assuming that's normal. After about an hour of being powered on the chip's surface temp is about 44C so it's warm, not hot.

BTW, I see that there is a new release of the AVR libraries. Should I consider installing these?

I don't know.  You haven't said what platform you're running under so I'm assuming Windows.

Unless you can find some specific mention of a bugfix regarding missing definitions for PB0, PB2, etc., then probably not. At this point it's unclear why the definitions are missing for the 328 (or whether it's even a bug). Maybe those definitions have been deprecated and the library you're using needs to be updated. The 328 is almost simply a "bigger" 168, but not completely. A lot of the same kind of problems cropped up when the transition from the ATmega8 to 168 occurred. There were also some differences in the chips and many libraries had to be updated with conditional code that uses different definitions for each chip.

In looking at the header files for the different chips, the ATmega8 and ATmega168 both have PB0-PB7 defined.  The ATMega328 header file has the pin definitions named PORTB0-PORTB7. So you could either change the library to use PORTB0 in place of PB0, or add the definitions for PB0-PB7 to the header file in:
hardware/tools/avr/avr/include/avr/iom328p.h

For reference the header file used for the 8/168 is iomx8.h

Personally I'd recommend the latter as it will maintain code consistency across the different chips. I suspect it's simply a bug that the pins were renamed

See http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1237133962/4#4 for more info on PB2.

A couple of early thoughts...

I don't even know how this compiles (but it does).  This isn't correct:

Code:

Serial.begin (9600), // Start the serial connection at 9600 baud

There's a space before the (9600) and a spurious comma afterwords and there is no terminating semicolon.

Also, why don't you use the built-in shiftOut function?  In your version you're unnecessarily setting the pinMode for the clock and data pins with every call.  These only need to be set once in your setup() code.

I'm a little iffy on your shiftOut code and potential timing issues.  For example you set the dataPin back to 0 immediately after raising the clock pin - with no delay.  This leaves a very short window (only a few clock cycles) where a high data bit is actually represented with a high data pin.  Depending on the device you're talking to this may be too short an interval to actually record as a high bit once the device "catches" the clock transition.

I think you'd have better luck using the tested and reliable built-in shitOut function.

Lastly, how do you know your code isn't running when the serial monitor isn't open?  If it's because you're not getting data out through your shift register then the problem might be in that code.  If you're using a Diecimila or Duemilanove (or clone of these), then opening the serial monitor will cause a reset of the chip.  This may be what you're seeing rather then it "unsticking".  Try putting some led blink logic in your loop() as a status indicator so you can tell that the code is actually running.  This will help narrow down where the problem is.