Hallo,
ich schreibe momentan an einem Programm für den MSP430F5510, der Text
und Grafiken auf einem Pixeldisplay ausgibt. Der Print, den ich für die
Entwicklung nutze, hat monatelang problemlos funktioniert. Mit einem
zweiten Print habe ich aber nun auf einmal seltsame Probleme.
Angefangen hat es mit "Pixelfehlern" in der Grafik, und "ASCII-Fehlern"
im Text, also "dEbug" oder "debuf" statt "debug" auf dem Screen.
Ich habe dann meinen Code vereinfacht, bis ich bei dem gelandet bin:
Manchmal stoppt der Code auf dem Breakpoint, also wird manchmal das
Flash falsch ausgelesen. Meistens passiert dies kurz nach dem Reset (cnt
<= 50), manchmal geht es aber auch viel länger (cnt = einige Millionen).
Nach dem nächsten Reset passiert es dann z.B. sofort wieder.
Folgendes habe ich bisher herausgefunden:
- Bei einer System clock von 24MHz statt 25MHz scheint das Problem nicht
aufzutreten
- Bei zwei von vier getesteten Prints scheint das Problem nicht
aufzutreten
- Mit einfachen Werten statt arrays tritt das Problem seltener auf; wenn
ich != statt memcmp benutze, scheint es nicht mehr aufzutreten
- Compiler-Optimierungslevel macht keinen Unterschied
- ~1s delay vor und nach dem Clock-Einstellen macht keinen Unterschied
- Es scheint immer ein 1-bit als 0 gelesen zu werden, wenn die Daten
0x00 statt 0xFF sind, kann ich das Problem nicht reproduzieren.
Ich habe TI's Dokumentation vom flash corruption Problem (slaa471)
gelesen, aber da heisst es, dass der MSP430F5510 nicht betroffen ist,
und die Art, wie die Daten falsch gelesen werden, ist auch anders.
Im Erratasheet (slaz301j) habe ich auch nichts interessantes gelesen,
ausser "Corrupted flash read when SVM low-side flag is triggered" was
nicht auf mein Problem zutreffen sollte. Der Chip ist von der Revision
C, bei betroffenen und nicht betroffenen Prints.
Danke im Voraus für die Hilfe, ich bin am Ende meines Lateins
inzwischen.
Ich habe folgende Files angehängt:
- Relevanter Teil des Schemas und Layouts
- Speisungsrampe auf dem guten und schlechten Print. (whoops, die
schlechte Variante doppelt)
- zip mit einem CCSv4-Projekt mit dem Beispielcode.
Florian
Fehlt da nicht das Umsetzten von PMMCOREV auf eine höhere VCore
Spannung,
damit die 25 MHz überhaupt benutzt werden dürffen?
Zu niedriger VCore Level könnte das Verhalten (ein Chip tut, ein anderer
nicht) erklären.
Jim Meba schrieb:> Fehlt da nicht das Umsetzten von PMMCOREV auf eine höhere VCore> Spannung,> damit die 25 MHz überhaupt benutzt werden dürffen?> Zu niedriger VCore Level könnte das Verhalten (ein Chip tut, ein anderer> nicht) erklären.
Ich dachte eigentlich, dass sich UCS_initFLLSettle da schon darum
kümmert, aber wenn ich den code davon angucke, dann sehe ich das
nirgends... Ich guck mir das morgen mal an.
Das würde auch erklären, wieso bei 24 MHz alles okay ist.
Interessantes Problem :-)
Hast du schon mal den Takt von 25MHz gemessen? Vielleicht ist der zu
hoch oder hat Aussetzer.
Steht der Wert von XT2DRIVEx auf 3?
Florian Bruhin schrieb:> Jim Meba schrieb:>> Fehlt da nicht das Umsetzten von PMMCOREV auf eine höhere VCore>> Spannung,>> damit die 25 MHz überhaupt benutzt werden dürffen?>> Zu niedriger VCore Level könnte das Verhalten (ein Chip tut, ein anderer>> nicht) erklären.>> Ich dachte eigentlich, dass sich UCS_initFLLSettle da schon darum> kümmert, aber wenn ich den code davon angucke, dann sehe ich das> nirgends... Ich guck mir das morgen mal an.>> Das würde auch erklären, wieso bei 24 MHz alles okay ist.
Das war in der Tat das Problem, mit einem zusätzlichen
1
PMM_setVCore(PMM_CORE_LEVEL_3);
ist alles okay. Ich hatte eigentlich erwartet, dass das
UCS_initFLLSettle für mich schon erledigt.
Bevor ich auf die driverlib gewechselt habe, hatte ich den Code dafür
auch drin. Eigentlich witzig, dass das so heftig über der spec (25 MHz
statt 8) noch so gut gelaufen ist.
Ich habe denselben Post in Englisch auch noch im TI-Forum gepostet, da
hat mir dann kurz nach dir auch noch ein TI-Mitarbeiter dasselbe
erzählt.
Vielen Dank!