RE: [avr-gcc-list] Re: Strange compile behaviour

[Han Hoekstra]

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