Ich habe sehr lange einen Fehler gesucht, durch den ein steuersystem nach dem Bootlader immer abstürzte. SRAM, Flash, CPU kreuzweise umgelötet, UARTs vom Bus entfernt, alle I/O auf kurzschluss getestet etc.
Am ende war es die Paralell angebundene RTC V3022.
https://www.emmicroelectronic.com/sites/default/files/products/datasheets/3022-DS.pdf
Das hatte ich überhaupt nicht als anfälliges Bauteil auf dem Schirm, zumindest nicht mit crash als Symptom.
Ich habe hier einige mit diesem Fehlerbild, ich gehe bisher davon aus, dass es überall die RTC ist.
Kennt jemand, der aus diesem Zeitalter kommt, dieses Problem? Wodurch passiert das, ist das low-power silizium prozessbedingt empfindlicher? Ist es der komplizierte aufbau mit integriertem Quarz? Es ist keines der berüchtigten batterie-Sram, diese haben einen Goldcap daneben.
Nun, wenn die Software des Systems "crasht", weil die RTC sich unerwartet verhält, dann ist das in erster Linie ein Problem der Software (schlechte bzw. keine Fehlerbehandlung).
Habe es nicht genau geprüft, aber ich denke die defekte RTC könnte nach dem ersten zugriff den Bus Blockieren? Also wenn der low-power teil in der RTC defekt ist und daher das Bus-interface dumme dinge macht?
Aber ja, ohne RTC startet die software auch nicht korrekt.
Insgesamt scheint die Konfiguration der subcomponenten dieses
mikrocontrollers nicht ganz ohne zu sein.
Ach wo, ist wie ein RP2040 mit TPU.
Aber ja, mag ja sein das die RTC irgendwelche unrealistischen Daten liefert, aber wenn es crasht dann ist es sicher auch ein Softwarebug. Mach ein Ticket auf. :-D
Habe es nicht genau geprüft, aber ich denke die defekte RTC könnte nach
dem ersten zugriff den Bus Blockieren?
Warum sollte er. Vom Datenblatt her ist das ein normaler SRAM, d.h. er legt nur Daten auf den Bus bei /RD = 0.
Werden denn die Timings lt. Datenblatt eingehalten?
Vielleicht mal Waitstates einfügen. Viele µCs können das Timing auf dem externen Bus strecken.
Es liegt auf jeden Fall ein Softwarebug vor, d.h. die gelesenen Daten werden nicht geprüft, ob valid.
Ich hab das mal bei einem Notebook erlebt. Der Treiber hat so schöne Zeiten geliefert wie 23:60, 24:59, 24:60, 24:00 und dann ist Windows abgestürzt. Man mußte das Notebook kurz vor Mitternacht zuklappen, damit es weiter lief.
Allenfalls ist die Batterie der RTC alle ? Das waer zumindest mit einer externen Baterie behebbar.
Allenfalls ist das Datum ausserhalb des Bereiches ? Datum neu stellen, zB auf genau 40 Jahre zurueck
Ich habe sehr lange einen Fehler gesucht, durch den ein steuersystem
nach dem Bootlader immer abstürzte. SRAM, Flash, CPU kreuzweise
umgelötet, UARTs vom Bus entfernt, alle I/O auf kurzschluss getestet
etc.
Am ende war es die Paralell angebundene RTC V3022.
Mit der Software hast du dich nicht beschäftigt? Dann wirst du viele Fehler niemals finden können.
Habe es nicht genau geprüft, aber ich denke die defekte RTC könnte nach
dem ersten zugriff den Bus Blockieren?
Ausnahmsweise ist es hier vielleicht besser, nicht einfach nur zu denken
(was hier sowieso nur "glauben" heißt), sondern eben mal genau
prüfen/messen.
Außerdem sollte man sich, wenn man schon einen Chip in Verdacht hat, sich dessen Spannungsversorgung genau anschauen. Eine "gestörte" Versorgung ist immer gut für komische Effekte.
Versorgungsspannungen prüfen, diverse Spannungspegel auf 'Sauberkeit' prüfen. (Eindeutiges H oder L)
Wenn das alles sauber ist:
Kommt, nachdem die RTC ein /CS bekommt ein /DTACK oder /VPA zum 68k zurück?
Wenn ja: An welcher (RTC)Adresse setzt die Kommunikation aus?
Und wenn nicht, bleibt /BERR aus?
Dann bei der /BERR-Erzeugung suchen.
Kommt, nachdem die RTC ein /CS bekommt ein /DTACK oder /VPA zum 68k
zurück?
Hat der RTC nicht, der hat nur ein ganz normales Intel MMIO (/CS, /RD, /WR).
Da kann nichts weiter zurück kommen außer den Lesedaten. Und wenn das Timing nicht stimmt, kommt eben Garbage.
wir hatten mal ein Latch-Up-Problem mit einer RTC. Ist jedoch schon lange her und passt vermutlich nicht zum hier beschriebenen Fehlerbild. Wollte es trotzdem mal in die Runde werfen.
IMG20250206204409.jpg
(240 KB)
