Telexforum.de

FredSonnenrein hat geschrieben: ↑Sa 22. Feb 2020, 13:02 Wenn nur eine der Schnittstellen betroffen ist, dann wird es der Chip sein. Falls das Problem auch auf anderen Schnittstellen vorkommt, wäre sowas wie Störeinflüsse von der Stromversorgung denkbar.

Stromversorgung - auch möglich. Werde mal die ATmegas der beiden Schnittstellen kreuztauschen. Mal sehen, ob der Fehler mitwandert.

Noch etwas: Es scheint kein Timeout zu geben, wenn die EEPROM-Fehlermeldung auf einer Schnittstelle auftritt; blöd, wenn an der betreffenden Schnittstelle kein FS angeschlossen ist (Leitungsrelais bleibt gezogen). Nach 2 Minuten Wartezeit habe ich die Situation durch Ausschalten aufgelöst.

So - nach Kreuztausch der ATmegas und entsprechender Konfig-Änderung (Rufnummern getauscht) arbeiteten bei ATmegas erst einmal unauffällig - mehrere Restarts verliefen ohne EEPROM-Fehler. Bis dann irgendwann beim x-ten Versuch der ATmega an Schnittstelle#2 (= der potentiell defekte) doch wieder einen EEPROM-Fehler schmiss. Ich schiebe es nun doch eher auf den ATmega (der aktuell auf #2 steckt).

Also nochmal ausgeschalten - doch nun startete Schnittstelle#2 mit einer falschen Nebenstellennummer (diese hatte auf einmal die "11" statt vorher "22"). Die "11" gehört aber zu Schnittstelle#1 - daraufhin blinkte Schnittstelle#1 rot (und hatte fortan die Rufnummer "0"). Ist dieses Verhalten von ATmega#1 (Änderung zu "0") so korrekt bzw. nachvollziehbar? Oder wurde die Konfiguration von ATmega#1 ebenfalls beschädigt?

Gruß,
Thomas

BanditDD hat geschrieben: ↑Sa 22. Feb 2020, 18:05 So - nach Kreuztausch der ATmegas und entsprechender Konfig-Änderung (Rufnummern getauscht) arbeiteten bei ATmegas erst einmal unauffällig - mehrere Restarts verliefen ohne EEPROM-Fehler. Bis dann irgendwann beim x-ten Versuch der ATmega an Schnittstelle#2 (= der potentiell defekte) doch wieder einen EEPROM-Fehler schmiss. Ich schiebe es nun doch eher auf den ATmega (der aktuell auf #2 steckt).

Es gibt zwei Fehler: einen mit dem Text "warnung lesefehler" und einmal "schwerer lesefehler".
Bei dem ersten hatten zwei der drei Speicherstellen wenigstens den gleichen Inhalt (dieser gewinnt dann), bei der anderen Variante sind drei unterschiedliche Werte gefunden worden, dann wird ein Standardwert verwendet, z.B. 11 für die Nebenstellennummer. Dieser Standardwert wird aber auch gleich ins EEPROM geschrieben. Das muss ich ggf. nochmal überdenken.

BanditDD hat geschrieben: ↑Sa 22. Feb 2020, 18:05 Also nochmal ausgeschalten - doch nun startete Schnittstelle#2 mit einer falschen Nebenstellennummer (diese hatte auf einmal die "11" statt vorher "22"). Die "11" gehört aber zu Schnittstelle#1 - daraufhin blinkte Schnittstelle#1 rot (und hatte fortan die Rufnummer "0"). Ist dieses Verhalten von ATmega#1 (Änderung zu "0") so korrekt bzw. nachvollziehbar? Oder wurde die Konfiguration von ATmega#1 ebenfalls beschädigt?

Weil #2 die 11 (default) bekommen hat und #1 eine Mikrosekunde langsamer war, hat #1 gemerkt dass bereits eine 11 vergeben ist und hat auf "nix" umgeschaltet. In diesem Fall bleibt aber das EEPROM unverändert und nach "korrigieren" der #2 hätte #1 wieder normal hochstarten müssen.

FredSonnenrein hat geschrieben: ↑Sa 22. Feb 2020, 18:57 Es gibt zwei Fehler: einen mit dem Text "warnung lesefehler" und einmal "schwerer lesefehler".
Bei dem ersten hatten zwei der drei Speicherstellen wenigstens den gleichen Inhalt (dieser gewinnt dann), bei der anderen Variante sind drei unterschiedliche Werte gefunden worden, dann wird ein Standardwert verwendet, z.B. 11 für die Nebenstellennummer. Dieser Standardwert wird aber auch gleich ins EEPROM geschrieben. Das muss ich ggf. nochmal überdenken.

Da #2 die "11" verpasst bekam, gehe ich davon aus, dass es zu einem schweren Lesefehler in EEPROM#2 gekommen sein muss :-/

