Busmatrix STM32F411 und F413

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

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?

[Jim M. (turboj)]

Mw E. schrieb:
> ARM gibt ja eigentlich vor, dass der am D-Bus hängen muss ab 0x20000000?

Die 0x20000000 Adresse ist S-Bus. Nur da funktioniert Bitbanding.
Der I- und D-Bus geht nur bis 0x1FFF FFFF.

Wieso Deine MPU Implementierung keine Null Pointer finden kann, dürfte 
ein anderes Problem sein.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

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?

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

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.