Forum: Mikrocontroller und Digitale Elektronik SRAM Lücke STM32Fxxx, Linkerskripte falsch


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von M. Н. (Gast)


Angehängte Dateien:

Lesenswert?

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

von Curby23523 N. (Gast)


Lesenswert?

Wieder ein Vorteil, wenn man auf HAL/CubeMX etc. verzichtet.

von M. Н. (Gast)


Lesenswert?

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...

von Curby23523 N. (Gast)


Lesenswert?

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.

von Doctor What (Gast)


Lesenswert?

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.

von Florian O (Gast)


Lesenswert?

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.

von Jim M. (turboj)


Lesenswert?

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.

von Doctor What (Gast)


Lesenswert?

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.

von Dr. Sommer (Gast)


Lesenswert?

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...

von 43222342 (Gast)


Lesenswert?

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 ...

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.