STM32F4 Flash Unlock -> Hard Fault

OP #5005109
Lesenswert?

Hallo,

ich versuche mich gerade an der EEPROM Emulation bei einem F4. Leider 
scheitert schon der Befehl Flash_Unlock().

Ich kann voll auf den Chip zu greifen, Programmieren, Löschen etc. Laut 
ST Utility sind keine Lock Bits gesetzt. Trotzdem führt der Aufruf der 
Funktion zu einem Hard Fault.

Die 1. Zeile führt sofort zu einem Hard Fault:
1
FLASH->KEYR = FLASH_KEY1;

mfg
OP #5006730
Lesenswert?

Das hilft mir nur leider nicht wirklich weiter. Ich Unlocke den Flash 
sofort in der Main mit der Funktion aus der SPL, welche korrekt ist.

1
#define FLASH_KEY1               ((uint32_t)0x45670123)
2
#define FLASH_KEY2               ((uint32_t)0xCDEF89AB)
3

4
void FLASH_Unlock(void)
5
{
6
  if((FLASH->CR & FLASH_CR_LOCK) != RESET)
7
  {
8
    /* Authorize the FLASH Registers access */
9
    FLASH->KEYR = FLASH_KEY1;
10
    FLASH->KEYR = FLASH_KEY2;
11
  }  
12
}
13

14
int main()
15
{
16
  FLASH_Unlock();
17
  
18
  while(1);
19
}

mfg
Gast #5007011
Lesenswert?

An und für sich ist die Sequenz doch korrekt. Da muss also irgendwo 
drumherum was falsch sein.

Wo kommt die Deklarationen vom FLASH->KEYR her? volatile???
Ist das Fragment direkt aus der SPL oder eine Kopie? Dto. bzgl. der 
Header.
Optimiert der Compiler vielleicht die erste Zuweisung weg?
Das "(FLASH->CR & FLASH_CR_LOCK) != RESET" sieht etwas merkwürdig aus.
"(FLASH->CR & FLASH_CR_LOCK)" sollte doch reichen?!
Clocks? Vielleicht kurze Pause zwischen den beiden Schreibzugriffen?
OP #5007038
Lesenswert?

Der Code (bis zu int main()..) ist aus der SPL rauskopiert (zum bessern 
Verständnis). Ich habe diese Funktion also nicht selbst implementiert 
etc. Ich rufe die fertige, von mir nicht veränderte SPL Funktion 
lediglich auf, genauso wie es auch in den Examples ist.

Status Reg muss ich noch checken, da ich aber im Hardfault lande, weiß 
ich nicht ob ein "Nachher" möglich ist.

mfg
Gast #5007043
Lesenswert?

> Status Reg muss ich noch checken, da ich aber im Hardfault lande, weiß
> ich nicht ob ein "Nachher" möglich ist.

Naja, das Debug-Interface ist auch gerade dazu da, bei angehaltener CPU 
Speicher und Register untersuchen zu können. Nach einem HardFault kann 
man in Ruhe alles bis zum letzten Bit untersuchen ...

Und ein Blick ins Assembler-Listing lohnt auch. Gelegentlich machen 
Compiler irgendwelchen Murks.

Es muss ja irgendwo etwas faul sein, und da hilft wohl nur, den Blick 
großzügig schweifen zu lassen und alles zu hinterfragen.
OP #5007673
Lesenswert?

Ich glaube ich habe den Fehler gefunden. Es war wohl die Compileroption 
-fpack-struct

Nachdem ich diese entfernt hatte, da sie bereits anderweitig einen 
Hardfault bei einer float-Berechnung verursacht hat (x = 
lround(struct.y)), funktioniert es nun.

Wobei ich aber nicht verstehe, warum diese Option mehrfach im Code einen 
Hardfault provoziert...

mfg

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren