Atmega168 behaves very buggy after uploading code

Go To Last Post
2 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I have a weird problem with an Atmega168. I was adding some features to my software when all of a sudden, the controller started behaving very buggy; the update_display() method I wrote started to display random data from memory (like strings defined elsewhere the code), controls didn't work anymore, etc.

I've had this before when I had buffer overruns etc, so I decided to revert back to a version I know works (the last commit in my bzr repository), but the problem persisted.

I thought, maybe all these write cycles have damaged the chip, so I replaced it. It worked again. But then I put my new features back into the code and uploaded. And again, the controller is very buggy, and uploading old code to it doesn't fix it.

It's almost as though a part of its memory was overwritten that wasn't supposed to.

Question is, how do I know what's going on and how do I fix it? Rewriting the fuse bits doesn't help.

I use GCC and Avrdude in Linux. This is it's output:

avrdude -c avrispmkii   \
 -p atmega168 -P usb -e        \
 -U flash:w:preamp-cpu.hex 

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9406
avrdude: erasing chip
avrdude: reading input file "preamp-cpu.hex"
avrdude: input file preamp-cpu.hex auto detected as Intel Hex
avrdude: writing flash (7476 bytes):

Writing | ################################################## | 100% 2.48s

avrdude: 7476 bytes of flash written
avrdude: verifying flash memory against preamp-cpu.hex:
avrdude: load data flash data from input file preamp-cpu.hex:
avrdude: input file preamp-cpu.hex auto detected as Intel Hex
avrdude: input file preamp-cpu.hex contains 7476 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 2.43s

avrdude: verifying ...
avrdude: 7476 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

7 k of flash should fit in the 16k of the device.

If it were a RAM problem, uploading an old version of the program should fix it...

Any help is welcome.

edit: apparently, because I had programmed the fuse bits to retain the EEPROM upon chip erase, this happened.

But the question remains, why does the code start getting all buggy when I add in code that isn't even executed yet?

How can one know if you're running out of memory, anyway?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your software has programmed and verified correctly.

Your new 'features' are most likely the problem.

David.