ALU-, RAM- und ROM-Test für LPC 1778

Ich arbeite an einem Nicht-Sicherheitsprojekt und wollte im Rahmen der Initialisierungstests den internen Speicher des LPC1778 auf ordnungsgemäße Funktionalität überprüfen, bevor ich mit der Anwendung beginne.

Ich beabsichtige nicht, alle Adressen zu testen, da dies für die Anwendung nicht möglich ist. Ich plane, diesen 3-in-1-Test (ALU, RAM und ROM) folgendermaßen zu implementieren:

1. Speichern Sie ein Array von 32 Zahlen im ROM (const array), dessen Mitgliedswerte Potenzen von 2 sind. Beispiel -> 1,2,4,8 ... bis zu 2 Potenzen 32 (da LPC1778 einen 32-Bit-Datenbus hat)

2. Lesen Sie diese Werte aus dem ROM (konstantes Array) und schreiben Sie sie in ein Array der Größe 32, das sich im RAM befindet (nicht konstantes Array, das auf dem Stapel zugewiesen wird, indem eine Funktion aufgerufen wird, die ein solches Array lokal deklariert).

3. Vergleichen Sie jeden Wert im lokalen Array mit einem Wert, der von der ALU berechnet wurde (bitweise Verschiebung nach links).

Reicht dies zum Testen aus oder muss ich auch prüfen, ob der Adressbus kurzgeschlossen ist (wenn sie kurzgeschlossen sind und ich versuche, an eine ungültige Stelle zu schreiben, wird der Ausnahmehandler nicht ausgelöst?) Muss ich auch nach anderen
Operationen der ALU suchen, wie z Addition, Subtraktion, NICHT, XOR usw. Ich habe auch die Code-Prüfsumme in einem externen Flash gespeichert, mit dem verglichen wird, indem sie während der Laufzeit im Code berechnet wird. (Prüfsumme im Code berechnet==Prüfsumme aus Flash gelesen)

Irgendwelche Vorschläge. Bitte helfen Sie.

Ich verwende Keil IDE.

Antworten (2)

Wovor hast du Angst? Dass eine interne Route zwischen Gates innerhalb des Chips unterbrochen oder kurzgeschlossen wird? Wenn dies der Fall wäre, würde dies sicherlich bedeuten, dass der Chip physisch kaputt war. Ich meine, gebrochen wie in "wegen thermischer Belastung in zwei Hälften geteilt". In diesem Fall würde es überhaupt nicht funktionieren. Was Sie hier zu testen versuchen, ist es nicht wert, die Wahrscheinlichkeit, dass eine interne Spur falsch ist, ist mehr als unwahrscheinlich.

Wahrscheinlicher wären Single-Event-Upset , die Sie nicht durch vorheriges Testen verhindern können (und die sowieso sehr schwierig zu handhaben sind, Sie würden wahrscheinlich einen Lock-Step-Core und ECC-Speicher benötigen).

Verwenden Sie schließlich etwas CRC für kritische Daten im Speicher, um zu reagieren, falls sie beschädigt werden. Das ist das Beste, was Sie tun können.

Lock-Step-Kern und ECC-Speicher => RMxx-Serie von TI-Typen??
Ja, diese Art von MCU. Aber Sie möchten sich nicht die Mühe machen, dies für ein "Nicht-Sicherheitsprojekt" zu verwenden, wie Sie erwähnt haben. Denn es wird sehr schnell kompliziert. Treten Sie einfach einen Schritt zurück und prüfen Sie, was im schlimmsten Fall passieren kann, wenn Ihr System ausfällt. Wenn es nicht „jemand wird verletzt“ heißt, machen Sie es einfach.
Ja danke. Es reicht also aus, die oben genannten Dinge zu tun, oder?
Ich weiß nicht, was Ihre Anwendung ist, das haben Sie nicht erklärt. Ich kann also nicht erraten, welche Prüfungen in Ihrem Fall angemessen sind. Wenn Sie einen MP3-Player bauen, führen Sie überhaupt keine Überprüfung durch, nicht einmal einen CRC, es ist in Ordnung. Wenn Sie ein zugangskontrolliertes Türschloss herstellen, möchten Sie möglicherweise einen CRC auf die Seriennummern der Tags setzen, die Sie zulassen. Andernfalls können Sie, wenn etwas beschädigt wird, einer unbefugten Person den Zutritt gestatten. Wenn Sie einen Flugschreiber bauen, der in eine Boeing passt, verwenden Sie RMxxx. Sie sollten in der Lage sein, selbst zu sagen (vor allem, da Sie uns nicht gesagt haben, was Sie entwerfen).

Speicherprüfung: Führen Sie eine CRC über den gesamten Speicherinhalt aus, mit Ausnahme der Stelle, an der Sie den erwarteten Wert speichern, und bestimmen Sie den erwarteten Wert während der Erstellungszeit. Da der erwartete Wert für jeden Build unterschiedlich ist, würde dies auch unvollständig geschriebene Firmware abfangen (was weitaus wahrscheinlicher ist als ein defekter Speicher).

ALU-Check: eigentlich sinnlos. Eine erschöpfende Überprüfung wäre eine Menge Code, und eine schnelle Überprüfung würde wahrscheinlich etwas übersehen. Ohne Kenntnis der internen Beschaltung wüssten Sie nicht, welche Tests sinnvoll sind (zB das Hinzufügen von 0x55555555 zu 0x55555555, um auf versehentlich verbundene Nachbarbits zu prüfen, funktioniert nur, wenn die eigentliche Implementierung nicht interleaved ist). Die ALU wird im Werk getestet, sowohl mit einer optischen Inspektion vor dem Verpacken als auch mit einem Test, der für das physische Layout, das sie hat, geeignet ist.

ALU-, RAM- und ROM-Test für LPC 1778
AntwortenHierDatenschutz-Bestimmungen1y, 0v