mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik [MSP430] Struct Daten auf FLASH Speicher dauerhaft sichern


Autor: Daniel G. (daniel83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

Ich bin neu hier und hoffe mich richtig eingefunden zu haben. Gesucht 
habe ich schon, nur leider nicht ganz das richtige gefunden.

Kurz zur Hardware.
Ich habe einen MSP430F149. Dieser ist in ein fertiges System verbaut, 
eine Hardware änderung kommt nicht in Frage, da es sich um ein 
Verkaufsfertiges Produkt handelt und nur an der Software gedreht werden 
darf, alles andere wird unangenehm teuer.

Was ich machen möchte:
Ich habe ein Programm für den PC geschreiben, mit dem ich Parameter 
ändern kann. Aktuell werden diese über Dippschalter eingestellt, sind 
also nach einem Stromausfall reproduzierbar. Das ist bei einer 
Einstellung über Software nicht beliebig möglich.
Ich muss also meine Einstellungen auf den FLASH schreiben. Dies soll 
über eine Einstellrutine via UART erfolgen.

Was ich bisher gemacht habe:
Ich bekomme die Daten auf den Controler gesendet und empfange sie dort 
korrekt. Gespeichert werden sie noch nicht, da ich nun ein kleines 
Konzeptionelles Problem habe.

Lösungsansätze:
- 1. Erst habe ich überlegt, die Daten auf einen relativ weit 
hintenleigenden Bereich im FLASH zu speichern und von dort zu 
verarbeiten.

Warum nicht im Information Memory?
Ganz einfach zu viele Daten, Information Memory == 2* 128Byte
ich habe aber 3*280Byte, auch wenn ich von der PC Programierung komme, 
wo Datenmengen inzwischen keine Rolle mehr spielen ist da nicht mehr 
viel weg zu optimiern.

- 2. Ich Schreibe die Daten beim empfang in den RAM, da ist noch 
ausreichend Platz aktuell 1,4K da sollte ich die 840Byte wohl noch rein 
bekommen. Nach dem Empfang speichere ich diese in den FLASH und Prüfe 
sie auf Richtigkeit. Die Daten im RAM halte ich weiterhin vor. Dort sind 
sie nach dem was ich besher gelesen habe auch deutlich einfacher 
anzusprechen und auch deutlcih schneller und einfacher verfügbar. In der 
Startuprutine lese ich die Daten vom FLASH in den RAM und arbeite wie 
gewohnt mit den RAM Daten.

Fragen:
- Lösungsansatz 1 habe ich sinnvollerweise Verworfen?
- Ist die Lösung 2 vom Ansatz her Richtig?
- Kann ich Arrey[struct] einfach ab einer start adresse in den ROM 
schreiben oder muss ich das von hand Byte weise tun?
- Ist der FLASH echt so langsam oder kann ich mir den Platz im RAM 
sparen und mir bei Bedarf (Schon häufig, mögl. relativ Zeitkritsch) die 
DAten Satzweise aus dem FLASH hohlen?
- Bin aus den Informationen von TI nicht ganz schlau geworden was die 
Adressierbarkeit im Flash angeht. Geht das mit "Variablen" bezeichnern, 
oder muss ich da über die adresse gehen?

So nun gut viele Fragen für einen ersten Post, ich hoffe ich habe alle 
relevanten Daten geliefert und auch gezeigt dass ich mir bereits einige 
Gedanken gemacht habe.

Danke im Voraus

Daniel

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst im Linker-Script einen beliebigen eigenen Flash-Bereich 
anlegen, dazu musst du nur das Script anpassen. Die txt Section wird 
dann kleiner, und der Linker lässt den Bereich für dich frei. 
Sinnvollerweise musst du da die Sektorgrenzen beachten. Da du die 
Adressen selbst vorgibst, kannst du über die normale Flash-Funktion (aus 
den C-Demos) dann einfach den/die Sektor(en) löschen, und den Strukt da 
rein schreiben. Du nimmst einen pointer auf das Strukt und per sizeof() 
die Länge und ab geht die Post. Einzig das Schreiben ist etwas langsam, 
aber das Lesen aus dem Flash ist genauso schnell wie das Lesen aus dem 
RAM, daher ist das egal. Ich hab sowas für einen Funk-Bootloader 
gemacht, klappt wunderbar. Mit GCC noch einfacher als mit dem CCE3, aber 
geht natürlich bei jedem Compiler/Linker.

Autor: Daniel G. (daniel83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmal Hallo Zusammen

So, habe den Teil erstmal auf die lange Bank geschoben, aber jetzt bin 
ich wieder dran.
Das mit den Linker Files hab ich noch nicht ganz verstanden, glaube ich. 
Da ich mir damit bestimmt auch nen bischen was kaputt machen kann frag 
ich lieber nochmal nach. Ich habe einen File gefunden und Modifiziert. 
der sieht jetzt so aus:


<!DOCTYPE Linker_Placement_File>
<Root name="MSP430 Section Placement">
  <MemorySegment name="RAM">
    <ProgramSection load="Yes" start="0x0" name=".abs"/>
    <ProgramSection name="IDATA0"/>
    <ProgramSection name="UDATA0"/>
  </MemorySegment>
  <MemorySegment name="INFO_A">
    <ProgramSection load="Yes" name="INFO_A"/>
  </MemorySegment>
  <MemorySegment name="INFO_B">
    <ProgramSection load="Yes" name="INFO_B"/>
  </MemorySegment>
  

  <MemorySegment name="Element_1">
    <ProgramSection size="512" load="Yes" start="0x6000" name="Element_1"/>
  </MemorySegment>
  <MemorySegment name="Element_2">
    <ProgramSection size="512" load="Yes" start="0x6200" name="Element_2"/>
  </MemorySegment>
  <MemorySegment name="Element_3">
    <ProgramSection size="512" load="Yes" start="0x6400" name="Element_3"/>
  </MemorySegment>



  <MemorySegment name="FLASH">
    <ProgramSection load="Yes" name="ISR"/>
    <ProgramSection load="Yes" name="CONST"/>
    <ProgramSection load="Yes" name="CODE"/>
    <ProgramSection size="32" load="Yes" start="0xFFE0" name="INTVEC"/>
  </MemorySegment>
</Root>

eingefügt habe ich den Teil in der Mitte. Geht das so, oder bin ich da 
komplett auf dem Holzweg?


sollte das so gehen, komme ich gleich zur nächsten Frage. Nach ansehen 
der Beispiel Dateien von TI habe ich 3 Beispiel funktionen geschreiben, 
die in etwa zeigen sollen was ich vor habe.


typedef struct{
  unsigned byte ubByte1;
  unsigned int uiInt1;
  unsigned long ulLong1;
}TS_INNER_STRUCT

typedef struct{
  unsigned byte ubByte2;
  unsigned int uiInt2;
  unsigned long ulLong2;
  TS_INNER_STRUCT inner_struct[STRUCT_COUNT];
}TS_MAIN_STRUCT


int erase_Flash(unsigned int StartAdress)
{
  Flash_ptr = (TS_MAIN_STRUCT *) StartAdress;    //Initialise Flash pointer to StartAdress

  FCTL2 = FWKEY + FSSEL1 + FNO; // MCLK/2 for Flash Timing Generator
  FCTL1 = FWKEY + ERASE; // Set Erase bit
  FCTL3 = FWKEY;  // Clear Lock bit

  *Flash_ptr = 0;  // Dummy write to Erase

  while (! (FCTL3 & WAIT) );  // Wait while not ready
  
  return 1;
}

void write_Flash(TS_MAIN_STRUCT struct_to_save , unsigned int StartAdress)
{
  //_DINT();  // Disable Interrupts

  Flash_ptr = (TS_MAIN_STRUCT *) StartAdress;  
             //Initialise Flash pointer to StartAdress

  while( FCTL3 & BUSY );  // Check Flash Busy bit

  FCTL1 = FWKEY + BLKWRT + WRT; // Enable block-write operation

  *Flash_ptr = struct_to_save; // write value to flash

  while (! (FCTL3 & WAIT ) );  // Wait until Flash is ready

  FCTL1 = FWKEY;  // Clear BLKWRT & WRT bits

  while ( FCTL3 & BUSY );  // Check Busy bit

  FCTL3 = FWKEY + LOCK;  // Reset Lock bit

  //_EINT();    // Enable Interrupts
}


TS_MAIN_STRUCT read_Flash( unsigned int StartAdress )
{
  Flash_ptr = (TS_MAIN_STRUCT *) StartAdress;    //Initialise Flash pointer to StartAdress

  return (*Flash_ptr);              // return Value of Flash pointer

}

Ich meine Gelesen zu haben, dass ich die Interrupts beim Schreiben aus 
stellen muss, also sollte ich sie ein kommentieren.
In der Schreib rutine von TI waren keine drin, deshalb hab ich erstmal 
keine, oder aber die gelten in dem Beispiel wegen der Copy rutine.

Die Adressen kann ich mir ja entsprechend der MemoryMap und den dort 
angegebenen Adressen verwenden.

Wenn ich das so machen, kriege ich dann das komplette struct ("auf 
einaml") in den Flash oder muss ich das Byteweise schreiben?

Und krieg ich das wirklich soo einfach wieder heraus?

Ich habe leider eine etwas schlechte Debugumgebung, also Debuggen im 
System ist mir soweit ich weiß nicht möglich, deshalb gerade bei 
möglicherweiser kritschen Operation frage ich hier so ausführlich nach, 
nicht dass ich mir was kaputt mache.

So, wer hier angekommen ist, schonmal vielen Dank für die Mühe des 
lesens, und hoffentlich des beantwortens^^

Gruß Daniel

Autor: Daniel G. (daniel83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In der Datei, die als MemoryMap gelinkt ist habe ich den Folgenden Teil 
entdeckt:

<MemorySegment size="0xef00" access="Read" start="0x1100" name="FLASH"/>
  <MemorySegment size="0x80" access="Read/Write" start="0x1000" name="INFO_B"/>
  <MemorySegment size="0x80" access="Read/Write" start="0x1080" name="INFO_A"/>
  <MemorySegment size="0x800" access="Read/Write" start="0x200" name="RAM"/>

Das hießt doch dass mein Sectionplacement, was oben steht wohl falsch 
ist.
Weil wie oben geht es nicht. ich müsste also in diesem File es so 
ändern:

<MemorySegment size="0xef00" access="Read/Write" start="0x1100" name="FLASH"/>
  <MemorySegment size="0x80" access="Read/Write" start="0x1000" name="INFO_B"/>
  <MemorySegment size="0x80" access="Read/Write" start="0x1080" name="INFO_A"/>
  <MemorySegment size="0x800" access="Read/Write" start="0x200" name="RAM"/>


und in der oberen Datei so:

...
  <MemorySegment name="FLASH">
    <ProgramSection load="Yes" name="ISR"/>
    <ProgramSection load="Yes" name="CONST"/>
    <ProgramSection load="Yes" name="CODE"/>
    <ProgramSection size="512" load="Yes" start="0x6000" name="Element_1"/>
    <ProgramSection size="512" load="Yes" start="0x6200" name="Element_2"/>
    <ProgramSection size="512" load="Yes" start="0x6400" name="Element_3"/>
    <ProgramSection size="32" load="Yes" start="0xFFE0" name="INTVEC"/>
  </MemorySegment>
...


und diesen Teil raus löschen:


  <MemorySegment name="Element_1">
    <ProgramSection size="512" load="Yes" start="0x6000" name="Element_1"/>
  </MemorySegment>
  <MemorySegment name="Element_2">
    <ProgramSection size="512" load="Yes" start="0x6200" name="Element_2"/>
  </MemorySegment>
  <MemorySegment name="Element_3">
    <ProgramSection size="512" load="Yes" start="0x6400" name="Element_3"/>
  </MemorySegment>

Autor: Daniel G. (daniel83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, das mit der Memory Map hab ich jetzt.

Also Memory Map muss rein:

  <MemorySegment size="0xe900" access="Read" start="0x1700" name="FLASH"/>
  <MemorySegment size="0x200" access="Read/Write" start="0x1500" name="Element_C"/>
  <MemorySegment size="0x200" access="Read/Write" start="0x1300" name="Element_B"/>
  <MemorySegment size="0x200" access="Read/Write" start="0x1100" name="Element_A"/>
  <MemorySegment size="0x80" access="Read/Write" start="0x1000" name="INFO_B"/>
  <MemorySegment size="0x80" access="Read/Write" start="0x1080" name="INFO_A"/>
  <MemorySegment size="0x800" access="Read/Write" start="0x200" name="RAM"/>


in dem Section placement File:


  <MemorySegment name="INFO_B">
    <ProgramSection load="Yes" name="INFO_B"/>
  </MemorySegment>
  <MemorySegment>
    <ProgramSection load="Yes" name="Element_A"/>
  </MemorySegment>
  <MemorySegment>
    <ProgramSection load="Yes" name="Element_B"/>
  </MemorySegment>
  <MemorySection>
    <ProgramSection load="Yes" name="Element_C"/>
  </MemorySection>




zumindest zeigt es so meine Entwicklungsumgebung richtig an ;-)

bleibt das Problem mit dem Zugriff/Speichern in diesem Bereich.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst nicht das ganze Struct aufs Mal schreiben, sondern musst das 
Byte oder Wortweise schreiben, ich hab das zum beispiel so:
unsigned char WriteInfoMemA(unsigned int *Data, unsigned char NumWords)
{
  if(NumWords < 129)
  {
    //_DINT();
    WDTCTL = WDTPW + WDTHOLD;                       // Stop watchdog timer
      FCTL2 = FWKEY + FSSEL_SMCLK + FN1 + FN3;      // SMCLK/10 for Flash Timing Generator -> ~ 400Khz
    unsigned int *FlashPtr;
    unsigned char i;
    FlashPtr = (unsigned int*)0x1080;
    FCTL1 = FWKEY + ERASE;                    // Set Erase bit
      FCTL3 = FWKEY;                            // Clear Lock bit
      *FlashPtr = 0;                           // Dummy write to erase Flash segment
    FCTL1 = FWKEY + WRT;                      // Set WRT bit for write operation
    
    for (i=0; i<NumWords; i++)
      {
        *FlashPtr++ = *Data++;                   // Write value to flash
      }
  
      FCTL1 = FWKEY;                            // Clear WRT bit
      FCTL3 = FWKEY + LOCK;                     // Set LOCK bit
    //_EINT();
    return NumWords+1;
  }
  else return 0;
}
Aufrufen müsstest du das dann:

WriteInfoMemA(TS_MAIN_STRUCT, sizeof(TS_MAIN_STRUCT)/2 );

Musst halt für dich noch das mit der Startadresse anpassen, und die 
Anzahl Bytes an das Flash-Segment.....es gehen ja immer nur 128 Worte 
aufs Mal zu schreiben....

Autor: Daniel G. (daniel83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christan,

Danke für die Antwort,

Du meinst sicher 128Bytes, weil 128 Worte passen in Info_A nicht rein^^

Aus diesem Grund habe ich mir ja hoffentlich richtig 3 neue Daten 
bereiche eingerichtet, die 3* 512 Bytes groß sind, da mir die Info 
Speicher nicht reichen.

In deinem Beispiel löscht du Segment a und schreibst 128 * Int in den 
Speicher, int ist doch aber laut meinem schlauen Buch 2-4 Bytes lang, in 
meinem Fall meine ich 2 Bytes. Wäre also zuviel, aber du weist bestimmt 
was du tust. Vieleicht verhaue ich mich da.

Wenn aber int 2Bytes groß ist, dann kann ich doch auch Größe Datentypen 
auf mal schreiben, also bsp. nen Long, und wenn das geht warum kein 
Struct? ist ja auch "nur" ein Datentyp.

Wenn ich die Structs auseinander nehmen muss um sie in Teilen zu 
schreiben, und dann auch wieder in Teilen zu lesen?? habe ich dort 
einfach ein sehr großes Fehler Potential, welches ich gerne durch 
einfache Rutinen umgehen will.

Der Prozessor ist ja dummerweise immer nur so schlau wie der, der davor 
sitzt

Autor: Daniel G. (daniel83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Daten des Struktsliegen mir im RAM vor. Würde es gehen eine Schleife 
zu bauen, die mit 2 (char *) piontern arbeitet?

also so:

void write_Flash(TS_MAIN_STRUCT *struct_to_save, int StartAdress)
{

    //_DINT();
    WDTCTL = WDTPW + WDTHOLD;                       // Stop watchdog timer
      FCTL2 = FWKEY + FSSEL_SMCLK + FN1 + FN3;      // SMCLK/10 for Flash Timing Generator -> ~ 400Khz
    unsigned char *FlashPtr;
  unsigned char *StructPtr;
    FlashPtr = (unsigned char*)ELEMENT_A;
  StructPtr=(unsigned char*)struct_to_slave;
    FCTL1 = FWKEY + ERASE;                    // Set Erase bit
      FCTL3 = FWKEY;                            // Clear Lock bit
      *FlashPtr = 0;                           // Dummy write to erase Flash segment
    FCTL1 = FWKEY + WRT;                      // Set WRT bit for write operation
    
    for (; StructPtr<=(struct_to_slave+sizeOf(TS_MAIN_STRUCT); )
      {
        *FlashPtr++ = *StructPtr++;                   // Write value to flash
      }
  
      FCTL1 = FWKEY;                            // Clear WRT bit
      FCTL3 = FWKEY + LOCK;                     // Set LOCK bit
    //_EINT();
}


Der zugriff sollte wie oben beschrieben gehen , denke ich.

Gruß Daniel

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst auch über Sektor-Grenzen hinwegschreiben, musst aber vorher 
den nächsten Sektor auch gelöscht haben. Daher die 128 Worte (gesamter 
InfoMem des F1611). Sowas mache ich beispielsweise beim Firmware-Update 
über Funk. Ich hab einen Bootloader-Bereich und lösche allles ab dem 
Bootloader-Bereich in einem Rutsch in einer Schleife, den WritePointer 
immer un 0x200 erhöht (FlashPinter ist unsignec char *, also Byte 
Programming). Dann FlashPointer wieder auf den Start des Hauptpogrammes 
setzen und aus dem externen RAM das neue Programm in den Flash schreiben 
(auch wieder Byte-Weise.

Wenn du nur eine Schreib-Operation mit einem uint16_t* Pointer machst, 
wird nur ein einziges Wort in den Flash geschrieben. Teilen musst du 
deine Structs nicht. Das hab ich oben falsch geschrieben. Man kann über 
die Sektoren schreiben, aber eben vorher jeden Sektor einzeln löschen, 
wenn man kein Mass Erase machen will.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würds halt zur besseren lesbarkeit so machen:
void write_Flash(TS_MAIN_STRUCT *struct_to_save, int StartAdress)
{

    //_DINT();
    WDTCTL = WDTPW + WDTHOLD;                       // Stop watchdog timer
      FCTL2 = FWKEY + FSSEL_SMCLK + FN1 + FN3;      // SMCLK/10 for Flash Timing Generator -> ~ 400Khz
    unsigned char *FlashPtr;
  unsigned char *StructPtr;
    FlashPtr = (unsigned char*)ELEMENT_A;
  StructPtr=(unsigned char*)struct_to_slave;
    FCTL1 = FWKEY + ERASE;                    // Set Erase bit
      FCTL3 = FWKEY;                            // Clear Lock bit
      *FlashPtr = 0;                           // Dummy write to erase Flash segment
    //Segment B löschen
    FlashPtr = (unsigned char*)ELEMENT_B;
    FCTL1 = FWKEY + ERASE;                    // Set Erase bit
      FCTL3 = FWKEY;                            // Clear Lock bit
      *FlashPtr = 0;                           // Dummy write to erase
    FCTL1 = FWKEY + WRT;                      // Set WRT bit for write operation
    
    unsigned char i;
    for (i=0; i< sizeOf(TS_MAIN_STRUCT); i++)
      {
        *FlashPtr++ = *StructPtr++;                   // Write value to flash
      }
  
      FCTL1 = FWKEY;                            // Clear WRT bit
      FCTL3 = FWKEY + LOCK;                     // Set LOCK bit
    //_EINT();
}

Als Beispiel das (eventuell vorhandene) Segment B noch mit löschen, 
falls dein Struct größer ist als 512 Byte....

Autor: Daniel G. (daniel83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In meinem Fall schreibe ich in 512Byte große Bereiche im Flash, also 
löschen des Blocks sollte laut beschreibung die kompletten 512 Bytes 
löschen, ganz so viel brauche ich zwar nicht aber ich hab ja Platz ohne 
ende^^

Mir ist halt wichtig, dass die Structur des Structs erhalten bleibt.

Ich führe von einem PC aus eine Einstellung von "Parametern" durch. 
Diese will ich natürlich über einen möglichen strumausfall hin weg 
retten. Arbeiten tue ich mit dem Struct im RAM, da ich viele Schreib und 
überschreibzugriffe in bestimmten Teilen habe.

Ich brauche halt eine Funktion um die Structs vom Ram in den Flash zu 
bekommen und wieder zurück. Dies am besten ohne doll drüber nach zu 
denken.

Mit der von mir oben geposteten Version deiner Funktion schreibe ich ja 
nun Byteweise, sollte also gehen.

Muss ich auch wieder Byteweise lesen?

Wäre ja dann quasi genau so, wie die Schreib operation.

Wie gesagt ist mein Problem, dass ich erst zeimlich viel Code 
produzieren muss, um raus zu bekommen ob da jetzt das drin steht was ich 
rein schreiben wollte, deshalb hänge ich hier so ein bischen fest, und 
kaput schreiben will ich mir nach Möglichkeit auch nichts.
Deshalb bin ich hier so penetrant darauf bedacht zumindest ein ja es 
sollte so funktioneren als Antwort zu bekommen.

Autor: Daniel G. (daniel83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

danke dir für die Antwort.

Ich werde mich mal dran setzten und das so Implementieren.

Ja ein Element B ist vorhanden, aber das brauche ich für Array elemnt 2 
meines Struct Arrays^^

Ich sollte aber mit den 512 Bytes klar kommen, wenn nicht muss ich eh 
umbauen.

Hast du zum auslesen eine Idee, also muss ich das auch Byte weise tun 
oder geht das so wie beschrieben?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst dann natürlich auch Wortweise lesen. Ich nehm dazu die memcpy 
Funktion der Einfachheit halber. Flash lesen ist genauso wie RAM lesen, 
da muss nix am Flash-Controller getan werden.

Autor: Daniel G. (daniel83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also Pointer auf struct mit der Start adresse und gib ihm...

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
memcpy(DeinStrukt, SEGMENT_A, sizeof(TS_MAIN_STRUCT));

Autor: Daniel G. (daniel83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, habs zusammen und es schein zu funktionieren.

Schreiben:

void write_Flash(TS_MAIN_STRUCT*struct_to_save, int StartAdress)
{
      unsigned char *FlashPtr;
      unsigned char *StructPtr;
      unsigned int i;

       _DINT();
       WDTCTL = WDTPW + WDTHOLD;                       // Stop watchdog timer
       FCTL2 = FWKEY + FSSEL1 + FN0 ;      // SMCLK/10 for Flash Timing Generator -> ~ 400Khz

      FlashPtr = (unsigned char*)ELEMENT_A;
      StructPtr=(unsigned char*)struct_to_save;
      FCTL1 = FWKEY + ERASE;                    // Set Erase bit
      FCTL3 = FWKEY;                            // Clear Lock bit
      *FlashPtr = 0;                           // Dummy write to erase Flash segment
   
      FCTL1 = FWKEY + WRT;                      // Set WRT bit for write operation

      for (i=0; i< sizeof(TS_MAIN_STRUCT); i++)
      {
            *FlashPtr++ = *StructPtr++;                   // Write value to flash
      }
  
      FCTL1 = FWKEY;                            // Clear WRT bit
      FCTL3 = FWKEY + LOCK;                     // Set LOCK bit
      _EINT();
}



Auslesen:

void vSetStructs(void)
{
      TS_MAIN_STRUCT* Struct_ptr = (TS_MAIN_STRUCT*)ELEMENT_A;
      tsMainStruct[0]=*Struct_ptr;
}



ELEMENT_A ist eine Konstante auf den Speicherort.

Autor: Daniel G. (daniel83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So,

Speichern geht, zurück laden nicht ganz.

Da ich in früheren Beiträgen bereits auf mein suboptimale aufgelkistet 
Struct angesprochen wurde könnte es sein, dass damit zusammen hängt. 
hier erstmal meine Structs die ich ablege.


typedef struct   {
ubyte ubKeyDownCommand; 
ubyte ubKeyDownParameter;     
ubyte ubKeyUpCommand;      
ubyte ubKeyUpParameter;          
ubyte ubToggleCommand;         
ulong ulWindowUsed;            
ubyte ubState;                          
uword uwTimestamp;    
ubyte ubUpToDownFlags;            
ulong ulWindowsProcessed;      
                  } TS_KEYS;

typedef struct  {
ubyte ubDipSwitch;       
ubyte ubDipSwitchOld;     
ulong ulButtons;         
ulong ulButtonsOld;
ulong ulButtonsProcess;   
ubyte ubSlaveOnline;      
ubyte ubAvailableRetrys;  
ubyte ubModuleSoftwareFlag;   
ubyte ubModuleSoftwareFlagOld;
TS_KEYS tsKeys[KEY_COUNT_ONE];
                } TS_MODULE;


Das Problem ist, dass ich nach dem Speichern im Flash in einigen Stellen 
0xFF stehen hab, da der FGlash beim löschen ja mit 1 beschrieben wird 
legt das die vermutung nahe, dass ich hier auf die falsche stelle 
zugreife. Ich arbeite mit dem Struct nur im RAM, lege ihn aber im Flash 
ab und hohle ihn mir da beim Neustarten wieder raus.
Wenn ich etwas rein schreibe und sofort auslese ist alles richtig.
Wenn ich es erst abspeichere und dann aus dem Flash lade und dann 
auslese habe ich teilweise Falsche Werte Gerne bei "ubDownCommand" habe 
aber nicht alles restlos getestet, möglicherweise auch an anderer Stelle

Wie ich speichere Steht ja oben, lesen tue ich so

TS_MODULE* modulePtr;
modulePtr=(TS_MODULE *)ELEMENT_A;
tsModule[ubModuleID]=*modulePtr;


Sollte es so sein, dass evtl im RAM die Adressierbarkeit anders ist als 
im Flash könnte es durch einfaches Kopieren nicht getan sein.

Wenn dem so ist, oder jemand meint, dass es daran leigen könnte wäre es 
nett wenn mir jemand sagen könnte wie ich die Structs umstellen muss 
damit es keine Probleme gibt.

Ich speichere in einen Flashsector immer EIN "TS_MODULE"

Gruß Daniel

Autor: Daniel G. (daniel83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weiteres Testen ergab, fehler treten nur bei den ersten beiden Structs 
auf, bei dem Dritten geht es zuverlässig.

Allerdings verarbeite ich alle drei gleich, versuche nun schon seit 2 
Stunden den Unterschied in den Rutinen zu finden.

Wird durch dieses Verhalten meine Idee mit den unterschiedlichen Größen, 
bzw. lager orten der einzelnen Bytes und Longs im Flash und im Ram hin 
fällig, oder hat das nichts zu sagen??

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie groß ist Dein STRUCT (in Bytes) ?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Normalerweise kümmert sich der Kompiler drum, die Daten an 16 Bit 
auszurichten. Allerdings ist der Speicher im MSP430 auch 
Byte-Adressierbar, selbst dann sollte es keine Probleme geben. Welchen 
Kompiler benutzt du überhaupt?

Autor: Daniel G. (daniel83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Stefan: ca 360 Bytes meine ich ausgerechnet zu haben aufjedenfall 
deutlich kleiner als 512Bytes

@ Christian Rowley CrossStudio Pro

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@daniel ...

ich hab den thread nur mal eben kurz überflogen ...
aber wenn du in dem linkerfile für deine 3 speicherbereiche 0x1100 
0x1300 und 0x1500 angegeben hast wirst/kannst du probleme bekommen. die 
flash-page size ist ja 512 byte (0x200) groß, und 0x1100, 0x1300 und 
0x1500 liegen auf einer "halben page" ... mit 0x1200, 0x1400 und 0x1600 
dürften keine probleme auftauchen.
ich weiß nicht ob das im thread schon gesagt worden ist, aber das 
müsstest du beherzigen, vor allem wenn in dem bereich von 0x1000 - 
0x1100 und 0x1700-0x1800 code drin steht, da dieser beim löschen der 
page ebenfalls gelöscht wird und die fehlersuche dann erst richtig 
lustig wird.

Autor: Daniel G. (daniel83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mit 0x1100 angefangen, da dort laut datenblat der Code teil 
anfängt, hängt evtl. mit den 2*128Bytes im Info A und Info B speicher 
zusammen, das sollte eigentlich kein Problem sein

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>ca 360 Bytes meine ich ausgerechnet zu haben aufjedenfall
>deutlich kleiner als 512Bytes

Hat vermutlich nicht unbedingt mit Deinem Problem zu tun...
aber Du betreibst den Flash beim Beschreiben ausserhalb der 
Spezifikation!

Ich kann nicht behaupten, dass ich alles genau verstanden habe, was TI 
zu dem Thema sagt. Aber kurz zusammengefasst verstehe ich das so:
(Grundlage: Datenblatt F149 und AppNote slaa334)

Jeder Schreibvorgang ins Flash (Byte/Word) dauert 35 Taktzyklen (bezogen 
auf den Clock des Memory Controllers). Davon wird 29 TZ lang die 
Programmierspannung an eine zusammenhängende 64-Byte-Reihe Flashzellen 
gelegt. Diese Programmierspannung "stresst" die Flashzellen. Daher darf 
diese Spannung nur für eine maximale Zeitdauer anliegen (cumulative 
program time). Beim F149 beträgt diese max. 4ms !

Bei Dir -meine ich hier irgendwo gelesen zu haben- ist fFTG = 400kHz
D.h. beim Schreiben eines Bytes liegt die Spannung für 29/400kHz = 
72,5µs an.
Bei tCPT = 4ms kannst Du also maximal 4ms/72,5µs = 55Bytes am Stück 
programmieren. Wenn Du die vollen 64Bytes programmierst, überschreitest 
Du max. zulässige CPT!

Einzige Möglichkeit:
-entweder fFTG auf Maximum (476kHz)
-oder WORD anstatt BYTE-weise schreiben

Autor: Daniel G. (daniel83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Stefan:

Was du meinst ist bestimmt diese Zeile:
>FCTL2 = FWKEY + FSSEL1 + FN0 ;      // SMCLK/10 for Flash Timing Generator -> ~ 
400Khz

Die Kommentare daran habe ich aus Christans Bespiel übernommen, der Wert 
ist aus dem TI Beispiel

FCTL2 = FWKEY + FSSEL1 + FN0 ;  // MCLK/2 for Flashtiming Generator

wäre entsprechend dem Beispiel, etwas anderes sehe ich dort nicht, was 
irgendwas mit Timing oder Frequenzen zu tun hat, jedoch jedoch ist MCLK 
mit Dafault 800Khz angegeben, wären wenn MCLK/2 stimmt also auch 400kHz.

Wie krieg ich dass denn schneller?

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wie krieg ich dass denn schneller?
Na den Teilerfaktor über FNx gemäß User Guide anpassen.
Gegebenenfalls auch die Clock source anders wählen.
Musst halt auch aufpassen, dass die Toleranzen der Clock source nicht 
den Memory Controller Clock über die max. 476kHz treiben können!

Autor: Daniel G. (daniel83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Durch die Appnotes bin ich nicht ganz durchgestiegen, bzw. habe das 
Datenblatt mit den Werten nicht gefunden, aber das Timing Problem habe 
ich über Wortweises schreiben gelöst.

habe mal die Größe exakt bestimmt. mit optimierung also irgendwie passen 
zusammen gelegt ergibt das für TS_KEYS 17 Bytes und für TS_MUDOLE 18 
Bytes + 20* TS_KEYS also insgesamt 358Bytes

Ohne optimierung sind das TS_KEYS im schlechtesten fall 20 Bytes und 
TS_MODULE 20 Bytes + 20* TS_KEYS also 420 Bytes

Der Knackpunkt ist bei index 12, also 12 geht noch 13 nicht mehr.
nur in ELEMENT A und ELEMENT B in ELEMENT C bekomme ich alles passend 
rein und wieder raus.
12 wäre nach optimierter rechnnung 12*17+18=222Bytes
ohne Optimierung 12*20+20=260Bytes
Sollte 256 der knackpunkt sein, würden die letzten 4 Byte von 
TS_KEYS[12] auch fehler, werde ich gleich mal test, ob ein umlegen um 
0x0100 etwas bewirkt.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lass dir doch die Größe mit SizeOf Berechnen. Kannst du in einer 
variable zum Test mal ausgeben und im Debugger auslesen....dann weißt du 
es genau. Kommt ja drauf an, wie der die Padding Bytes einfügt...

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>habe mal die Größe exakt bestimmt. mit optimierung also irgendwie passen
>zusammen gelegt ergibt das für TS_KEYS 17 Bytes und für TS_MUDOLE 18
>Bytes + 20* TS_KEYS also insgesamt 358Bytes

>Ohne optimierung sind das TS_KEYS im schlechtesten fall 20 Bytes und
>TS_MODULE 20 Bytes + 20* TS_KEYS also 420 Bytes

Was für eine Optimierung?
Ich bin kein C-Standard-Auswendig-Wisser... aber soweit ich mich 
erinnere, sollte/dürfte ein Compiler an einer Struktur nix optimieren 
bzw. ändern?!

An Deiner Stelle würde ich mal die Strukturen so organisieren, dass das 
Alignment passt (ggf. Dummy-Bytes einfügen)!

... ist doch kein Zustand, sowas undefiniertes...

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Padding macht der Kompiler alleine. Allerdings nur für seine 
Architektur, da muss man beim Austausch von Strukturen aufpassen. Der 
mspgcc packt die Strukturen in 16 Bit Grenzen, wie das der Rowley macht, 
weiß ich nicht. Denke aber auch, dass er sie an der nativen Wortbreite 
des Speichers ausrichtet. Das sollte nicht das Problem darstellen....

Autor: Daniel G. (daniel83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gut, geht jetzt wohl.

Ich habe einfach den Speicherbereich ab 0x2000 anfangen lassen, ist ja 
massig Platz im Flash, wahrscheinlich ist da ein teil kaput gegangen, 
auf jedenfall geht es jetzt, werde es morgen noch bis zum exess Testen, 
auch mal mit anderer Hardware.

Soweit Danke ich erstmal allen, die sich ihre Gedanken gemacht haben und 
mir geholfen haben

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das Padding macht der Kompiler alleine
Es geht nicht ums Padding! Dass das der Compiler macht, ist klar!
Es geht um die (anscheinend) unterschiedliche Struktur-Größe, je nach 
Optimierung (was für eine auch immer da gemeint sein mag)...
Wenn man "nur" das Padding betrachtet, müsste die Struktur ja immer 
gleich groß sein!

Autor: Daniel G. (daniel83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die unterschiedliche Größe war ein reine theoretischer Überlegungsansatz 
von mir.
Da wir zwar ne teure Entwicklungsumgebung gekauft haben aber keinen 
tollen debugger sondern nur so ein Teil zum rein schreiben, sind meine 
Debug möglcihkeiten leider etwas eingeschränkt, also hab ich mit nem 
Stift und Papier mal gerechnet, ob sich da etwas ergeben könnte.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.