AVR "remembering" code, even after erasing and ref

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

Having successfully tried out a blinking code (to check my programmer/chip USBasp/ATMega168 was working) i tried to upload some ADC code.

It works more or less as planned, with a pot controlling the input voltage the status LED turns off when the input drops below whatever i set it to.

I set up the interrupt vector to blink the led with a 10ms delay. The vector works as mentioned above.

However, now it seems to be permanently stuck in ISR mode.

I tried to upload a simple "always on" LED script, the chip is still blinking and still responds to potentiometer input. This problem of apparently not fully erasing is driving me up the bend.

Having been confused by this, i plugged the chip back into the programmer and erased it. In eXtreme burner it definitely worked, the address summary was a page of FFFF's. I put it back into the circuit and tried it out again, nothing - obviously. I then tried to reflash the new code.

What happens? The LED starts flashing and responds to ADC input. This is from a hex file that has recompiled, the chip's been erased (and i know it was erased because it didn't do anything when i plugged it back in).

This is the code that's currently on there:

#include 
#include 
#include 
#include 
#include "adelay.h"

//io init
void init_io(void)
{
	//All Ouputs on
	DDRD = 0xff;
	DDRC |= ( 1 << PC1);
}
int main(void)
{
	init_io();
	//Turn main LED on
	PORTC |= (1 << PC1);
	
	ADCSRA &= ~(1 << ADEN);  // Disable ADC
	
	ADCSRA &= ~(1 << ADIE);  // Disable ADC Interrupt 

	cli();
	while(1)
	{
	PORTC |= (1 << PC1);
	}
}

ISR(ADC_Vect)
{
}

It's not a problem with the hex file, i uploaded it to an ATMega8 without any issues - the LED was lit continously.

Note my vain attempts to turn things off (interrupts, ADC registers) - which failed.

Interestingly if i enable both of the two LEDs (PC1 and PC2) in the new code, both will blink. If i then reflash with only one enabled, only one will blink. So the new code is obviously uploading and changing registers, but just not doing anything...

Is there some weird non-volatile memory (that stores interrupt routines) that i'm not aware of?[/code]

Last Edited: Thu. Sep 24, 2009 - 06:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

when the chip is erased all the code is gone, so it will not remember secretly.

Did you start a new project for your next stage? and then perhaps are loading the old hex file. If you use avr studio even when starting a new project you still have to change the hex file by hand to the new hex file. I also have seen that when there where complie/link errors there still was an old hex file available. thus also burning old code...

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

Nope, as i said the new hex file works with a different chip. The new file is also trimmed down to about half the size so can't possibly be the same.

I'm writing it up in notepad++, make-ing in command prompt and then uploading via eXtreme Burner.

I ran "make clean" a couple of times to be sure, but the fact it runs fine on a different chip is bugging the hell out of me :P

Is there any way i can check if the chip is narked? As it stands i can't see any logical explanation why it's still turning on the ADC..

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

Whiternoise wrote:
Is there any way i can check if the chip is narked?

It depends from your programmer.

A programmer should typically execute these four steps:

- erase
- blank check
- program
- verify

And every step must pass.

Peter

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

I've tried all of the above in AVRDude (aside from blank check - how would i do that?)

It passes every one and still doesn't work :)

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

if it verified ok then the code that you want to burn is checked against what is burned so that should be the same

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

Whiternoise wrote:
It passes every one and still doesn't work :)

Then the programmed HEX-file was an older file, not generated from your current source code.

I made this error also.
Then after erasing the new HEX-file, the programmer was still able to open the HEX-file.
Then I detected, the programmer was configured, to load the HEX-file from a different directory.

Erase the HEX-file and check, if the programmer says: file not found".

Erase also all *.o files of the project.
This covers the fault, that a syntax error occur and the compiler generate no new object file.

Compile to a new Hex-file.

Peter

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

Is it possible that it is working but you have watchdog reset enabled?
Say if the WDTON fuse is set?

--- bill

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

Whiternoise wrote:
It's not a problem with the hex file, i uploaded it to an ATMega8 without any issues - the LED was lit continously.

Whiternoise wrote:
(to check my programmer/chip USBasp/ATMega168 was working) i tried to upload some ADC code.

You seem to be saying that the hex file works on a mega8, but not on a mega168. You cannot in general make one hex file work on multiple different types of processor chip. The compiler does slightly different things depending on the target chip and the hex file will come out differently, despite the functionality being the same.

You need to change the target options to the correct chip, then clean and rebuild to make a fresh hex file. Check the time/date stamp on the file, and then try programming with it.

Christopher Hicks
==

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

@Christopher - sorry, i thought it was implied, i did of course change the makefile when i switched processors over (i did upload the wrong version by mistake once, but it just acted like no program was on there).

Thanks for the advice chaps,

I eventually got it working. I managed to get the driver for usbasp working on Win7 (i'm using x64 and it doesn't allow unsigned drivers without a little.. help). I then erased and flashed, etc and it seems to be working alright now. Previously i was running it on my macbook.

Really really baffling though :P

Especially when i was 99% certain that the hex files were different (i mean it was half the size, the GUI showed a totally different hex map than the one that was on the chip). But, at least it's sorted :)