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

[Herb Peyerl]

Richard Urwin <address@hidden>  wrote:
 > 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.

Ok, I had to run to the office to pickup my shop vac, so I played with it
for a few minutes... 

What I'm seeing from:

void
ioinit (void) /* Note [5] */
{
        DDRD= 0x13;             // PD3/PD5/PD6/PD7 are inputs
        DDRB= 0xec;             // PB0, PB1, PB4 are inputs.
        DDRC= 0xfe;             // All outputs. except for SR_Q (PC0)
        PORTC= 0;               // disable pullup.
        PORTB= 0;               // disable pullup.
        PORTD= 0;               // disable pullup.

        GIMSK= 0x0;             // Clear the mask.
        MCUCR= 0x3;             // rising/falling/whatever.
        GIMSK= 0x40;            // Enable INT0 interrupt.

        sei ();

        UBRR= 12;               // 38400 baud.
        UCSRB= 0x18;            // enable receiver and transmitter.
sbi(PORTC, 5);
        fdevopen (uart_putchar, uart_getchar, 0);

        // init spi
        SPCR= 0x57;             // SPE, MSTR, CPHA, SPR1, SPR0
 
}
   
int
main (void)
{
        char c;
        char intbuf[4];         // somewhere to store decimal strings.
        
        ioinit ();
        .
        .
        .
        .



...is a spike about every 160us on the scope, indicating to me that the
AVR is resetting somewhere in fdevopen().  If I moved the sbi(PORTC,5) 
below the fdevopen, I see nothing on the scope.

Again, this only happens if I have over a certain size of data in my
.data section.  I can cause this situation by adding a few characters
to an fputs() that isn't even in the code path.

The code works just fine as long as I keep my .data section below
0x4a bytes... I'm thinking there's nothing wrong with the fdevopen()
call but that it's being tromped by my .data section perhaps, or 
some other strangeness...

Anyone got any clues?