Vorgehen bei Fehlersuche

Nofalls den ganzen EEprom-Bereich mit einer Testsoftware in der Umgebung beschreiben.
Aufwärtszählen z.B. und die Daten nach einander mit etwas Abstand an zwei unterschiedlichen Adressen speichern.
Anschließend die entspr. Daten in einer Schleife wieder lesen und subtrahieren -> das Ergebnis prüfen.

Hab ich richtig in Erinnerung, du hast das Programm umgebaut auf state machine? Und vorher ging alles? Dann liegt's ja nicht an der eram hardware, wo jetzt ja grad gesucht wird. Es ist einfach ein Programmierfehler , der bei der Umschreibung entstanden ist. Warum hast du ein funktionierendes Programm umgebaut?

Die Umsetzung in eine Statemachine war schon die richtige Entscheidung. Den Grund haste ja eben genannt.
Und ich würde auch dabei bleiben.

Aber du hast irgendwo bei der Umsetzung einen Fehler gemacht.
Vielleicht die States nicht korrekt definiert oder zu viel in einen State gepackt.

Kann auch sein, dass du die Übergangsbedingungen an den falschen Stellen auswertest. Die gehören in die States (Cases) rein.

Vielleicht zeigst du mal die Schleife, in der die States abgehandelt werden und wo die tastenabfrage eingreift, um den State zu ändern.

Ich beziehe mich auf den Eröffnungs-post: ein Tausch der Platine ist nicht möglich?

Du hast das Glück, dass du ein funktionierendes Duplikat hast. Drum würde ich, an deiner Stelle, mit dem Tauschen anfangen. Wenn beide Platinen wirklich gleich sind und auch das Programm darauf, dann testen, ob sich die Platinen auch genau gleich verhalten. Wandert der Fehler auf den Schreibtisch, ist die Platine schuld. Bleibt der Fehler im Fahrzeug, ist die Umgebung schuld. Läge es am Programm, müsste der Fehler ja überall auftreten.

Wie ich es mir gedacht habe.
Statemachine ist fehlerhaft umgesetzt!

In der Do Loop
Fragst du zwar die States ab.
Aber außerhalb der Select Case Struktur (Statemachine) fragst du die Tasten ab und hast anderen Code, der die States ändert.
Da wird das Problem seine Wurzel haben. Die Zustandswechsel gehören immer in die entsprechenden Zustände.

In der Schleife mit der Statemachine darf im Grunde nur die Select case Struktur sein. Aller Code muss in die Cases und zwar zum richtigen Case.
So wie es jetzt ist wird in der select case vielleicht ein State geändert und nach der Select Case Struktur änderst du es wieder.
Das kann zu unerwartetem Verhalten der Steuerung führen und könnte der Grund für dein Problem sein.

Genau das soll die Statemachine ja verhindern.
Außerhalb der Select Case gehört nur das, was du in jedem State im Loop Code ausführen müsstest.

Ziel der Statemachine ist ja, dass du dein Steuerprozess in Zustände aufgliederst.
Und jeder Zustand hat eine Teilaufgabe im Prozess. Und da sind bestimmte Ereignisse (Taster-Abfragen oder ADC-Abfragen z.B.) in einzelnen Zustanden vielleicht nicht relevant.
Deswegen teilt man das ja auf. Das macht den Code übersichtlicher und auch wartbar.
Fehlersuche gehört auch zur Wartung!
Ist der Code sauber gegliedert, findet sich recht schnell der kleine Code-Teil, der als Ursache für Probleme in Betracht kommt.
Zumindest wenns am Code liegt.

Verstehst du was ich meine?

Im Übrigen sind deine Tastenabfragen syntaktisch falsch.

So nicht:
Sub Taster_ab:
..
End Sub

Sondern so:

Sub Taster_ab()
..
End Sub.

Der Compiler meckert vielleicht nicht, aber du weißt nicht, was er dann compiliert!
Das solltest du korrigieren.

Lass auch mal den Codeexplorer drüber schauen, ob der was sieht und das auch berichtigen.

Ich möchte einmal auf das wichtigste hin weisen. Das Bordnetz eines Fahrzeuges ist das sinngemäß schlimmste das man sich vorstellen kann.
Hier ein Link dazu: mk4-wiki.denkdose.de/artikel/kfz-bordnetz/start

Es wäre empfehlenswert, dieses Bordnetz genauer zu analysieren und die Platine darauf anzupassen. Zumindest mal ins Auge fassen, dass dieses Bordnetz
kein Labornetzteil ist, sondern eine Unmenge Störungen beinhalten kann. Klar ist, was auf dem Tisch störungsfrei funktioniert, hat eine ganz andere Stromversorgung! Wer ein Scope besitzt, sollte sich mal das Bordnetz eines Fahrzeuges anschauen. Eventuell auch mal genauer die Platinen-Stromversorgung unter Bordnetzbedingungen anschauen und so anpassen, dass ein möglichst sicherer Betrieb möglich ist.

Das kommt drauf an.

Erstens muss man nicht diesen Code in alle States einfügen.
Typischerweise würde man den Code dann in einer Sub bereit stellen und wurde dann von den States aus einfach einen Call machen.

Die Frage ist doch, ob du in jedem State alle Tasten prüfen musst. Und die Antwort ist normalerweise nein.

Aber Code, der von jedem Zustand immer ausgeführt werden müsste, kann natürlich außerhalb der Select case Struktur sein.
Aber der sollte nicht die States verändern.

Nur innerhalb der States werden nur genau die relevanten Bedingungen geprüft, die notwendig sind, um dann die Zustandsänderung zu machen.
Das macht man auch nicht in einer Tastenabfrage wie in deinem Beispiel, oder in Routinen außerhalb der Select case struktur.

Wenn du in dem State Zündung_Aus bist, macht es ja keinen sinn die Tasten hoch oder runter zu prüfen, oder?
Genau das meine ich.

Und wenn du "Taste Hoch" prüfst dann wird dort auch kein State geändert.

Die Prüfung einer Taste sollte lediglich zurück liefern, ob die Taste betätigt wurde oder nicht. Sie sollte keine Aktionen auslösen wie Effekte oder Zustandsänderungen.
Wenn du Aktionen brauchst, dann prüfe in einem zustand (Case) die Taste und wenn die Bedingung erfüllt ist, rufst du diesen Effekt per Call von dem State aus auf.

Die Steuerung ist in die Select Case-Struktur eingebettet und nicht im Code und verschiedenen Routinen verteilt.
So machst du dein Programm nur unübersichtlich und verstehst selber nicht, wie die Abläufe im Programm sind.

Deshalb Zustandsänderungen nur in der Select case Struktur. Die Bedingungen dazu in dem State prüfen und wenn die zutrifft, dann den zustand dort ändern.

So ist das ganze Wirkprinzip.

Eine Select Case Struktur bildet immer einen Prozess ab, der in sich quasi geschlossen ist.
Wenn du sowas in eine eigene Sub packst, z.B. ProzessNivellierung(),
brauchst du die nur in der Hauptschleife aufrufen.
Weitere Calls auf andere Prozesse können dann viele Prozesse quasi parallel laufen lassen.

Aber auch ein Lob an dich.
Du hast es gewagt, auch mal was neues zu probieren.
Wenn du das erst mal richtig durchstiegen hast wirst du selber feststellen, dass plötzlich die Programmabläufe stabiler laufen und besser zu kontrollieren sind.
Leider hast du dir zur "Übung" nicht gerade ein Einsteiger-Projekt ausgesucht.

Aber bleib dran!