STM32L4: Flash Erase gibt HardFault

[Max G. (l0wside)]

Guten Morgen zusammen,

der Versuch, auf einem Nucleo STM32L452 eine Page des Flash zu 
beschreiben, endet regelmäßig im HardFault - und ich verstehe den Grund 
nicht. In CFSR steht IACCVIOL auf 1 - access violation, aber wo und 
warum???

In main.c wird die Clock angeschaltet:

RCC->AHB1ENR |= RCC_AHB1ENR_DMA1EN | RCC_AHB1ENR_FLASHEN;

Die Struktur im Flash, in die ich schreiben will, ist wie folgt 
deklariert:

typedef struct {
  uint16_t ofs_x;
  uint32_t scale_x;
  uint16_t ofs_y;
  uint32_t scale_y;
} touch_calibration_t;

touch_calibration_t touch_calibration __attribute__ ((section("persist"))) __attribute__((aligned(64)));

Im Linker File steht:

  persist :
  {
    KEEP(*(persist))
    . = ALIGN(4);
    *(.persist)
    . = ALIGN(4);
  } > FLASH

Das Alignment scheint auch zu funktionieren, jedenfalls liegt das an 
0x08052A40 - 64-bit Alignment passt also.

Im Moment wäre ich schon froh, wenn ich unfallfrei löschen könnte. Beide 
Varianten unten führen zum HardFault.
Irritierenderweise ist das Flash SR nach dem Löschen völlig unauffällig 
(EOP gesetzt, sonst alles 0). Die Page ist auch gelöscht, jedenfalls 
laut Debugger.

uint32_t write_persist (uint32_t StartPageAddress, uint32_t *data, uint16_t numberofwords)
{

  static FLASH_EraseInitTypeDef EraseInitStruct;
  uint32_t PAGEError;
  int sofar=0;
  __disable_irq();
    /* Unlock the Flash to enable the flash control register access *************/
  uint32_t acr_backup = FLASH->ACR;
  FLASH->ACR = FLASH_ACR_LATENCY_4WS; /* disable caches, set to maximum wait states */
  while(FLASH->SR & FLASH_SR_BSY);
  HAL_FLASH_Unlock();

  /* Erase the user Flash area*/
  uint32_t StartPage = (StartPageAddress - FLASH_BASE) >> 11;
  uint32_t EndPageAdress = StartPageAddress + numberofwords*4;
  uint32_t EndPage = (EndPageAdress - FLASH_BASE) >> 11;

  /* Fill EraseInit structure*/
  EraseInitStruct.TypeErase   = FLASH_TYPEERASE_PAGES;
  EraseInitStruct.Page = StartPage;
  EraseInitStruct.NbPages     = ((EndPage - StartPage)/FLASH_PAGE_SIZE) +1;

  if (HAL_FLASHEx_Erase(&EraseInitStruct, &PAGEError) != HAL_OK)
  {
      /*Error occurred while page erase.*/
    __enable_irq();
      return HAL_FLASH_GetError ();
    }
  FLASH->ACR = acr_backup;
  HAL_FLASH_Lock();

  __enable_irq();
}

uint32_t write_persist (uint32_t StartPageAddress, uint32_t *data, uint16_t numberofwords)
{

  static FLASH_EraseInitTypeDef EraseInitStruct;
  uint32_t PAGEError;
  int sofar=0;
  __disable_irq();
    /* Unlock the Flash to enable the flash control register access *************/
  uint32_t acr_backup = FLASH->ACR;
  FLASH->ACR = FLASH_ACR_LATENCY_4WS; /* disable caches, set to maximum wait states */
  while(FLASH->SR & FLASH_SR_BSY);
  HAL_FLASH_Unlock();

  /* Erase the user Flash area*/
      while(FLASH->SR & FLASH_SR_BSY);
    uint16_t page = (((uint32_t)&touch_calibration) - FLASH_BASE) >> 11;
    FLASH->CR = FLASH_CR_PER | (page << FLASH_CR_PNB_Pos) | FLASH_CR_STRT | FLASH_CR_EOPIE;
    while(FLASH->SR & FLASH_SR_BSY);
    FLASH->CR &= ~(FLASH_CR_PER | FLASH_CR_PNB_Msk | FLASH_CR_EOPIE);
  FLASH->ACR = acr_backup;
  HAL_FLASH_Lock();

  __enable_irq();
}

