Society of Robots - Robot Forum

Electronics => Electronics => Topic started by: krich on July 29, 2008, 05:46:31 PM

Title: ATmega168P Issue
Post by: krich on July 29, 2008, 05:46:31 PM
I'm having a bit of a problem with my atmega168p.  Up until a few days ago it worked fine.  Then, it started exhibiting this strange behavior.  I can program it, erase it, set/check the fuses, everything.  The program even runs after I've programmed the chip.  The program runs if I reset the chip via the reset pin.  However, if I power the chip off, and then power it back on, the program does not run.  Resetting via the reset pin also does not work.  Strangely enough, if I verify the programming via AVR Studio while its exhibiting this behavior, it checks out okay.  Fuses check out okay as well.

What gives?   Any ideas?  :(

Edit:  I guess I should quantify "the program does not run".  The first thing that happens is that the UART gets initialized and a "Booting..." message is printed out to the serial port.  When "the program does not run", I get nothing on the serial port.  I'm in the process of installing a blinking boot LED as a backup boot indicator just to be sure it's not something strange with the UART.
Title: Re: ATmega168P Issue
Post by: pomprocker on July 29, 2008, 05:52:27 PM
Are you running it off a stable power source?
Title: Re: ATmega168P Issue
Post by: krich on July 29, 2008, 05:57:45 PM
Are you running it off a stable power source?

Yep, running off a 7.2V battery, which checks out at about 7.4V with the meter.  The battery feeds a typical 5V power supply (7805), and I'm measuring 5.1V out of that supply onto the rail that powers the atmega.


Edit:  Figured it out.  On a side note:  Why do I always have to be the person folks point to and say, "don't do it like that".  Geez...   :-\

For the record, I was trying to use the UART before it was initialized.  In my defense, the code is in C++ and the offending statement was in a class constructor that was called before the UART was initialized.  It wasn't completely obvious considering both the UART init statement and the rogue printf statement were in different files, even.

Hehe, live and learn.  Thanks for the moral support, guys (and the occasional gal).