MSP430FR FRAM als RAM benutzen?

[Jens (Gast)]

Hallo Leute,

hat sich schon jemand tiefergehend mit den FRAM Typen vom MSP430 
beschäftigt?

Ich suche schon eine ganze weile nach der Möglichkeit, den FRAM im Chip 
als RAM zu "misbrauchen", habe aber noch keinen erfolg gehabt. Kann mir 
da jemand mit seiner Expertiese helfen?

[Felix (Gast)]

Hallo Jens,

ich vermute mal, dass deine Variablen nicht in den FRAM abgelegt werden?
Im normalfall werden alle Variablen in ".data", also SRAM abgelegt.

Hierfür gibt es mehrere Möglichkeiten, mit denne ich zumindestens das 
gewünschte Verhalten umsetze:

- Du kannst bei der Deklaration der Variablen deren Speicherort 
festlegen (FRAM - Bereich).

bspw:

#pragma LOCATION( x , address );
int x;

- Du kannst sie gleich als Persistent deklarieren, da diese automatisch 
vom Linker in den FRAM gelegt werden. Evtl. nicht optimal für deine 
Anwendung, da hier nur einmalig beim Download die Variable initalisiert 
wird.

#pragma PERSISTENT (x );
int x=10;

- Du erstellst im Linker Command File eine eigene Section und weißt 
dieser die Variablen zu (Wohl beste Lösung)

#pragma SET_DATA_SECTION(".FelixSection")
unsigned int Test;   
...              
#pragma SET_DATA_SECTION()

und cmd-File:

GROUP(READ_WRITE_MEMORY): ALIGN(0x0200) RUN_START(fram_rw_start)
{
      .cio        : {}          /* C I/O BUFFER                      */
      .sysmem     : {}          /* DYNAMIC MEMORY ALLOCATION AREA    */
      .FelixSection: {}         /* Test */
}

PS:
- Die oben genannten Ausschnitte sind nur für Code Composer Studio und 
C. Für IAR oder Assembler sieht die Syntax jeweils anders aus.

- Manche MSP430FR haben eine MPU oder ein FRAM Protection-Bit, welche 
den Zugriff blockieren ;)

- Die passenden Userguides:
 + MSP430 Optimizing C/C++ Compiler v 4.3
 + MSP430 Assembly Language Tools v 4.3

[Jens (Gast)]

Hallo Felix,

danke für deinen Beitrag, der mir einen ordentlichen Denkanstoß gegeben 
hat.

Felix schrieb:
> - Du kannst bei der Deklaration der Variablen deren Speicherort
> festlegen (FRAM - Bereich).
>
> bspw:#pragma LOCATION( x , address );
> int x;

Ja sowas wäre fein, aber dazu ist ja irsinnig viel "Handarbeit" von 
nöten... bei zig Variablen steigt die Fehleranfälligkeit ja 
exponentiel... ;)

Da ist die Section deklaration sicherlich einfacher.

Interessant Frage die sich aus der Section deklaration ergibt:
Könnte man noch auf das FRAM vom MSP aus schreibend zugreifen, wenn man 
ein JTAG Passwort/Lock fergeben hat?

[Rufus Τ. F. (rufus)]

Jens schrieb:
> Könnte man noch auf das FRAM vom MSP aus schreibend zugreifen, wenn man
> ein JTAG Passwort/Lock fergeben hat?

Der Controller selber kann mit seinem FRAM selbstverständlich anfangen, 
was er will, völlig unabhängig von irgendwelchen JTAG-Passwörtern etc.

[Jens (Gast)]

Hallo Rufus,

auch Dir danke ich natürlich!

Eine kleine Frage habe ich noch ;)

TI sagt die Zellen machen 10e15 Schreibzyklen mit, was bei mir ~160.000 
Jahre @25°C bedeuten würde (1000 x pro Sekukunde). Okay, ich weiß das 
ist unrealistisch, aber ein "paar" Jahre (5-10) wären schon 
wünschenswert.
Die MSP430FR sind zwar erst ein paar wenige Jahre auf dem markt, aber 
hat auch hierzu schon jemand "Langzeiterfahrung".

[Max G. (l0wside)]

Frag doch mal TI, wie sie das abgesichert haben.

Wenn´s kritisch ist, kannst du auch mal selbst einen Versuch fahren: In 
der Endlosschleife wechselnde Bitpattern schreiben, Geräte auf 85°C 
hochheizen und mal einen Monat laufen lassen. Das entspricht rund 
70.000h bei 25°C oder etwa 8 Jahren (gerechnet mit 0,7eV).

85° schafft notfalls auch ein alter Umluft-Backofen mit getunter 
Temperaturregelung. Du solltest nur mehr als ein Gerät testen, die 
Statistik lässt grüßen. Wenn´s ganz genau sein soll, verschiedene 
Fertigungschargen nehmen (als kleiner Kunde wird´s hier aber langsam 
kompliziert).

Max