STM32F031 Wann blockiert CPU beim Flash programmieren/löschen

[stm32user (Gast)]

Guten Tag,

ich besitze einen STM32F031 und möchte zur Laufzeit in eine freie 
Flashseite etwas programmieren bzw. diese löschen. Aufgrund der 
Löschzeit von max. 40ms möchte ich aber parallel weiter meine 
Main-Funktion / andere Funktionen und Interrupts abarbeiten und auf ein 
Flash-Interrupt warten, also kein Busywait.

Meine Frage: Ist das so direkt umsetzbar, dass gelöscht/programmiert 
wird und ich parallel andere Programmteile ausführen kann (inkl. 
Interruptroutinen)?

Die Frage stelle ich, weil ich Zweifel aufgrund folgender Textzeilen im 
Datenblatt habe:

during a program/erase operation to the Flash memory, any attempt to read the Flash memory will stall the bus. The read operation will proceed correctly once the program/erase operation has completed. This means that code or data fetches cannot be made while a program/erase operation is ongoing.

Ich verstehe darunter, dass ich KEIN Code (Code fetch) aus dem Flash 
holen und ausführen darf, während Löschen/Programmieren. Ist es dann 
notwendig, dass ich mein Linkerfile anpassen muss um den Code in den 
SRAM zu bekommen?

Mein Linkerfile:

.isr_vector :
  {
    . = ALIGN(4);
    KEEP(*(.isr_vector)) /* Startup code */
    . = ALIGN(4);
  } >FLASH

  /* The program code and other data goes into FLASH */
  .text :
  {
    . = ALIGN(4);
    *(.text)           /* .text sections (code) */
    *(.text*)          /* .text* sections (code) */
    *(.rodata)         /* .rodata sections (constants, strings, etc.) */
    *(.rodata*)        /* .rodata* sections (constants, strings, etc.) */
    *(.glue_7)         /* glue arm to thumb code */
    *(.glue_7t)        /* glue thumb to arm code */
  *(.eh_frame)

    KEEP (*(.init))
    KEEP (*(.fini))

    . = ALIGN(4);
    _etext = .;        /* define a global symbols at end of code */
  } >FLASH

-------------------------------
In diesem Beitrag ist das Problem auch schon geschildert worden:

STM32 : internen Flash löschen/schreiben - CPU stall mit STLINK 
detektieren?
Beitrag "STM32 : internen Flash löschen/schreiben - CPU stall mit STLINK detektieren?"

In diesem Beitrag
https://stackoverflow.com/questions/36244319/why-cant-write-internal-flash-of-same-address-twice

heisst es auch in einem Kommentar:

normally you can read one page while writing/erasing another, but in STM32 the entire flash bus stalls, so no no code in flash runs - stalling execution for significant periods (tens of milliseconds)

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Um waehrend des Flashzugriffes bei den Single Bank STM32 Bauteilen 
weiterarbeiten zu koennen, wirst Du wie ein Fuchs darauf aufpassen 
muessen , dass Dein Code im Ram nicht irgendetwas aus dem Flash braucht: 
Code, Daten, Literal, Interrupt Vektoren etc.

[Jim M. (turboj)]

stm32user schrieb:
> Aufgrund der
> Löschzeit von max. 40ms möchte ich aber parallel weiter meine
> Main-Funktion / andere Funktionen und Interrupts abarbeiten und auf ein
> Flash-Interrupt warten, also kein Busywait.

Dann hol Dir einen dicken µC, der entweder 2 kompltt getrennte Flash 
Bereiche hat (z.B. EFM32GG) oder den kompletten Code aus dem RAM 
ausführen kann.

[Jim M. (turboj)]

stm32user schrieb:
> Ist es dann
> notwendig, dass ich mein Linkerfile anpassen muss um den Code in den
> SRAM zu bekommen?

Nicht nur das Linker File. Auch den Startup Code müsstest Du dann 
anpassen, denn es muss ja mindestens so etwas wie memcpy() im Flash 
verbleiben zuzüglich einer Kopie der Interrupt Vektor Tabelle.

[Curby23523 N. (Gast)]

Mir gefällt die Speicheraufteilung der STM32 für nichtflüchtige Daten 
generell nicht - der wohl größte Minuspunkt an diesen Controllern. Ich 
verwende daher immer ein externes EEPROM, auch wenn das etwas mehr Platz 
und Geld kostet.

Ansonsten ist das wichtigste gesagt. Aufpassen, dass dein Code keinen 
Flashzugriff benötigt. Mit einem SPI EEPROM passiert mir sowas aber 
nicht ;).

[stm32user (Gast)]

Eine Ergänzung von mir die meine Zweifel bestärkt, scheint als ob der 
ganze Controller ausser Gefecht gesetzt wird:
https://community.st.com/thread/30821

