Guten Tag,
bei einem STM32F439 leigt der 2 MByte interne Flash an der Adresse
0x0800 0000 bis 0x081F FFFF.
Ich verstehe noch nicht ganz, was in dem Bereich von 0x0000 0000 bis
0x001F FFFF liegt. Ich möchte gerne, dass mein Controller nach dem Start
Programmcode vom internen Flash ausführt. Also Boot From Flash.
Im Scatter File ist der interne Flash im Bereich 0x0800 0000 bis 0x081F
FFFF angegeben. Kann ich den bereich von 0x0000 0000 bis 0x001F FFFF
völlig ignorieren oder wann bzw. für was wird dieser gebraucht ?
Die Antwort findest du auf Seite 84 des Datenblatts
http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/DM00077036.pdf
"Memory map"
Im Bereich 0x0000 0000 - 0x001F FFFF liegt der Bootbereich, kann auhc in
den RAM gespiegelt werden.
0x0020 0000 - 0x07FF FFFF ist "reserved", in dem Bereich ist also
tatsächlich einfach nichts. bei einer späteren Version mit mehr Fash
könnte das Flash zum Beispiel da rein verlegt werden.
Welchen Bereich muss ich dann im Scatter File für meinen Programmcode (
+RO)
angeben ? Den ab 0x0000 0000 oder den Bereich, in dem der Flash liegt
0x0800 0000 ?
FS-embd schrieb:> Den ab 0x0000 0000 oder den Bereich, in dem der Flash liegt> 0x0800 0000 ?STM32F Flash liegt ab 0x0800... (zumidest bei den mir bekannten F1, F4,
F7).
rgds
Ja da liegt der Flash.
Ich verstehe aber nicht ganz, wann oder ob ich den Bereich ab 0x0000
0000 im Scatter File überhaubt verwenden muss. Mein Programmcode liegt
im internen Flash.
es hat was mit der Architektur des Controllers zu tun.
Das folgende ist nur grob zusammengefasst und vieleicht nicht ganz
korrekt:
Der ARM hat einen Architektur-Hybrid aus vonNeumann und Harvard. Es kann
sowohl Instruktionen vom I-Bus gelesen werden, so wie es bei einem
Harvard gemacht wird. Zusätzlich können aber auch Instruktionen vom
D-Bus gelesen werden, so wie es bei von Neumann der Fall ist. Dies ist
natürlich etwas langsamer, da der Bus-Traffic sich nicht mehr aufteilt.
Jetzt kommt das relevante für dich:
Der I-Bus hat einen begrenzten Adressraum, hier von 0x0 bis 0x1F FFFF.
Hier werden verschiedene Speicherbereiche reingemappt. Beim POR
entscheiden zunächst die Bootpins, welcher Speicher das ist. Im
laufenden Programm kann das über Systemregister nochmals umgestellt
werden, wenn man z.B. Programme aus dem RAM ausführen will.
In den genannten Speicherbereich wird also nichts geschrieben, sondern
ist nur ein Alias für andere Speicherbereiche für den I-Bus.
Vielen Dank für deine Erklärung.
Vielleicht kannst du mir noch bei einer anderen Frage weiterhelfen:
Ich habe gelesen:
"The DMA has its own data bus which is wired to the 128 kB nin CCM-SRAM.
Also it is not possible to use the Non CCM SRAM for both the DMA and
Core at the same time. "
Der STM32F439 besitzt drei SRAM Bereiche. Einmal 112kB, 16 kB und 64 kB.
Wenn mein DMA beispielsweise sehr oft Daten über einen UART in den SRAM
lädt, kann es ja zu Verzögerungen kommen, wenn der Core auf den gleichen
SRAM Block zugreifen möchte.
Bezieht sich diese Einschränkung auf alle drei Bereiche oder kann ich
beispielsweise einen festen Bereich für den DMA in den 64 kB SRAM Block
legen legen, während alles andere vom Core auf diesen Block nie zugreift
?
Ich meine wenn der DMA den 64 kByte SRAM blockiert, sind dann auch die
zwei anderen blockiert oder kann der Core auf diese ohne Einschränkung
gleichzeitig zugreifen ?
Das geht extrem tief in die Bus-Architektur des Controllers. Solche
spezifischen Fragen kann dir dann nur der STM-Support zuverlässig
beantworten.
Wenn du aber tatsächlich Daten vom USART ins RAM speichern willst,
solltest du dir um die Bandbreite absolut keine sorgen machen.
Der schnellste USART im Chip kann 8Mbit, also nicht ganz 1MB/s (wegen
start und stop bits).
Das Ethernet mit 100Mbit full dublex oder DMA transfers memory-to-memory
würde mir da mehr Sorgen machen.
Aussage beim Cortex-M7-HandsOn in Frankfurt:
Die Buslast ist de facto so gering, dass man sich um
Arbitrierungsprobleme zwischen Core und DMA keine Sorgen machen muss.
Da der STM32F4 die selbe peripherie hat wie der STM32F7, vermute ich in
deinem Fall ähnliches.
Um aber sicher zu gehen solltest du den STM-Support fragen.
FS-embd schrieb:> "The DMA has its own data bus which is wired to the 128 kB nin CCM-SRAM.> Also it is not possible to use the Non CCM SRAM for both the DMA and> Core at the same time. ">> Der STM32F439 besitzt drei SRAM Bereiche. Einmal 112kB, 16 kB und 64 kB.
Du solltest schon etwas aufmerksamer lesen.
Zum einen hat der ..439 mehr RAM und CCM ist für DMA tabu. Siehe
Abschnitt: Multi-AHB bus matrix
Ja, der hat drei SRAM Bereiche, mit CCM 4. Deshalb frage ich ja, ob Core
und DMA auf zwei Blöcken parallel arbeiten können ohne sich gegenseitig
zu blockieren.
Das DMA nicht auf CCM zugreifen kann habe ich geschrieben. Leider ist
ein Rechtschreibfehler mit drin. Das sollte non CCM-SRAM heißen.
FS-embd schrieb:> Ja, der hat drei SRAM Bereiche, mit CCM 4. Deshalb frage ich ja, ob Core> und DMA auf zwei Blöcken parallel arbeiten können ohne sich gegenseitig> zu blockieren.>
Klar können sie, dazu sind sie ja da.
DMA und CPU kommen sich nur dann in die Quere, wenn der Zugriff von
beiden in gleichzeitig in die selben Speicherbereiche gehen. In die
Quere heisst aber nur, dass der Zugriff für die CPU während des Transfer
vom/zum DMA gebremst wird. Bei Deinem UART wirst Du das gar nicht
merken.
Gruß Martin
