STM32F4 Flash Unlock -> Hard Fault

[Felix F. (wiesel8)]

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:

FLASH->KEYR = FLASH_KEY1;

mfg

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

Aus RM0090, 3.6.1 Unlocking the Flash control register:
Any wrong sequence will return a bus error and lock up the FLASH_CR 
register until the next reset.

[Felix F. (wiesel8)]

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.

#define FLASH_KEY1               ((uint32_t)0x45670123)
#define FLASH_KEY2               ((uint32_t)0xCDEF89AB)

void FLASH_Unlock(void)
{
  if((FLASH->CR & FLASH_CR_LOCK) != RESET)
  {
    /* Authorize the FLASH Registers access */
    FLASH->KEYR = FLASH_KEY1;
    FLASH->KEYR = FLASH_KEY2;
  }  
}

int main()
{
  FLASH_Unlock();
  
  while(1);
}

mfg

[Mike R. (thesealion)]

Hi,

du schreibst deine Keys in das falsche Register.

Laut Reference Manual (3.9.4) müssen die nach

FLASH->OPTKEYR

Gruß Mike

Edit: Ups. hab gerade gesehen ,das es zwei Register gibt. Eins für das 
Options Byte und eins for den Flash.

[A. B. (Gast)]

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?

[A. B. (Gast)]

Und: FLASH_SR VOR bzw. NACH dem Unlock-Versuch???

[Felix F. (wiesel8)]

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

[A. B. (Gast)]

> 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.

[Martin (Gast)]

in Rcc den Flash aktivieren

[fft (Gast)]

Den Fehler hatte ich auch :-)

Schau dir mal an, womit der Flash-controller getaktet ist...

[Felix F. (wiesel8)]

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