>wirst Du wie ein Fuchs darauf aufpassen
>muessen , dass Dein Code im Ram nicht irgendetwas aus dem Flash braucht

Sprich: Mit meinem aktuellen Linkerfile (ganzer Code im Flash) kann ich 
mein Vorhaben in die Tonne kloppen?

Ich hab > 5k Code im Flash, aber nur ein 4k RAM. Damit ist also dieses 
"Parallele abarbeiten der main / andere Unterfunktionen" wohl 
Wunschdenken und verdammt kompliziert.


Ich muss also mit sowas arbeiten, richtig?

__attribute__( ( section(".data") ) ) void 
TIM3_IRQHandler .....

Dann hol Dir einen dicken µC

Ich kann die Hardware nicht wechseln.

[Jim M. (turboj)]

stm32user schrieb:
> Ich muss also mit sowas arbeiten, richtig?

Ich hätte die Section ".data.TIM3_IRQHandler" genannt, aber ungefähr 
richtig.

Du musst aber auch zwingend die Vektor-Tabelle ins RAM schieben, und ich 
weiss grade nicht ob der Cortex-M0 überhaupt das dafür notwendige VTOR 
Register kennt. War das nicht ein optionales Feature...?

[stm32user (Gast)]

Ich hab kurz in die Headerfiles geschaut und konnte nichts finden beim 
M0.

core_cm0.h:

typedef struct
{
  __I  uint32_t CPUID;                   /*!< Offset: 0x000 (R/ )  CPUID Base Register                                   */
  __IO uint32_t ICSR;                    /*!< Offset: 0x004 (R/W)  Interrupt Control and State Register                  */
       uint32_t RESERVED0;
  __IO uint32_t AIRCR;                   /*!< Offset: 0x00C (R/W)  Application Interrupt and Reset Control Register      */
  __IO uint32_t SCR;                     /*!< Offset: 0x010 (R/W)  System Control Register                               */
  __IO uint32_t CCR;                     /*!< Offset: 0x014 (R/W)  Configuration Control Register                        */
       uint32_t RESERVED1;
  __IO uint32_t SHP[2];                  /*!< Offset: 0x01C (R/W)  System Handlers Priority Registers. [0] is RESERVED   */
  __IO uint32_t SHCSR;                   /*!< Offset: 0x024 (R/W)  System Handler Control and State Register             */
} SCB_Type;

core_cm4.h:

typedef struct
{
  __I  uint32_t CPUID;                   /*!< Offset: 0x000 (R/ )  CPUID Base Register                                   */
  __IO uint32_t ICSR;                    /*!< Offset: 0x004 (R/W)  Interrupt Control and State Register                  */
  __IO uint32_t VTOR;                    /*!< Offset: 0x008 (R/W)  Vector Table Offset Register                          */
  __IO uint32_t AIRCR;                   /*!< Offset: 0x00C (R/W)  Application Interrupt and Reset Control Register      */
  __IO uint32_t SCR;                     /*!< Offset: 0x010 (R/W)  System Control Register                               */
  __IO uint32_t CCR;                     /*!< Offset: 0x014 (R/W)  Configuration Control Register                        */
  __IO uint8_t  SHP[12];                 /*!< Offset: 0x018 (R/W)  System Handlers Priority Registers (4-7, 8-11, 12-15) */
  __IO uint32_t SHCSR;                   /*!< Offset: 0x024 (R/W)  System Handler Control and State Register             */
  __IO uint32_t CFSR;                    /*!< Offset: 0x028 (R/W)  Configurable Fault Status Register                    */
  __IO uint32_t HFSR;                    /*!< Offset: 0x02C (R/W)  HardFault Status Register                             */
  __IO uint32_t DFSR;                    /*!< Offset: 0x030 (R/W)  Debug Fault Status Register                           */
  __IO uint32_t MMFAR;                   /*!< Offset: 0x034 (R/W)  MemManage Fault Address Register                      */
  __IO uint32_t BFAR;                    /*!< Offset: 0x038 (R/W)  BusFault Address Register                             */
  __IO uint32_t AFSR;                    /*!< Offset: 0x03C (R/W)  Auxiliary Fault Status Register                       */
  __I  uint32_t PFR[2];                  /*!< Offset: 0x040 (R/ )  Processor Feature Register                            */
  __I  uint32_t DFR;                     /*!< Offset: 0x048 (R/ )  Debug Feature Register                                */
  __I  uint32_t ADR;                     /*!< Offset: 0x04C (R/ )  Auxiliary Feature Register                            */
  __I  uint32_t MMFR[4];                 /*!< Offset: 0x050 (R/ )  Memory Model Feature Register                         */
  __I  uint32_t ISAR[5];                 /*!< Offset: 0x060 (R/ )  Instruction Set Attributes Register                   */
       uint32_t RESERVED0[5];
  __IO uint32_t CPACR;                   /*!< Offset: 0x088 (R/W)  Coprocessor Access Control Register                   */
} SCB_Type;

