[WinAVR-users] [ winavr-Bugs-1671819 ] ATmega168/88/48 RAM used from 0x0060

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bugs item #1671819, was opened at 2007-03-01 17:07
Message generated for change (Comment added) made by h_a_r_r_y_
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=520074&aid=1671819&group_id=68108

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Deleted
Resolution: None
Priority: 5
Private: No
Submitted By: H.A.R.R.Y. (h_a_r_r_y_)
Assigned to: Nobody/Anonymous (nobody)
Summary: ATmega168/88/48 RAM used from 0x0060

Initial Comment:
After succesfully working with older versions of WinAVR and AVR-Studio the latest upgrade (and also the version from mid of 2006) produce some nonsense using ATmega168.

The problem is that variables locate at 0x0060 which is the extended IO space on these devices. The correct location should be 0x0100 for RAM start.

I carefully doublechecked this behaviour also with the latest version. Simulation with AVR-Studio yields the same weird behaviour as trying it out with a controller.

Currently I'm not sure where the problems is located so please forgive me that I enter some of the code here (main.h is empty, properties.h only does some assignments on port usage, but no adress adjustments!):

#include "properties.h"
#include "main.h"
#include <avr/io.h>

unsigned long phaseAccu1, phaseIncrement1;
unsigned int phaseIndex1;
int envelope1;
char dac1;
unsigned char ampl1;

unsigned long phaseAccu2, phaseIncrement2;
unsigned int phaseIndex2;
int envelope2;
char dac2;
unsigned char ampl2;

#if defined __AVR_ATmega168__
	#define bug 160 // the 160 extra byte result from a WinAVR bug on ATmega168: extended IO used as RAM!
#elif defined __AVR_ATmega88__
	#define bug 160 // the 160 extra byte result from a WinAVR bug on ATmega88: extended IO used as RAM!
#elif defined __AVR_ATmega48__
	#define bug 160 // the 160 extra byte result from a WinAVR bug on ATmega48: extended IO used as RAM!
#else
	#define bug 0
#endif

char triangle [bug+256];

int main (void)
{
	SPI_CS_PORT |= (1<<SPI_CS0) | (1<<SPI_CS1);	// preset port bits
	SPI_CS_DDR |= (1<<SPI_CS0) | (1<<SPI_CS1);		// make bits outputs
	SPI_DDR |= (1<<SPI_CLK) | (1<<SPI_MOSI);		// enable SPI lines
	PORTB = (1<<PB2); // PB2 is input but pulluped for SPI-master use!!
	DDRB |= (1<<PB2); // PB2 is input but pulluped for SPI-master use!!
	SPCR = (1<<MSTR) | (1<<SPE);					// enable SPI in master mode
	SPDR = 0;
	// prepare the triangular wave
	for (phaseIndex1 = 0; phaseIndex1 < 64; phaseIndex1++)
		triangle[bug+phaseIndex1] = (phaseIndex1 << 1);
	triangle[bug+64] = 127;
	for (phaseIndex1 = 65; phaseIndex1 < 192; phaseIndex1++)
		triangle[bug+phaseIndex1] = 256 - (phaseIndex1 << 1);
	triangle[bug+192] = -127;
	for (phaseIndex1 = 193; phaseIndex1 < 256; phaseIndex1++)
		triangle[bug+phaseIndex1] = (phaseIndex1 << 1) - 256;
	// setup generators
	phaseIncrement1 = 30236570; // 0x01CD5F9A;
	phaseIncrement2 = 23998782;
	phaseAccu1 = 0;
	phaseAccu2 = 0;
	envelope1 = 0;
	envelope2 = 0;
	while (1)
	{

		phaseAccu1 += phaseIncrement1;
		phaseIndex1 = (phaseAccu1 & 0xff000000) >> 24;
		dac1 = triangle[(bug+phaseIndex1)];
		envelope1 -= 3;
		ampl1 = envelope1 >> 8;
		dac1 = (int)(dac1 * ampl1) >> 8;
		while ((SPSR & (1<<SPIF)) == 0x00) {}
		SPI_CS_PORT |= (1<<SPI_CS0) | (1<<SPI_CS1);
		SPDR = dac1 ^ 0x80;
		SPI_CS_PORT &= ~(1<<SPI_CS1);

		phaseAccu2 += phaseIncrement2;
		phaseIndex2 = (phaseAccu2 >> 24);
		dac2 = triangle[(bug+phaseIndex2)];
		envelope2 -= 3;
		ampl2 = envelope2 >> 8;
		dac2 = (int)(dac2 * ampl2) >> 8;
		while ((SPSR & (1<<SPIF)) == 0x00) {}
		SPI_CS_PORT |= (1<<SPI_CS0) | (1<<SPI_CS1);
		SPDR = dac2 ^ 0x80;
		SPI_CS_PORT &= ~(1<<SPI_CS0);

	}
	return(0);
}

The problem is that the array is starting at 0x0060 and the only workaround currently was to use the 'bug' variable to inflate the array size so that the critical area stays unused (nulled out).

On ATmega8 the project compiles and works as intended, the array here starts also at 0x0060 but this is the valid RAM start.

Here is the makefile that I use:
PROJECT			= noname
MCU_TARGET		= atmega168
OPTIMIZE		= -O2
DEFINITIONS		= -DF_CPU=8000000UL
#LIBS			= -lm
LIBRARIES		=

COMPILER		= avr-gcc
LINKER			= avr-gcc
OBJCOPY			= avr-objcopy
OBJDUMP			= avr-objdump

TO_COMPILER		= -g -Wall $(OPTIMIZE) -mmcu=$(MCU_TARGET) $(DEFINITIONS)
TO_LINKER		= -Wl,-Map,$(PROJECT).map
TO_OBJCOPY		=  -j .text -j .data -O ihex

# Override is only needed by avr-lib build system.
override CFLAGS	= $(TO_COMPILER)
override LFLAGS	= $(TO_LINKER)

all: $(PROJECT).elf #eeprom

$(PROJECT).elf: main.o Makefile
	$(LINKER) $(LFLAGS) -o $(PROJECT).elf $(LIBRARIES) main.o
	$(OBJCOPY) $(TO_OBJCOPY) $(PROJECT).elf $(PROJECT).hex

main.o: main.c main.h properties.h Makefile
	$(COMPILER) $(CFLAGS) -c main.c

#lcd.o: lcd.c lcd.h properties.h Makefile
#	$(COMPILER) $(CFLAGS) -c lcd.c

.PHONY: clean
clean:
	rm -rf *.o *.elf *.eps *.png *.pdf *.bak 
	rm -rf *.lst *.map $(EXTRA_CLEAN_FILES)

Is there the possibility that on newer versions something went wrong with the ATmega48/88/168 memory handling? Is this possibly a bug? If so, is there a quick (and better than mine) workaround possible until a debugged version is available?
I failed finding something like RAM_START in the headers included to WinAVR. Also the FAQs and so on do not yield any result to this problem.

Best regards
H.A.R.R.Y.

----------------------------------------------------------------------

>Comment By: H.A.R.R.Y. (h_a_r_r_y_)
Date: 2007-03-02 16:07

Message:
Logged In: YES 
user_id=1732505
Originator: YES

I'm terribly sorry for any inconvinience by this topic.
The bug is not in WinAVR project but in my makefile. I'm sorry.

Best regards
H.A.R.R.Y.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=520074&aid=1671819&group_id=68108