Habe im Moment das Problem, daß ich ein STM32F407G-DISC1 (Discovery)
Board mit einem .BIN und dem STM32 ST-LINK Utility uter Windows 8.1
geflasht habe.
Jetzt wollte ich unter gdb/openOCD ein anders kleines Programm
hineinladen,
aber es passiert nichts. Ich krieg den Code nicht überschrieben.
Mein openOCD-Aufruf:
manchmal kann ich einen Satz nicht
Um wieder zum Ernst des Lebens zurückzukehren: also, ich sehe es daran,
daß beim Untersuchen des Speichers bei 0x00000000 nichts verändert wird,
also nicht der Reset Einsprung meine kleinen Miniprogramms
einprogrammiert wird und auch ansonsten keine Anzeichen zu sehen sind,
daß irgendetwas mit dem Board passiert.
Wird doch wohl nicht daran liegen, daß ich unter dem ST32 ST-LINK
Utility einen Firmware Upgrade gemacht habe?
Hier ist noch mal die Ausgabe von gdb:
1
$ ./GDB
2
GNU gdb (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.50.20181213-git
3
Copyright (C) 2018 Free Software Foundation, Inc.
4
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
5
This is free software: you are free to change and redistribute it.
6
There is NO WARRANTY, to the extent permitted by law.
7
Type "show copying" and "show warranty" for details.
8
This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
9
Type "show configuration" for configuration details.
10
For bug reporting instructions, please see:
11
<http://www.gnu.org/software/gdb/bugs/>.
12
Find the GDB manual and other documentation resources online at:
13
<http://www.gnu.org/software/gdb/documentation/>.
14
15
For help, type "help".
16
Type "apropos word" to search for commands related to "word".
17
Reset () at simple.s:11
18
11 nop @ Do Nothing
19
Loading section .text, size 0xf0 lma 0x8000
20
Start address 0x80ec, load size 240
21
Transfer rate: 1920 bits in <1 sec, 240 bytes/write.
Das Flash (da soll's doch hingehen, nicht ins RAM?) liegt ab 0x08000000.
Und der Flash Handler (schreckliches Wort ...) der STM32er in OpenOCD
fühlt sich für alles außerhalb dieses Bereiches unzuständig (abgesehen
von OTP etc.).
Ob der Flash zusätzlich noch irgendwo gespiegelt wird, spielt dabei
keine Rolle.
Und wenn's ins RAM gehen soll, dann ab 0x20000000, nicht ab 0x0.
Was dort liegt (gespiegelt!) hängt von der Konfiguration ab und ist
daher sozusagen unvorhersehbar bzw. reichlich "dynamisch". Dahin lädt
man also tunlichst --- nichts.
Ah, danke. Verstehe. Jetzt sieht's auch schon anders aus, nachdem ich
die loader map angepaßt habe. Da stand Unsinn drin.
Zum Stack: ich kann den doch mit 0x4000000 initialisieren?
Wird ja dann bei der ersten Benutzung pre-dekrementiert und ich lande im
SRAM.
Gibt's eigentlich in der Cortex-Architektur einen Double Bus Fault? Bei
der PDP-11 gab es früher den "Double Bus Fault" - einen Addresserror
(Zugriff auf nicht existierende Adresse) während einer Trap
(Exceptionverarbeitung).
Grüße
Christoph
Christoph K. schrieb:> Gibt's eigentlich in der Cortex-Architektur einen Double Bus Fault?
Double fault gibt's, ja.
Aber exception handler hast du ja sowieso keine installiert. :-)
ps: Normalerweise sollte man zumindest einen HardFault_Handler
installieren. Die diversen anderen Faults müsste man explizit freigeben;
wenn man das nicht konfiguriert hat, fallen am Ende alle auf einen
HardFault zurück.
Jörg W. schrieb:> Christoph K. schrieb:>> Gibt's eigentlich in der Cortex-Architektur einen Double Bus Fault?>> Double fault gibt's, ja.>> Aber exception handler hast du ja sowieso keine installiert. :-)>
Noch nicht:)
> ps: Normalerweise sollte man zumindest einen HardFault_Handler> installieren. Die diversen anderen Faults müsste man explizit freigeben;> wenn man das nicht konfiguriert hat, fallen am Ende alle auf einen> HardFault zurück.
Ja, kommt dann auch. Übrigens meinte ich Stackpointer, nicht Stack
initialisieren.
Christoph K. schrieb:> Übrigens meinte ich Stackpointer, nicht Stack initialisieren.
Schon klar, aber deine 0x4000000 sind nicht korrekt. Du kannst ihn auf
0x20000000 + RAM-Größe initialisieren. (Bin gerade zu faul, die
RAM-Größe des STM32F407 nachzusehen.)
Jörg W. schrieb:
...
> Schon klar, aber deine 0x4000000 sind nicht korrekt. Du kannst ihn auf> 0x20000000 + RAM-Größe initialisieren. (Bin gerade zu faul, die> RAM-Größe des STM32F407 nachzusehen.)
Ach so, klar.
Jörg W. schrieb:> Schon klar, aber deine 0x4000000 sind nicht korrekt. Du kannst ihn auf> 0x20000000 + RAM-Größe initialisieren.
Das ist zum Ausprobieren OK, aber ansonsten legt man den Stack besser
mit einer definierten Größe gegen den Anfang des RAMs, damit ein Stack
Overflow direkt in einen Hardfault rennt. Die Demo-Linkerscripte von ST
sind nicht für production code gedacht.
Nop schrieb:> Jörg W. schrieb:>>> Schon klar, aber deine 0x4000000 sind nicht korrekt. Du kannst ihn auf>> 0x20000000 + RAM-Größe initialisieren.>> Das ist zum Ausprobieren OK, aber ansonsten legt man den Stack besser> mit einer definierten Größe gegen den Anfang des RAMs, damit ein Stack> Overflow direkt in einen Hardfault rennt. Die Demo-Linkerscripte von ST> sind nicht für production code gedacht.
Stack an Anfang des Rams wegen Hardfault: auch gute Idee. Werde ich mir
mal merken.
Nop schrieb:> aber ansonsten legt man den Stack besser mit einer definierten Größe> gegen den Anfang des RAMs
Naja, es gibt nicht das Universalrezept.
Das mit dem Stack an den Anfang ist ein möglicher Trick, Stack ans Ende
(und von unten gegenläufiger Heap) ist eine andere Variante. Beide haben
Vor- und Nachteile, die man gegeneinander abwägen sollte.
... was anderes gilt nur dann, wenn man einen Controller hat, bei dem
(anders als beim hier vorhandenen Cortex-M) ein Zugriff "unterhalb" des
RAMs keinen sauberen Fault auslöst, z.B. weil dort die Register liegen.
Nop schrieb:> Hat den "Vorteil"
Ich weiß nicht, was deine Ironie soll.
Selbstverständlich ist das der Nachteil des Konzepts. Der Vorteil ist
die flexible Speichernutzung. Wenn man den Stack an den Anfang legt,
dann muss man sich völlig sicher sein, wie groß er maximal werden kann:
hat man ihn zu klein veranschlagt, stürzt der Kram ab, obwohl eigentlich
noch Speicher verfügbar wäre (wurde halt nur nicht dem Stack
zugeschlagen). Hat man ihn zu groß veranschlagt, ist der dafür beiseite
gelegte RAM dauerhaft für andere Anwendungen verloren.
Was man im konkreten Fall will, muss man daher selbst entscheiden:
100%ige Sicherheit zum entsprechenden Preis einschließlich einer
vorangegangenen worst-case-Recherche (die bei einem komplexeren Programm
recht aufwändig sein kann), oder maximale Flexibilität auf Kosten der
Sicherheit.
Für ein Fahrzeug wird die Antwort auf diese Frage sicher anders aussehen
als für ein Musikinstrument.
Jörg W. schrieb:> Wenn man den Stack an den Anfang legt,> dann muss man sich völlig sicher sein, wie groß er maximal werden kann:
Das muß man ohnehin, weil das Produkt sonst nicht zuverlässig
funktioniert.
> hat man ihn zu klein veranschlagt, stürzt der Kram ab, obwohl eigentlich> noch Speicher verfügbar wäre
Das ist der Witz daran und deswegen ein Vorteil, kein Nachteil. Man
bemerkt nämlich, daß es überhaupt ein Problem gibt, und zwar dann, wenn
es erstmals entsteht.
> Für ein Fahrzeug wird die Antwort auf diese Frage sicher anders aussehen> als für ein Musikinstrument.
Mit anderen Worten: bei Musikinstrumenten ist es schon OK, wenn der Kram
beim Kunden abstürzt, gerne auch mitten in einem Live-Konzert. Was ist
der Kunde auch so blöd und kauft das Produkt. Tja, vielleicht ist er
dann aber immerhin schlau genug, bei dem Hersteller nicht nochmal zu
kaufen.
Nop schrieb:> Man bemerkt nämlich, daß es überhaupt ein Problem gibt, und zwar dann,> wenn es erstmals entsteht.
Auch das kann allerdings erst beim Kunden sein …
Aber lass die Diskussion mal hier enden. Die ist philosophisch, und wird
Chris nur sehr bedingt weiter helfen. Er macht da gerade seine ersten
Schritte, und ich bezweifle stark, dass er irgendwas entwickelt, was
mehr als zu seiner eigenen Erbauung gut ist. (Ich kenne ihn nun schon
ein paar Jahrzehnte und kann mir ungefähr vorstellen, was er so treibt.
;-)
Jörg W. schrieb:> Nop schrieb:>> Man bemerkt nämlich, daß es überhaupt ein Problem gibt, und zwar dann,>> wenn es erstmals entsteht.>> Auch das kann allerdings erst beim Kunden sein …>> Aber lass die Diskussion mal hier enden. Die ist philosophisch, und wird> Chris nur sehr bedingt weiter helfen. Er macht da gerade seine ersten> Schritte, und ich bezweifle stark, dass er irgendwas entwickelt, was> mehr als zu seiner eigenen Erbauung gut ist. (Ich kenne ihn nun schon> ein paar Jahrzehnte und kann mir ungefähr vorstellen, was er so treibt.> ;-)
Danke, Jörg, für die milden Worte. Hier weht ja sonst ein rauher Wind.
;-)
Grüße
Christoph
Thread beobachten
Seitenaufteilung abschalten