Seltsames Problem mit ATTiny10 + avr-gcc: in ISR verwendeter Zähler durch globale Variablen beschädigt?

Ich habe ein sehr seltsames Problem einer möglichen Speicherbeschädigung bei der Verwendung globaler Variablen und eines Timer-Überlauf-Interrupts auf dem ATTiny10 (mit avr-gcc 4.9.2). Ich kann keinen Sinn daraus machen, habe es aber geschafft, es auf die Reproduktion mit einem sehr einfachen Programm einzugrenzen:

#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);
  }
}

Alles, was es tut, ist Folgendes:

• Richtet den Timer und eine Timer-Überlauf-ISR ein, die einen Zähler (globale Variable ovrf) erhöht und eine LED basierend auf dem Wert dieses Zählers ein- und ausschaltet.
• Die Hauptschleife greift nur auf zwei andere globale Variablen zu (schreibt nicht einmal irgendwo hin).

Ich würde erwarten, dass die LED regelmäßig blinkt, was beweist, dass der Interrupt funktioniert und der Zähler korrekt inkrementiert wird. Aber es schaltet sich nicht ein -- oder wenn das Programm leicht modifiziert wird, zB mehr Code oder main()mehr Variablen hinzugefügt werden -- blinkt es unregelmäßig oder mit einer sehr schnellen Rate. Daraus gehe ich nach vielen Tests und dem Versuch, jede andere Erklärung auszuschließen, davon aus, dass der Zähler ( ovrf) irgendwie von der Hauptschleife beschädigt wird.

Ich habe mehrere Änderungen gefunden, die das Problem verschwinden lassen können:

• Verschieben der beiden globalen Variablen ( foound bar) inmain()
• Entfernen des Codes, der auf sie zugreift
• Ändern des Typs von fooinint
• Deaktivieren Sie alle Optimierungen mit -O0(der Standardwert war -Os), aber das macht den Code ~1,6x größer.

Aber ich kann immer noch keine Erklärung für die tatsächliche Ursache sehen. Übersehe ich etwas Offensichtliches völlig ...? Mir gehen die Ideen aus und mir fällt nichts anderes ein als ein Compiler-Fehler, aber das ist sehr unwahrscheinlich, da dieses Beispiel so einfach ist.

AKTUALISIEREN

Basierend auf dem Vorschlag von @MarkU habe ich versucht, mit verschiedenen Optimierungseinstellungen zu spielen, um die genaue Option zu finden, die das Problem verursachen könnte:

• Auch probiert -O1, hilft aber auch nicht

• Ich fand, dass das -Os -fno-toplevel-reorder auch das Problem behebt! -- Ich vermute jedoch, dass dies nur ein zufälliger Effekt sein könnte:

• In meinem ursprünglichen Programm (sehr ähnlich dem obigen vereinfachten Beispiel), in dem ich das Problem gefunden habe, hilft keines der oben genannten Dinge (nicht einmal -O0). Dort habe ich eine weitere globale Variable (a bool), und das einzige, was zu helfen scheint, ist, eine anfängliche Zuweisung (z. B. "bool ledOn = true;" --> "bool ledOn;") zu entfernen.

Es hat also definitiv etwas damit zu tun, wie Variablen zugewiesen werden, aber nicht nur mit ihrer Gesamtgröße. (Es gibt keine weiteren Abhängigkeiten, keine Funktionsaufrufe etc.)

AKTUALISIERUNG 2

Dem Rat von @Curd folgend, habe ich auch versucht, ovrf / 500durch zu ersetzen ovrf >> 9(ungefähr dasselbe, das genaue Timing interessiert mich hier sowieso nicht). Dadurch wurde der Code um 74 Bytes (!) reduziert – und dies behebt auch das Problem!

Ich habe mir den disassemblierten Code für die ISR angesehen: Diese Änderung reduziert die Anzahl der Bytes pushedam Anfang von 13 auf 7, was erklären könnte, warum es hilft!

(Dies ovrf / 500sollte nur ein schneller und einfacher Test sein, um zu überprüfen, ob die ISR funktioniert, aber ich wusste nicht, dass es in der tatsächlichen Implementierung überhaupt nicht so einfach ist! In meinem ursprünglichen Programm gibt es keine Division, ich behalte eine ungefähre Millis zählen, indem Sie einfach ovrfmit 2 multiplizieren.)

Ich habe auch den zerlegten Code für -Os("schlecht") und -Os -fno-toplevel-reorder("gut") verglichen, aber abgesehen davon, dass der Code am Anfang neu geordnet wird, main()scheinen sowohl der Inhalt von als auch die ISR gleich zu sein (gleiche Anzahl von Pop/Pushes usw.)

--

Anscheinend kann ich das Problem in diesem konkreten Beispiel mit einem der oben genannten Workarounds beheben, aber ich fühle mich immer noch unwohl, wenn ich die eigentliche Ursache nicht wirklich verstehe und nicht weiß, wie ich dies im allgemeinen Fall vermeiden kann. Und ich weiß nicht genug über Assembler, um den generierten Code zu analysieren.

Vielleicht sollte ich auch einige dieser Fragen stellen:

• Ist diese Art von Trial-and-Error-Prozess "normal", wenn C für ATTiny10 verwendet wird? (Ich meine: nicht annähernd genug Ressourcen und / oder unzureichende Compiler-Unterstützung, um dies zuverlässig zu machen - erwarten Sie also nicht, dass es funktioniert, und kehren Sie einfach zur Assembly zurück, wenn dies nicht der Fall ist?)

• Gibt es etwas, das generell vermieden werden sollte (z. B. keine Verwendung globaler Variablen oder Optimierung)?

AKTUALISIERUNG 3

Vielen Dank für all die Kommentare und Antworten, sie enthalten viele nützliche Vorschläge, die es wert sind, alle für alle zu überprüfen, die auf ein ähnliches Problem stoßen!

Ich hatte noch ein weiteres "Mysterium" mit meinem ursprünglichen Programm, bei dem das Ersetzen von a bool ledOn = true;durch bool ledOn;die einzige Lösung war.

Jetzt, da ich mehr verstehe, habe ich mir die generierte Assembly und die Speichernutzung noch einmal angesehen: Es stellt sich heraus, dass die Initialisierung den Compiler dazu bringt, ein .dataSegment zu produzieren und ein weiteres Byte im Speicher zugewiesen wird, was knapp über der Grenze liegt, um eine Kollision mit zu verursachen Stapel. Obwohl (glaube ich) am Ende ein Register für diese Variable verwendet wird, genau wie im Fall "keine explizite Initialisierung", sollte die zusätzliche Zuordnung nicht erforderlich sein. Ich denke, der Compiler hat einfach keine Optimierung für diesen Extremfall mit so wenig RAM.