Busmatrix STM32F411 und F413

OP (Firma: fritzler-avr.de) #5528434
Lesenswert?

Hallo,
weis jemand was sich ST dabei gedacht hat?
Der SRAM hängt normalerweise in der Busmatrix am D-Bus des ARM Kerns.
Beim STM32F413 jedoch machen die das nicht so.
Bei diesem hängt der SRAM nur am S-Bus und nur durch ein remappen nach 
0x00000000 hängt der wieder am D-Bus.
Dann kann meine MPU Implementierung keine Nullpointerzugriffe mehr 
finden.

Im DB steht dazu noch folgendes:
CPU can access SRAM1 memory via S-bus, when SRAM1 is mapped at the 
address range: 0x2000 0000 to 0x2003 FFFF.
CPU can access SRAM2 memory via S-bus, when SRAM2 is mapped at the 
address range: 0x2004 0000 to 0x2004 FFFF.
CPU can access SRAM1 memory via I-bus and D-bus, when SRAM1 is remapped 
at address 0x0000 0000 either by booting from RAM memory or by the remap 
mode.
CPU can access SRAM2 memory via I-bus and D-bus, when SRAM2 is mapped at 
the address range: 0x1000 0000 to 0x1000 FFFF.
Performance boosts up, when the CPU access SRAM memory via the I-bus.

Hat da wer ne idee was die dazu bewegt hat?
ARM gibt ja eigentlich vor, dass der am D-Bus hängen muss ab 0x20000000?
Angehängte Dateien:
OP (Firma: fritzler-avr.de) #5528640
Lesenswert?

Na wenn ich den SRAM nach 0x00000000 remappen muss, damit er am D-Bus 
hängt, dann sind an der Stelle valide Daten.
Da kann ich ja erst garnicht per MPU sperren.
Das meinte ich mit
"Dann kann meine MPU Implementierung keine Nullpointerzugriffe mehr
finden.".

Bisher schiebe ich die IVT per VTOR "zurück" in den Flash und sperre 
dann alles von 0x00000000 bis zum Flashanfang.
Sämtliche Zugriffe im vorderen Bereich zeigt mir die MPU dann per Fault 
an.
Find ich sehr praktisch während der Entwicklung von Code.
Dann sieht man gleich wo genau es knallt und nicht erst irgendwelche 
Sekundärfehler wenn eine Variable falsch gelesen wurde (Pounter auf nen 
struct ist NULL).

Du meinst also, dass auch beim F411 per S-Bus auf den SRAM zugegriffen 
wird?
OP (Firma: fritzler-avr.de) #5528704
Lesenswert?

AH!
Jetz hats klick gemacht.

Trotz der Knubbels in der STM Busmatrix wurde auch so schon nur per 
S-Bus darauf zugegriffen.
ST hats bei dem neueren F413 nur verdeutlicht.

Lektüre zu den Bussen und den Adressbereichen:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439b/CACDHCFH.html

Warum das jetz so ist erschließt sich mir nicht.
Eigentlich würde ich den SRAM am D-Bus erwarten und die ganzen 
Peripherieregister am S-Bus (letzteres ist ja auch so).

Danke für den Denkanstoß!


Dann ist das jetzt aber nicht der Grund wieso man eim Debuggen mit dem 
F413 einschläft.

Ich hab hiern STM32F411 Disovery Board und der RAM wurde zu klein, also 
den Pinkompatiblen F413 mit 320kB RAM statt der bisherigen 128kB 
raufgelötet.
Laut DaBla ist er auch Softwarekompatibel.
Ein Debugstep dauert nun nen aber paar Sekunden!
(natürlich hab ich die Änderung auch im Debugger und Compiler 
nachgezogen)
Daher suche ich jetzt nach Ursachen.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren