Busmatrix STM32F411 und F413

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.

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?

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.