Der Rechtsshift um 11 bit dient der Division durch 2048 - die Page Size 
im Flash.

Der HardFault tritt erst dann auf, wenn ich einen Reset versuche. Am 
nachfolgenden Code kann es aber nicht liegen, denn den Effekt habe ich 
auch dann, wenn als nächster Aufruf while(1) folgt.


Any ideas? Inzwischen sind mir die Ideen ausgegangen.

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

Warum align(4) und nicht (8)? Was sagt der Debugger?

[Max G. (l0wside)]

align(8) ist natürlich plausibel, du hast Recht. Hat das Problem aber 
auch nicht gelöst (und war auch vorher schon, ziemlich unglücklich, 
durch das __attribute__((aligned(64))) erschlagen).

Was genau meinst du mit "was sagt der Debugger"?

[pegel (Gast)]

~/STM32Cube/Repository/STM32Cube_FW_L4_V1.17.2/Projects/NUCLEO-L452RE/Ex 
amples/FLASH

Vielleicht hilft das zur Orientierung.

[Michael F. (Firma: IAR Systems) (michael_iar)]

Max G. schrieb:
> In CFSR steht IACCVIOL auf 1 - access violation, aber wo und
> warum???

Moin,

laut Arm Cortex-M4 User Guide sollte bei IACCVIOL die verursachende 
Adresse des Program Counters gespeichert werden:

1 = the processor attempted an instruction fetch from a location that does not permit execution. This fault occurs on any access to an XN region, even when the MPU is disabled or not present. When this bit is 1, the PC value stacked for the exception return points to the faulting instruction.

Steht was plausibles in LR / R14?

Gruß,
Michael

[Jim M. (turboj)]

Löschen geht doch nur für ganze Pages, die 11 Bits benötigen ein 
Alignment von 2048 Byte - jedenfalls sieht das für mich so aus.

Wenn Du Teile Deines Programms mit löschst sind Hard Faults die logische 
Folge. Hast Du mal den Flash komplett ausgelesen und mit dem Programm 
(binary/hex) verglichen?

[Max G. (l0wside)]

Jim M. schrieb:
> Wenn Du Teile Deines Programms mit löschst sind Hard Faults die logische
> Folge. Hast Du mal den Flash komplett ausgelesen und mit dem Programm
> (binary/hex) verglichen?
Auch wenn ich den ersten Teil deines Beitrags nicht so recht verstanden 
habe (die Pages werden mit ihrer Nummer, nicht mit der Adresse 
angesprochen, daher der Rechtsshift), hast du mich auf die richtige Spur 
gebracht.

Das Linker-File sieht nun wie so aus:

MEMORY
{
  RAM    (xrw)    : ORIGIN = 0x20000000,   LENGTH = 160K
  RAM2    (xrw)    : ORIGIN = 0x10000000,   LENGTH = 32K
  FLASH    (rx)    : ORIGIN = 0x8000000,   LENGTH = 510K
  EEPROM   (rx)    : ORIGIN = 0x807F800,   LENGTH = 2K
}
[...]
  persist :
  {
    KEEP(*(persist))
    . = ALIGN(8);
    *(.persist)
    . = ALIGN(8);
  } > EEPROM

In der ursprünglichen Version war die section irgendwo am Ende des 
Bootcodes gelandet, so dass die Löschaktion den Bootcode mit entsorgt 
hat. Das hat wenig erstaunlich den Hardfault verursacht.
Sieht aus, als wäre es nun i.O.

Danke allen Helfern!