Forum: Mikrocontroller und Digitale Elektronik MSP430: Selbsttest von RAM und Flash ?


von Arvid Teichtmann (Gast)


Lesenswert?

Hallo zusammen,

für einem MSP430F149 möchte ich in C einen Einschalt-Selbsttest
programmieren, der nach dem Einschalten den RAM komplett durchtestet
(also alle Zellen beschreibt, ausliest und wieder löscht) und den
Programm-Flash mit einer crc16 Checksumme überprüft (also ob
irgendwelche Bits gekippt sind bzw. der Programmcode sich
unbeabsichtigt geändert hat).
Beim RAM-Selbsstest besteht das Problem, das ich ja alle Variablen
überschreiben würde, die schon im RAM angelegt sind.
Hat jemand sowas schon Mal gemacht und kann mir dazu ein paar Tipps,
Beispiele oder Links weitergeben?
Danke für alle Hinweise.

Gruss
Arvid

von Peter D. (peda)


Lesenswert?

Wozu ?

Macht TI die Fab-Tests nicht richtig und verkauft Ausschußware ?

Die Fab-Tests sind wesentlich strenger als Du es mit einer Routine
machen könntest. Die Routine hätte also Null-Aussage.

Bei externen RAM / Flash könnte man so wenigstens Leiterplattenfehler
erkennen, aber doch nicht im internen RAM / Flash.


Peter

von Arvid Teichtmann (Gast)


Lesenswert?

Es geht mir nicht darum, die neuen Chips zu testen, es geht mir darum,
zu prüfen, ob sich mein Programm unbeabsichigt verändert hat und ob
einen RAM-zelle defekt ist.

> Die Routine hätte also Null-Aussage.
Falsch, ein Flash kann im Laufe der Zeit durchaus seinen Speicherinhalt
verändern (ein Bit kippt). Das ist sehr unwahrscheinlich, aber nicht
ausgeschlossen. Der Hersteller garantiert auch nur eine bestimmte
"Lebenszeit" der Programmspeicherinhalte.
In (m)einer kritischen Applikation muss deshalb der Programmspeicher
bei jedem Selbsttest überprüft werden.

> aber doch nicht im internen RAM / Flash.
...wieso nicht, Dein PC macht auch bei jedem Booten einen RAM Test.
Auch im RAM kann eine Speicherzelle defekt sein. Das muss ich auf jeden
Fall auch abfangen. Auch wieder sehr unwahrscheinlich, aber nicht
ausgeschlossen...

Gruss
Arvid

PS: Ich entwickle keine Gameboys :-)

von Peter D. (peda)


Lesenswert?

Der RAM-Test im PC testet aber nur den externen Speicher, d.h. wo noch
ne Menge Leiterzüge IS-Fassungen und andere Chips dazwischen sind, die
Ärger machen können.
Die internen Register und Cache werden aber nicht getestet.


Ein Flash kann sich ändern, das stimmt schon. Bloß warum soll sich
ausgerechnet die Testroutine nicht ändern ?

Sinnvoll ist es daher vor allem anderen erstmal zu verhindern, daß sich
der Flash überhaupt ändert. Also stabile Stromversorgung, EMV-gerechtes
Layout, Brown-Out-Reset, Lock-Bits setzen usw.


Ich kenne jetzt den MSP nicht genau, aber manche MC habe einen
Bootbereich, der z.B. nur durch einen externen Programmer mit 12V
Programmierspannung änderbar ist (z.B. T89C51CC01).
Dieser Bootbereich ist dadurch unempfindlicher gegen unbeabsichtigte
Änderungen und der könnte dann einen CRC-Test auf dem User-Flash
ausführen.


Ich habe nur einen Flash CRC-Test für den 8051 in Assembler, wird dir
also nichts nützen.
Der hat dort aber vor allem die Aufgabe, nach einem Abbruch während
eines Updates die Ausführung eines defekten Programms zu verhindern und
statt dessen sofort wieder in den Bootloader zu springen.


Peter

von Schmittchen (Gast)


Lesenswert?

> Beim RAM-Selbsstest besteht das Problem, das ich ja alle Variablen
überschreiben würde, die schon im RAM angelegt sind.

Zum Zeitpunkt des Tests ist das RAM noch nicht initialisiert - also
gibts da nicht viel zu überschreiben (außer ein bisschen Stack - den
also aussparen).

> PS: Ich entwickle keine Gameboys :-)
Automobilbranche? Dort ist sowas nämlich üblich - auch bei internem
RAM.

Schmittchen.

von Oryx (Gast)


Lesenswert?

Hallo Arvid,
hast Du dir schon mal die Startup-Dateien angesehen?
Sie heissen crt0.o oder so ähnlich. Darin wird das Ram initialisiert.
Wenn Du dir dort Deine eigenen Dateien schreibst und mit -nostartfiles
linkst, hast Du den vollen zugriff auf Deinen Controller.
Nach deinen Tests mußt Du natürlich den Speicher korrekt initialisieren
.
Bei bedarf kann ich Dir genauere Infos schicken. So etwas habe ich
bisher nur bei den Renesas Controllern gemacht.

Oryx

von Arvid Teichtmann (Gast)


Lesenswert?

@Schmittchen:
Zu Beginn von main(void) sind die meines Wissens sehr wohl schon
initialisiert, wo denn bitte sonst?
Und wie kann ich in C vor main(void) schon Code ausführen?

@Oryx:
Es gibt wohl ein cstartup.s43 file, das man modifizieren kann, habe es
mir aber noch nicht angesehen. Werde dann um Assembler wohl nicht
herumkommen...
Die Doku von IAR ist einfach grauenhaft, der Linker ist dermassen
schlecht beschrieben und ich bin kein Profi, der schon seit zehn Jahren
uC programmiert.

> Bei bedarf kann ich Dir genauere Infos schicken.
...gerne, man lernt am besten aus Beispielen.

> So etwas habe ich bisher nur bei den Renesas Controllern gemacht
...die hiessen früher mal Mitsubishi, oder?

Gruss
Arvid

von Schmittchen (Gast)


Lesenswert?

In main() ist schon alles gelaufen. Du mußt vorher deinen RAM-Test
durchlaufen. Wie Oryx schon anmerkte, in den crt0.*-Files kann Code
eingebaut werden, der vor main() ausgeführt wird - ist auch abhängig
vom Compiler. Davor kommst meist nur noch startup.asm o.ä..
Wenn du dir die paar Zeilen in Assembler nicht zutraust, dann schreibs
in C und lasses compilieren und dich davon inspirieren.

Schmittchen.

von Arvid Teichtmann (Gast)


Lesenswert?

> In main() ist schon alles gelaufen.
> Du mußt vorher deinen RAM-Test durchlaufen.

...das habe ich mir auch schon gedacht.
Nach einigem Suchen bin ich fündig geworden (grauenhafte IAR-Doku):
Es gibt ein cstartup.s43 file, dort kann man assembler code hinzufügen
und das modifizierte file dann einbinden.
Oder man schreibt eigenen C-Code in das file lowinit.c,
das wird vor main() ausgeführt.
Genau das habe ich gesucht...
Werde ich demnächst mal ausprobieren.

Arvid

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.