STM32F4-Bootkonzepte und Vektortabellenverschiebung

Es gibt einige Dinge, die ich beim Startvorgang des STM32F4-Mikrocontrollers nicht verstehe.

Mein Verständnis ist wie folgt:

1. Der ARM Cortex-M4-Start erwartet den Stapelzeiger-Initialisierungswert und die Interrupt-Vektoren an 0x00000000 + SCB->VTOR, während er SCB->VTORbeim Zurücksetzen gelöscht wird.
2. An diesem Ort ist kein Speicher vorhanden. Flash-Speicher beginnt um 0x08000000, SRAM um 0x20000000.
3. Um das Booten zu ermöglichen, kann der µC den Flash- oder SRAM-Speicherbereich abbilden 0x00000000. Der zuzuordnende Speicherbereich wird durch den Status der Boot-Pins definiert.

Meine Fragen:

1. Warum ist das STM32F4 Referenzhandbuch sagen , auf Seite 69 , dass

   Wenn das Gerät vom SRAM startet, müssen Sie im Anwendungsinitialisierungscode die Vektortabelle im SRAM mithilfe der NVIC-Ausnahmetabelle und des Offset-Registers verschieben.

   ? Aus meiner Sicht ist dies nicht erforderlich, da der gesamte Speicherbereich ohnehin einen Alias ​​aufweist. Interessanterweise scheint dies nicht erforderlich zu sein, wenn der Flash-Bereich dem 0x0Speicherplatz neu zugeordnet wird.

2. Die einzige Verwendung zum Booten von SRAM, die ich mir vorstellen kann, besteht darin, die Schreibzyklen auf dem Flash während der Entwicklung zu reduzieren. Bevor Sie das Zurücksetzen des µC freigeben, schreiben Sie das Programm mit dem Debugger in den SRAM und starten von dort aus. Da Sie jedoch über Debugger-Zugriff verfügen, gibt es ohnehin keine Einschränkungen hinsichtlich des Startorts. Warum also diese Funktion?

   Dass die Boot-Position von Pins abgeleitet ist, zeigt (zumindest meiner Meinung nach) an, dass diese Funktion nicht während der Entwicklung, sondern im endgültigen Betrieb verwendet werden soll. Und im endgültigen Betrieb ist SRAM beim Booten klar. Daher ist es nicht sinnvoll, von SRAM zu booten.

Frage 1:

Ich kann Ihre erste Frage nicht definitiv beantworten. In dem Programmierhandbuch, in dem das VTOR-Register beschrieben ist ( Seite 212 ), heißt es jedoch, dass Bit 29 verwendet wird, um zu bestimmen, wo sich die Vektortabelle entweder im Codebereich (0) oder im SRAM-Bereich (1) befindet.

Jetzt verstehe ich nicht, warum dies aus dem gleichen Grund erfolgen muss, den Sie angeben. Der SRAM wird auf 0x0 ausgerichtet. Warum muss dieser Offset festgelegt werden?

Die einzige Vermutung, die ich habe, ist auf Ihrer zitierten Seite 69 angegeben. Sie sagen:

Der Codebereich beginnt bei der Adresse 0x0000 0000 (Zugriff über die ICode / DCode-Busse).

Der Datenbereich (SRAM) beginnt bei der Adresse 0x2000 0000 (Zugriff über den Systembus).

Der Cortex ® -M4 mit FPU-CPU ruft immer den Rücksetzvektor auf dem ICode-Bus ab

Möglicherweise wird bei einem Interrupt der ICode-Bus verwendet, der auch bei erneuter Zuordnung nicht auf den SRAM zugreifen kann (ich weiß nicht, ob dies der Fall ist). Dies würde erklären, warum dieses Bit entsprechend gesetzt werden muss, und den Kern anweisen, den Systembus zu verwenden und auf den SRAM zuzugreifen.

Frage 2:

Es mag zwar zutreffen, dass der SRAM beim ersten Start des Geräts leer ist, dies ist jedoch nicht unbedingt für spätere Starts erforderlich. Sie könnten also so etwas wie ein batteriebetriebenes Gerät erstellen, dessen SRAM während der Produktion programmiert wird und dann ausgeführt wird, bis die Batterie leer ist, wodurch der SRAM gelöscht wird. Ich denke, dies würde das Reverse Engineering des Geräts etwas schwieriger machen.

In einem batteriebetriebenen Gerät würden Sie wahrscheinlich den Standby-Modus verwenden, um Strom zu sparen. Wenn Sie diesen Modus verlassen, werden die Boot-Pins erneut abgetastet, sodass sie die richtige Einstellung haben müssen, um wieder zum SRAM zu gelangen.

Sie können das Gerät auch sicher neu starten, da der Inhalt des SRAM nicht zerstört wird, wenn kein Stromausfall vorliegt.

Keine sehr überzeugende Anwendung, um alle Probleme bei der Neuzuordnung des SRAM zu beheben.