|
Anzeige
|
STM32F4 Flash Unlock -> Hard FaultHallo, 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:
mfg 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. 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.
mfg Hi, du schreibst deine Keys in das falsche Register. Laut Reference Manual (3.9.4) müssen die nach
Gruß Mike Edit: Ups. hab gerade gesehen ,das es zwei Register gibt. Eins für das Options Byte und eins for den Flash.
Gast
#5007011
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?
Gast
#5007021
Und: FLASH_SR VOR bzw. NACH dem Unlock-Versuch??? 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
> 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.
Gast
#5007155
in Rcc den Flash aktivieren
Gast
#5007177
Den Fehler hatte ich auch :-) Schau dir mal an, womit der Flash-controller getaktet ist... 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 |
Anzeige
|
