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 ?
Datenblatt Seite 84 Figure 19. Memory Map
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.
Kenne ich, aber das zeigt mir ja nur das was ich schon geschrieben habe.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.