[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [avr-gcc-list] Re: Strange compile behaviour
From: |
Han Hoekstra |
Subject: |
RE: [avr-gcc-list] Re: Strange compile behaviour |
Date: |
Wed, 3 Feb 2010 16:42:35 +0100 |
I want to thank everyone that helped me with my problem.
I finally found what the problem was and of course it was my own doing.
The piece of code causing the problem is the following:
void main_MyInit (void) __attribute__((naked)) __attribute__ ((section
(".init1")));
void main_MyInit (void)
{
uint8_t *p;
for (p = &__data_start; p < &__heap_end; p++) {
*p = GLOBAL_RAM_FILL_BYTE;
} /* for */
} /* main_MyInit */
This code I have taken from another project we have here which uses an
ATMega128 with external RAM. And for the external RAM to be used we
specified this '-Wl,--defsym=__heap_end=0x808fff' in the linker settings,
which causes the __heap_end to have a location in memory.
But __heap_end does not point to the end of RAM in the ATMega168 project, it
has the value 00000000, so the loop should not do anything. Changing the
function to :
void main_MyInit (void) __attribute__((naked)) __attribute__ ((section
(".init1")));
void main_MyInit (void)
{
uint8_t *p;
for (p = &__data_start; p < (uint8_t *) RAMEND; p++) {
*p = GLOBAL_RAM_FILL_BYTE;
} /* for */
} /* main_MyInit */
made everything work.
I have no idea why it is ok now, since I explicitly set __bss_end [0] and
__bss_end [1] to GLOBAL_RAM_FILL_BYTE before ever checking it and why the
loop :
while (app_TXIncomming != 0) {
} /* while */
Seemed to fix the problem is also not clear to me, because in the test
situation app_TXIncomming would never be anything else than 0.
But my code works again now, so I am happy for the moment, I can continue
with my project and maybe later check out what was going on with the wrong
code, if I have the time.
Again, thanx all.
Greetings,
Han
__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4831 (20100203) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
[avr-gcc-list] Re: Strange compile behaviour, David Brown, 2010/02/02