Jedoch gibt es offensichtlich einen nicht logisch erklärbaren Abhängigkeitseffekt.
Bin eben auf ein ähnliches Problem gestoßen ...
Und bei der Fehlersuche, bin ich auch näher an dieses, dein Timerproblem heran gekommen.
Leider ist meine jetzige Ansage auch nur eine Hypothese.
Denn die Innereien des AVR Timers sind geheim.
Wir haben nur das Datenblatt.
Grundsätzlich, kann man den Timer als endlichen Automaten betrachten.
Eben nicht in Software, sondern in Hardware gegossen.
Und genau diesen Automaten bringst du in einen ungültigen Zustand, aus dem er sich mehr befreien kann.
Also meine Erkenntnis:
Das Problem besteht aus einer Kombination von 2 Gegebenheiten!
Erstens:
Der Timer befindet sich in Mode 1
Zweitens:
Es wird OCR2A = 249 gesetzt und sofort darauf der Timer in Mode 2 versetzt.
Das crashed.
Warum kommt der Automat dabei aus dem Tritt?
Im Mode 1 wirkt OCR2A = 249 nicht auf dem Register direkt ausgeführt, sondern der Wert wird erst in ein Schattenregister geschrieben und beim Timer Überlauf dann ins Vergleichsregister.
OCR2A = 249 ist also nur ein Auftrag, der zur späteren Ausführung im Timer hinterlegt wird.
Im Mode 2 gibt es dieses Schattenregister nicht.
Erfolgt die Umschaltung von Mode 1 zu Mode 2 zu schnell, kann der Auftrag nicht ausgeführt werden, und der Timer bleibt hängen, der ganze AVR bleibt stehen.
Abhilfe 1:
Erst den Mode einstellen, und dann OCR2A setzen.
Abhilfe 2: (zum testen)
Nach OCR2A = 249 ein delay() einfügen, so dass der endliche Automat im Timer, die Chance bekommt den Auftrag auszuführen.
Es ist also der klemmende Auftrag, welcher den Timer/AVR ermordet.
Ich behaupte, das betrifft alle AVR mit diesem Schattenregister.
-----
Reicht dir das als Erklärung?