Re: [avr-gcc-list] 4433 .data+.text sensitivity.

[Richard Urwin]

On Wednesday 24 Dec 2003 1:18 pm, Herb Peyerl wrote:
> My problem is that the function of my application seems to be highly
> dependant on the size of my .data section. The following produces
> code that works fine:
>
> 0 .text 00000962 00000000 00000000 00000094 2**0
> 1 .data 0000004a 00800060 00000962 000009f6 2**0
> 2 .bss 00000012 008000aa 008000aa 00000a40 2**0
>
> Adding a few extra bytes in an fputs() results in code that does
> not work. ie: out of reset, there is no outward appearance that
> the cpu is even coming out of reset (according to the scope on I/O
> pins that I expect to do stuff). So the following is with the
> addition of a few bytes in an fputs():
>
> 0 .text 00000962 00000000 00000000 00000094 2**0
> 1 .data 0000004e 00800060 00000962 000009f6 2**0
> 2 .bss 00000012 008000ae 008000ae 00000a44 2**0
>
> It doesn't even seem to matter whether the fputs() in question is
> in the code path or not.
>
> Now, unless I'm missing something obvious here, a 4433 has 4K of
> flash and I'm not coming anywhere near that threshold. I'm doing
> very little in the way of function calls so I'm content to think
> I'm not abusing the stack at all.

I don't know the 4433, or avr-gcc, but in the interests of a quick answer:
4K flash is of course 2K instructions. But the section size will be reported 
in bytes anyway, so that isn't likely to be the problem.

When moving data around changes the behaviour, the problem is usually a loose 
pointer. So check for uninitialised variables.

Are you using a pointer to automatic data? eg

char * badpointer ()
{
        char buffer[64];
        return buffer;
}

If you have a spare output, try setting it as the first thing in main(). If 
that works move it down the program until it stops working. Of course if the 
problem is interrupt-related things may get ill-defined, but that should give 
you a clue. Adding that code may well change the behaviour too.

HTH, Merry Christmas.

-- 
Richard Urwin