Guten Tag liebe STM32-Nutzer,
mir ist schon vor längerer Zeit im Speicher-Mapping der STMs die Lücke
zwischen den RAM Bereichen aufgefallen.
Da ich meine Linkerscripte etc. immer selbst schreibe, halte ich mich
strikt an die Vorgaben im Datenblatt.
Angehängt ist das Memory-layout eines STM32F205. Der Ram besteht aus
zwei Teilen: Einem oberen, der immer 16KB groß ist und dem unteren, der
je nach Controller unterschiedlich groß ist. Bei Controllern mit
kleinerem RAM, ergibt sich dazwischen eine Lücke.
STM bestätigt dies:
1
Accessing the gap is like accessing any other gap in the memory map. You may end up within a hardfault, or may access location you may not have intended to. You should not access gaps in the memory map in the first place.
Einem Kollegen ist allerdings aufgefallen, dass bei jedem uC der
komplette, voll ausgestattete RAM nutzbar ist. Ansich kein Problem. STM
setzt wohl bei der Produktion keine Fuses, mit denen der Adressdekoder
den Bereich ausgraut.
Wie STM korrekt sagt, sollte der Bereich nicht benutzt werden, da er im
Datenblatt nicht spezifiziert ist.
Doch genau DAS machen die Linkerskripte von CubeMX und auch von anderen
Anbietern. Der gesamte Speicher der Controller wird an einem Stück
definiert. Dies funktioniert nur, weil die Controller, entgegen ihrer
Spezifikation, diese RAM-Bereiche tatsächlich besitzen.
Auf die Frage, ob der RAM da wirklich funktioniert, sagt STM:
1
You are using it on your own risk as these areas are not production tested and we can not guarantee functionality of these regions. We could also disable these regions completely on future device revisions.
2
[...]
3
We may re-layout the chip or alter it in any way whenever it will become necessary.
Auf die Tatsache, dass ihre Code-Generatoren, die - leider - weit
verbreitet sind, den RAM falsch anlegen; in einen Bereich, den sie
selbst als untested bezeichnen:
1
CubeMx seems to be wrong with its linker scripts, thank you for reporting this issue, we have not noticed it. I will forward the issue report to the appropriate team that will fix it in the future revision of CubeMx tool.
Ich möchte damit nicht gegen die STM-Controller Stimmung machen. Die
Controller sind schön und haben nicht umsonst ihre weite Verbreitung.
Ich möchte nur darauf aufmerksam machen, dass überall verwendete Tools
gravierende Fehler enthalten, die bei einem möglichen, aber
unwahrscheinlichen, Chip-Relayout den gesamten Code unnutzbar machen.
Man sollte, auch wenn die Tools vom Hersteller kommen, sich immer
kritisch damit auseinandersetzen, da diese Controller auch in
Sicherheitskritischen Sektoren eingesetzt werden. Oft mit diesen
"fehlerhaften" Linkerskripten.
Viel Erfolg bei euren weiteren STM32 Projekten
Nils N. schrieb:> Wieder ein Vorteil, wenn man auf HAL/CubeMX etc. verzichtet.
Meiner Meinung nach, und man darf das gerne anders sehen, ist die HAL
von ST nicht anderes als ein Vendor-Lock, um dich an ihre Controller zu
binden. Entgegen einer Abstraktion, wie das A in HAL andeutet, machen
die Libs nichts anderes, als hochspezifische Hardware anders
darzustellen. Das ganze in einem ebenso spezifischen Weg, dass da nicht
von HAL gesprochen werden kann. Aber das ist meine Meinung.
Das Problem ist, dass sich die Linkerskripte/startup-Codes, die
teilweise noch andere Fehler enthalten, auch außerhalb der
CubeMX/Keil-"Szene" Anwendung finden.
Was macht man, wenn man damit anfängt mit GCC seine erstes Projekt zu
bauen? Richtig -- Man zieht sich was aus'm Internet und bastelt daran
herum, bis es läuft. Ich denke alle, die Linkerskripte selbst schreiben
bzw. überhaupt schreiben können, haben ihr Wissen aus der Lektüre
bestehender Skripte, da die Doku durchaus etwas versteckt ist. Und
bestehende Fehler pflanzen sich dadurch einfach weiter fort...
M. H. schrieb:> Meiner Meinung nach, und man darf das gerne anders sehen, ist die HAL> von ST nicht anderes als ein Vendor-Lock, um dich an ihre Controller zu> binden.
Das sehe ich genauso wie du.Zusätzlich kommt man in Schwulitäten wenn
etwas nicht funktioniert wie es soll. D.h. die Fehlersuche beginnt.
Zugegeben, Linkerscripte schreibe ich mir bisher nicht selber, schmeiße
aber sämtlichen vordefinierten C-Code aus den Projekte heraus.
zusätzlich verzichte ich auf HAL und StdLib und schreibe alles auf
Register-Ebene.
M. H. schrieb:> Was macht man, wenn man damit anfängt mit GCC seine erstes Projekt zu> bauen? Richtig -- Man zieht sich was aus'm Internet und bastelt daran> herum, bis es läuft. Ich denke alle, die Linkerskripte selbst schreiben> bzw. überhaupt schreiben können, haben ihr Wissen aus der Lektüre> bestehender Skripte, da die Doku durchaus etwas versteckt ist. Und> bestehende Fehler pflanzen sich dadurch einfach weiter fort...
Nichts für ungut, aber von Dir auf andere zu schliessen, ist schon
unverschämt. Erstens gibt es dazu genug Literatur:
http://www.uni-regensburg.de/EDV/kurs_info/brf09510/kurs_info/pdf/ld.pdf
Gibt aber auch Tutorials für unbedarfte Einsteiger.
Nur weil haufenweise Arduino-Stümper jetzt irgendwas aus dem Netz ohne
Verstand zusammenkratzen, heisst das noch nicht, dass das jeder so
macht.
Ich (und auch etliche Freunde) haben das jedenfalls nicht so gemacht,
zumal die Linkerskripte aus dem Netz auch unnötig aufgeblasen sind.
Gleiches gilt übrigens für den (sehr simplen) Startup-Code.
Ich bin der Meinung, das dieser Thread nicht zur Diskussion genutzt
werden sollte und der Orginalbeitrag vielleicht sticky wird - mir
fällt grade leider kein deutscher Begriff daür ein - also unter Compiler
& IDE oben erhalten bleibt. Je mehr leute darüber stoßen um so besser.
M. H. schrieb:> Doch genau DAS machen die Linkerskripte von CubeMX und auch von anderen> Anbietern.
GNU LD aus den Binutils kann nicht vernünftig mit Gaps im RAM umgehen.
Wenn man so eine Konfiguraton z.B. im LPC1768 von NXP hat, wird das ein
Riesenaufwand mit vielen __attribute__((section())) im Source. BTDT.
Jim M. schrieb:> Wenn man so eine Konfiguraton z.B. im LPC1768 von NXP hat, wird das ein> Riesenaufwand mit vielen __attribute__((section())) im Source. BTDT.
Kommt darauf an, wie man das nutzt.
Mit tausenden 8-Bit-Variablen ist das natürlich unschön.
Nils N. schrieb:> Das sehe ich genauso wie du.Zusätzlich kommt man in Schwulitäten
Und da hätte man gedacht solche diskriminierenden Sprüche gehörten der
Vergangenheit an.
M. H. schrieb:> Ich möchte nur darauf aufmerksam machen, dass überall verwendete Tools> gravierende Fehler enthalten,
Das ist nicht der erste Fehler. Die alten Linker Scripte, noch bevor es
Cube überhaupt gab, haben teilweise _sidata falsch berechnet, sodass
Variablen teilweise falsch initialisiert wurden. Das war ein Spaß bei
der Fehlersuche!
Bis heute hat der Header für den STM32F37 ein Bit bei der SDADC
Peripherie falsch definiert.
Die Doku hat allgemein jede Menge Copy Paste Fehler. Silicon Bugs gibt's
natürlich auch.
Die STM32 sind weit weg von "perfekt" und "fehlerlos". Dennoch bieten
sie viel Leistung bei guten Preisen. Man kann sich damit arrangieren
oder was anderes nutzen...
viel krasser ist das bei dem F4 F7 h7
diese haben DTCM RAM , SRAM ( 2 blöcke ) und ITCM RAM
Das cube linkerfile geht einfach ab 0x20000000 los
aber im DTCM gehen keine buffer für DMA ...
im SRAM 2 nur bestimmte ...
und schräg sind dann die performanceunterschiede wenn daten vom DTCM mal
vom DTCM oder SRAM kommen ...
oder der STACK im SRAM liegt .. aber dann langsam ist.
im DTCM ist das schnell , liegt aber mittem im adressbereich ...
Thread beobachten
Seitenaufteilung abschalten