Anscheinend hat M0 im Vergleich zu M4 die Funktion nicht.



Was ist eigentlich mit diesem Codeausschnitt von ST aus der StdLib?

FLASH_Status FLASH_WaitForLastOperation(uint32_t Timeout)
{ 
  FLASH_Status status = FLASH_COMPLETE;
   
  /* Check for the FLASH Status */
  status = FLASH_GetStatus();
  
  /* Wait for a FLASH operation to complete or a TIMEOUT to occur */
  while((status == FLASH_BUSY) && (Timeout != 0x00))
  {
    status = FLASH_GetStatus();
    Timeout--;
  }
  
  if(Timeout == 0x00 )
  {
    status = FLASH_TIMEOUT;
  }
  /* Return the operation status */
  return status;
}

Wird die while-Schleife ueberhaupt ausgefuehrt waehrend des Loeschens 
einer Seite und wie?

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Jim M. schrieb:
> Du musst aber auch zwingend die Vektor-Tabelle ins RAM schieben, und ich
> weiss grade nicht ob der Cortex-M0 überhaupt das dafür notwendige VTOR
> Register kennt. War das nicht ein optionales Feature...?

Die STM32F0 Serie hat kein VTOR. Um das zu umgehen mappe ich mit SYSCFG 
das Ram an Adresse 0. Dann ist die Interrupttabelle im Ram aktiv.

[Dr. Sommer (Gast)]

stm32user schrieb:
> Ich hab > 5k Code im Flash, aber nur ein 4k RAM.

Kannst du den Code, der parallel zum schreiben läuft, nicht eingrenzen 
sodass nur ein "Notprogramm" in den RAM passen muss? Kannst du einfach 
nach dem Abschalten des Geräts schreiben indem du einen Kondensator als 
Puffer verbaust? Reduziert auch die Flash Abnutzung.

[TriHexagon (Gast)]

Wäre es denn in der Zeit möglich auf die Ereignisse mit DMA zu 
reagieren?

[stm32user (Gast)]

Danke, für die Antworten.

Ich wünschte ich hätte dieses Dokument früher gefunden und mir die 
Sucharbeit erspart:

AN4808

Writing to non-volatile memory without disrupting code execution
 on microcontrollers of the STM32L0 and STM32L1 Series

http://www.st.com/content/ccc/resource/technical/document/application_note/group0/7c/6a/88/d1/27/04/46/2f/DM00260799/files/DM00260799.pdf/jcr:content/translations/en.DM00260799.pdf

Schade das im Reference Manual dieser ganze Sachverhalt nur in paar 
Sätzen kurz nebenbei erläutert wird.

>Kannst du den Code, der parallel zum schreiben läuft,
>nicht eingrenzen sodass nur ein "Notprogramm" in den RAM passen muss

Das werd ich wohl machen müssen, da ich heute rausgefunden habe, dass 
sogar (hochpriorisierte) Interrupts nicht bearbeitet werden während 
dieser Zeit - was fatal ist ... sogar Watchdogs.

>Wäre es denn in der Zeit möglich auf die Ereignisse mit DMA zu
reagieren?

Ich hatte eher die Idee an eine komplette quasi-Multitaskanwendung 
gedacht, also mit mehreren Tasks ...


Kann mir jemand noch vielleicht verraten, was der Sinn hinter der 
Funktion ist, die ja im Flash ausgefuehrt wird:

FLASH_Status FLASH_WaitForLastOperation(uint32_t Timeout)

[S. R. (svenska)]

stm32user schrieb:
> Kann mir jemand noch vielleicht verraten, was der Sinn hinter der
> Funktion ist, die ja im Flash ausgefuehrt wird:

Wenn ein Not-Programm aus dem RAM ausgeführt wird, dann muss es 
irgendwie rauskriegen können, ob es seinen Zweck erfüllt hat und wieder 
an das Hauptprogramm abgeben darf.

[ProgNix (Gast)]

Die Löschzeit ist im Verhältnis zur Schreibzeit von zwei Byte ja recht 
lang.
(ms v. µS)

Vielleicht kannst du das Löschen auf unkritische Zeitpunkte legen (z.B. 
Startup)

[stm32user (Gast)]

>Wenn ein Not-Programm aus dem RAM ausgeführt wird

Diese ganzen Funktionen wie EraseFlash, ProgramHalfWord, .. SOLLTEN also 
aus dem RAM aufgerufen werden. Weil ja sonst die nächste Programmzeile 
nach dem Funktionsaufruf die CPU Blockade hervorrufen würde.

Schade das diese Empfehlung mit der Auslagerung in den RAM gar nicht im 
Code/StdLib dokumentiert ist. Wenn ich mich irre, bitte Bescheid sagen. 
Alles sehr mager beschrieben