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
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
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 :-)
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
> 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.
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
@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
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.
> 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.