STM32F4 Programm im RAM ausführen

du musst:

- linker-file anpassen (dein Programm in den RAM linken)
Ich weiß nicht ob Coocox da nachgebessert hat, in den Versionen die ich 
benutzt habe waren Speicher-Anpassungen etwas tricky (ich habe mir eine 
kopie des linkerfiles gemacht und dann in dieser Einstellungsseite 
umgeändert). Evtl reicht bei dir die Anpassung auf der Einstellungsseite 
aus...

- bootpin richtig setzen (BOOT0, BOOT1; bitte im Datenblatt / Refman. 
die richtige Beschaltung nachlesen)

Den Standard Radiobutton "Debug in RAM" habe ich schon auf alle 
erdenklichen weisen ausprobiert, hat leider nur zu Müll auf dem Display 
und sonst nichts geführt.

Phantomix Ximotnahp schrieb:
> du musst:
>
> - linker-file anpassen (dein Programm in den RAM linken)
> Ich weiß nicht ob Coocox da nachgebessert hat, in den Versionen die ich
> benutzt habe waren Speicher-Anpassungen etwas tricky (ich habe mir eine
> kopie des linkerfiles gemacht und dann in dieser Einstellungsseite
> umgeändert). Evtl reicht bei dir die Anpassung auf der Einstellungsseite
> aus...
>
> - bootpin richtig setzen (BOOT0, BOOT1; bitte im Datenblatt / Refman.
> die richtige Beschaltung nachlesen)

Auch eine Anpassung des linker-files hat zu keinem anderen Ergebnis 
geführt, es kam genau das selbe dabei heraus.

Ist die Beschaltung der Bootpins zwingend, auch wenn ich nicht resetten 
können will? (Nur Debuggen am Rechner auswählen)

Ok, dann zieh ich die Boot-Pins mal hoch.

Kannst du mir erklären, was dann passiert? Was macht der µC dann? Eben 
mit Interruptvektoren usw.

Die Interruptvectoren stehen immer am Anfang. Beim Linken im RAM werden 
die an Adresse 0x20000000 gelinkt, durch die Boot-Pin Konfiguration 
"RAM" wird der RAM Bereich mit der Adresse 0x20000000 auch an Adresse 
0x00000000 gespiegelt, denn nach dem Reset liest die CPU ab Adresse 
0x00000000 in der Vectortabelle.
Man könnte das Programm also auch ab Adresse 0x00000000 linken und in 
das Ram ab Adresse 0x20000000 rein schreiben, das würde genau so laufen.

Das hab ich jetzt ehrlich gesagt nicht ganz verstanden.

Ich hab die Bootpins beschalten, der Effekt ist leider der selbe.

Die Boot-Pin Beschaltung ist hier beschrieben:
http://www.mikrocontroller.net/articles/STM32#Bootmodi
oder in der Doku.

Der gelinkte Code müsste dann mit der Vector-Tabelle ab Adresse 
0x20000000 sein, das kann man in der .map Datei kontrollieren.

Ich habe das noch nie genutzt, ich flashe immer meine Controller. Bisher 
ist mir noch keiner Kaputt gegangen.

Markus Müller schrieb:
> Die Boot-Pin Beschaltung ist hier beschrieben:
> http://www.mikrocontroller.net/articles/STM32#Bootmodi
> oder in der Doku.

Habe ich schon aus dem Datenblatt geholt, aber danke :)


> Der gelinkte Code müsste dann mit der Vector-Tabelle ab Adresse
> 0x20000000 sein, das kann man in der .map Datei kontrollieren.

Ja, ist er auch, war er ständig. Habe gerade etwas im Forum der IDE 
ausgegraben, scheint ein Bug in der derzeitigen Version zu sein. Dann 
hoffe ich mal, dass es nach dem nächsten Update anders aussieht.


> Ich habe das noch nie genutzt, ich flashe immer meine Controller. Bisher
> ist mir noch keiner Kaputt gegangen.

Habe ich bisher auch, aber die Flashzellen des STM32F4 halten scheinbar 
nur 100 Zyklen, und da ich doch einige male am Tag flashen würde will 
ich lieber auf Nummer sicher gehen :)

100 Zykeln?
kann nicht sein eher das hundertfache.

100?
Das kann sicher nicht sein. Mein STM32F417 flashe ich schon lange 
ständig mit einem neuen Programm.
Im Datenblatt steht "10 kcycles" unter 5.3.12 in der Tabelle 40 
(Datenblatt vom STM32F417xx/Rev. 3)

Tur mir leid, ich meinte 1000 Zyklen :)

Ich finde den Punkt gerade nicht im Datenblatt, aber dann glaube ich mal 
die 10k.

Solang es heißt, dass es an einem Bug in der IDE liegt werde ich mich 
auch nicht weiter darum kümmern.

Vielen Dank an alle :)

Kann mir noch jemand sagen, wo die Lebensdauer des Flash im 
Rev5-Datenblatt steht? Ich finde es einfach nicht, ich hatte noch nie 
dermaßen Probleme mit einem Datenblatt :)

Bei mir sieht die Vectortabelle so aus:

1

const intvec_elem AppVectors[] __attribute__ ((section(".vectors"))) =

2

{

3

  {(intfunc) STACK_TOP},  // stack pointer

4

  {(void *)main},

5

  {NMIException},

6

  {HardFaultException},

7

  {MemManageException},

8

: : :

Und im Linker-Script steht wohin die section .vectors hin kommt. Der 
Stack-Pointer steht da natürlich auch gleich mit drin.

Ich gehe mal davon aus, dass Coocox das von alleine macht, wenn man es 
entsprechend konfiguriert.
Bei Coocox ist das wohl in einer Startup-Assembler Datei, ich habe das 
in C geschrieben und nutze kein Coocox.
Ich habe in meinem Programm gleich 2 solche Vector-Tabellen, eine für 
den Bootloader und eine für die Applikation, beides in einem Projekt. 
Ist ein wenig kniffelig, aber geht.

Datenblatt: "DM00035129" Rev. 4
Seite: 107
Abschnitt 5.3.12 Tabelle 41

Markus Müller schrieb:
> Und im Linker-Script steht wohin die section .vectors hin kommt. Der
> Stack-Pointer steht da natürlich auch gleich mit drin.
>
> Ich gehe mal davon aus, dass Coocox das von alleine macht, wenn man es
> entsprechend konfiguriert.
> Bei Coocox ist das wohl in einer Startup-Assembler Datei, ich habe das
> in C geschrieben und nutze kein Coocox.
> Ich habe in meinem Programm gleich 2 solche Vector-Tabellen, eine für
> den Bootloader und eine für die Applikation, beides in einem Projekt.
> Ist ein wenig kniffelig, aber geht.

Ich werde wohl einfach warten müssen, bis der STM32F429 offiziell 
unterstützt wird^^