Problema extraño con ATTiny10 + avr-gcc: ¿el contador utilizado en ISR está dañado por variables globales?

Tengo un problema muy extraño de una posible corrupción de memoria cuando uso variables globales y una interrupción de desbordamiento del temporizador en ATTiny10 (usando avr-gcc 4.9.2). No puedo entenderlo, pero logré reducirlo a reproducirlo con un programa muy simple:

#include <avr/io.h>

/* Timer overflow counter */
volatile unsigned int ovrf = 0;

/* Some global variables used in main() */
/* (MOVING THESE INTO main() FIXES THE ISSUE) */
unsigned long foo;
unsigned int bar;

int main(void) {
  /* Fast PWM 8 Bit Mode */
  TCCR0A |= _BV(WGM00);
  TCCR0B |= _BV(WGM02);
  /* Enable Timer Overflow Interrupt */
  TIMSK0 |= _BV(TOIE0);
  /* /8 prescaler */
  TCCR0B |= _BV(CS01); // 
  /* PB0 as output */
  DDRB |= _BV(PB0);
  /* Enable interrupts */
  sei();

  for (;;) {
    /* Some random code that uses the global vars */
    /* (REMOVING THIS FIXES THE ISSUE) */
    if (foo > bar) {
      foo = 0;
    }
  }
}

ISR(TIM0_OVF_vect) {
  ovrf++;

  /* Toggle LED (about once per second) */
  if ((ovrf / 500) % 2 == 0) {
    PORTB &= ~(_BV(PB0));      
  } else {
    PORTB |= _BV(PB0);
  }
}

Todo lo que hace es lo siguiente:

• Configura el temporizador y un ISR de desbordamiento del temporizador que incrementa un contador (variable global ovrf) y enciende y apaga un LED según el valor de este contador.
• El bucle principal solo accede a otras dos variables globales (ni siquiera escribe en ninguna parte).

Espero que el LED parpadee periódicamente, lo que demuestra que la interrupción funciona y el contador se incrementa correctamente. Pero no se enciende, o cuando se modifica ligeramente el programa, por ejemplo, al agregar más código o main()más variables, parpadea de forma errática oa un ritmo muy rápido. A partir de esto, después de muchas pruebas, tratando de excluir cualquier otra explicación, asumo que el contador ( ovrf) de alguna manera se está corrompiendo desde el ciclo principal.

Encontré varios cambios que pueden hacer que el problema desaparezca:

• moviendo las dos variables globales ( fooy bar) amain()
• eliminando el código que accede a ellos
• cambiar el tipo de fooaint
• desactivar todas las optimizaciones con -O0(el valor predeterminado era -Os), pero esto hace que el código sea ~1,6 veces más grande.

Pero todavía no puedo ver ninguna explicación sobre la causa real. ¿Me estoy perdiendo por completo algo obvio...? Me he quedado sin ideas y no puedo pensar en otra cosa que no sea un error del compilador, pero eso es muy poco probable, dado que este ejemplo es muy simple.

ACTUALIZAR

Basado en la sugerencia de @MarkU, traté de jugar con varias configuraciones de optimización, tratando de encontrar la opción exacta que podría causar el problema:

• También lo intenté -O1, pero tampoco ayuda.

• ¡ Descubrí que eso -Os -fno-toplevel-reorder también soluciona el problema! -- Sin embargo, sospecho que esto podría ser solo un efecto accidental:

• En mi programa original (muy similar al ejemplo simplificado anterior), donde encontré el problema, nada de lo anterior ayuda (ni siquiera -O0). Allí tengo una variable global más (a bool), y lo único que parece ayudar es eliminar una asignación inicial (por ejemplo, "bool ledOn = true;" --> "bool ledOn;").

Así que definitivamente tiene algo que ver con la forma en que se asignan las variables, pero no simplemente con su tamaño general. (No hay otras dependencias, ni llamadas a funciones, etc.)

ACTUALIZAR 2

Siguiendo el consejo de @Curd, también intenté reemplazar ovrf / 500con ovrf >> 9(más o menos lo mismo, no me importa el tiempo exacto aquí de todos modos). Esto redujo el código en 74 bytes (!), ¡y esto también soluciona el problema!

Eché un vistazo al código desensamblado para el ISR: este cambio reduce la cantidad de bytes pushedal principio de 13 a 7, ¡lo que podría explicar por qué ayuda!

(Esto ovrf / 500solo pretendía ser una prueba rápida y simple para verificar que el ISR estaba funcionando, ¡pero no me di cuenta de que en la implementación real no es tan simple en absoluto! En mi programa original no hay división, mantengo un valor aproximado de milisegundos. cuente simplemente multiplicando ovrfpor 2.)

También comparé el código desensamblado para -Os("malo") y -Os -fno-toplevel-reorder("bueno"), pero aparte de que el código se reordenó al principio, tanto el contenido como main()el ISR parecen iguales (la misma cantidad de pop/pulsaciones, etc.)

--

Parece que puedo solucionar el problema en este ejemplo concreto con una de las soluciones anteriores, pero todavía me siento incómodo por no entender realmente la causa real y no saber cómo evitar esto en el caso general. Y no sé lo suficiente sobre ensamblaje para analizar el código generado.

Tal vez también debería hacer algunas de estas preguntas:

• ¿Este tipo de proceso de prueba y error es "normal" cuando se usa C para ATTiny10? (Quiero decir: no hay suficientes recursos y / o soporte de compilador insuficiente para que esto sea confiable, así que no espere que funcione y simplemente vuelva al ensamblaje si no es así).

• ¿Hay algo que deba evitarse en general (p. ej., no usar vars globales u optimización)?

ACTUALIZAR 3

Gracias por todos los comentarios y respuestas, hay muchas sugerencias útiles en ellos, ¡vale la pena revisarlas todas para cualquiera que tenga un problema similar!

Me quedaba un "misterio" más con mi programa original donde reemplazar a bool ledOn = true;con bool ledOn;era la única solución.

Ahora que entiendo más, eché otro vistazo al ensamblaje generado y al uso de la memoria: resulta que la inicialización hace que el compilador produzca un .datasegmento y se asigna un byte más en la memoria, que está justo por encima del límite para causar una colisión con el pila. Aunque (creo) usa un registro para esta variable al final, al igual que en el caso de "inicialización no explícita", por lo que la asignación adicional no debería ser necesaria. Supongo que el compilador simplemente no tiene optimización para este caso extremo con una cantidad tan pequeña de RAM.