Wird bei einer Warnung der EEPROM-Inhalt neu geschrieben (mit den 2-aus-3-Daten), um alle Speicherbereiche wieder glattzuziehen? Ich kann mir nicht erklären, warum es nach einer EEPROM-Warnung + Neustart manchmal auch wieder ohne EEPROM-Warnung klappt. Oder wird das EEPROM generell nur bei einem Aufruf des Konfigurationsmodus geschrieben?

Weil #2 die 11 (default) bekommen hat und #1 eine Mikrosekunde langsamer war, hat #1 gemerkt dass bereits eine 11 vergeben ist und hat auf "nix" umgeschaltet. In diesem Fall bleibt aber das EEPROM unverändert und nach "korrigieren" der #2 hätte #1 wieder normal hochstarten müssen.

Ok, da war ich zu voreilig - ich habe erst #1 auf was völlig anderes gesetzt, dann #2 zurück auf "22" korrigiert um schlußendlich #1 auf die ursprüngliche "11" zu setzen. Bei #2 war übrigens nicht nur die Rufnummer auf "11" gesetzt, sondern zusätzlich auch noch die Sperrzeiten verschoben:

Sperrzeit a
von 2200 (ok)
bis 2200 (nok, sollte '0600' sein)

Sperrzeit b
von 2015 (ok)
bis 2015 (nok, sollte '0830' sein)

Ich denke, der ATmega hat nen Treffer ...

Gruß,
Th.

BanditDD hat geschrieben: ↑Sa 22. Feb 2020, 19:16

FredSonnenrein hat geschrieben: ↑Sa 22. Feb 2020, 18:57 Es gibt zwei Fehler: einen mit dem Text "warnung lesefehler" und einmal "schwerer lesefehler".
Bei dem ersten hatten zwei der drei Speicherstellen wenigstens den gleichen Inhalt (dieser gewinnt dann), bei der anderen Variante sind drei unterschiedliche Werte gefunden worden, dann wird ein Standardwert verwendet, z.B. 11 für die Nebenstellennummer. Dieser Standardwert wird aber auch gleich ins EEPROM geschrieben. Das muss ich ggf. nochmal überdenken.

Da #2 die "11" verpasst bekam, gehe ich davon aus, dass es zu einem schweren Lesefehler in EEPROM#2 gekommen sein muss :-/

Wird bei einer Warnung der EEPROM-Inhalt neu geschrieben (mit den 2-aus-3-Daten), um alle Speicherbereiche wieder glattzuziehen? Ich kann mir nicht erklären, warum es nach einer EEPROM-Warnung + Neustart manchmal auch wieder ohne EEPROM-Warnung klappt. Oder wird das EEPROM generell nur bei einem Aufruf des Konfigurationsmodus geschrieben?

Bei einer Warnung und bei einem Fehler wird das EEPROM wieder beschrieben, so dass die Warnung / der Fehler tatsächlich beim nächsten Reset verschwinden sollte.
Es gibt übrigens auch den Schreibfehler, der dann ausgelöst wird, wenn nach dem Schreiben sofort wieder falsche Daten zurückgelesen werden.

BanditDD hat geschrieben: ↑Sa 22. Feb 2020, 19:16

Weil #2 die 11 (default) bekommen hat und #1 eine Mikrosekunde langsamer war, hat #1 gemerkt dass bereits eine 11 vergeben ist und hat auf "nix" umgeschaltet. In diesem Fall bleibt aber das EEPROM unverändert und nach "korrigieren" der #2 hätte #1 wieder normal hochstarten müssen.

Ok, da war ich zu voreilig - ich habe erst #1 auf was völlig anderes gesetzt, dann #2 zurück auf "22" korrigiert um schlußendlich #1 auf die ursprüngliche "11" zu setzen. Bei #2 war übrigens nicht nur die Rufnummer auf "11" gesetzt, sondern zusätzlich auch noch die Sperrzeiten verschoben:

Sperrzeit a
von 2200 (ok)
bis 2200 (nok, sollte '0600' sein)

Sperrzeit b
von 2015 (ok)
bis 2015 (nok, sollte '0830' sein)

Ich denke, der ATmega hat nen Treffer ...

Gruß,
Th.

Sieht so aus...

Nur kurz zur Info: ein neuer ATmega168 an der betreffenden Schnittstelle funktioniert nun einwandfrei - offensichtlich hat die neue Prüfroutine einen fehlerhaften EEPROM identifziert.

Moins,

ich habe ja nun auch TW 39 PLUS und bin sehr zufrieden damit, ich habe zwar Fred seine Unterstüzung gebraucht, weil wie kann ich richten das meine Chips zu klein waren, aber ich habe dann neue bestellt in der richtigen Größe, ich mußte zwar 2 brennen auf die blanken Chips, aber dann waren sie willig. Es gab noch einen kleinen Formulierungsfehler bei der Automatischen Vorwahl, aber Fred hat es wohl schon bereinigt, aber wir müssen ja nicht überperfekt sein, denn wir sind hier im Hobby und nicht im OP-Saal.