MSP430F5510: Korrupte Daten beim Lesen aus Flash

[Florian B. (the_compiler)]

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:

#include <msp430.h>
#include <string.h>
#include "driverlib/MSP430F5xx_6xx/ucs.h"

static const uint16_t flash_data[] = {
        0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
        0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
        0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
        0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
};
static volatile uint16_t ram_data[] = {
        0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
        0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
        0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
        0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
};

void main(void)
{
    volatile uint32_t cnt = 0;
    static const uint32_t mclk = 25000000;

    WDTCTL = WDTPW | WDTHOLD;

    UCS_clockSignalInit(UCS_FLLREF, UCS_REFOCLK_SELECT, UCS_CLOCK_DIVIDER_1);
    UCS_initFLLSettle(mclk/1000, mclk/32768);

    while (1) {
        if (memcmp(&flash_data, (void*)&ram_data, sizeof(flash_data)) != 0) {
            _op_code(0x4343); # Software breakpoint
        }
        cnt++;
    }
}

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

[Jim M. (turboj)]

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.

[Florian B. (the_compiler)]

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.

[Stefan1234 (Gast)]

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 B. (the_compiler)]

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

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!