Hallo,
ich benutze den OCD in der System Workbench for STM32. Die Firmware
startet ab einer Offsetadresse (Linkerscript), weil am Flashanfang noch
ein Bootloader sitzt. Wie kann ich dem OCD sagen dass das Komplilat an
eine andere Adresse geflasht werden soll?
S
Wenn Du nicht grade ein .bin benutzt steht der Offset schon korrekt drin
(hex, elf). Normales gdb load mit dem .elf müsste ohne weiteres
funktionieren und sollte den Bootloader nicht überschreiben.
Bernd K. schrieb:>> Normales gdb load mit dem .elf>> gdb zum Flashen ist overkill und komplizierter als nötig, openocd kann> das alleine.
Wenn man das korrekt aufsetzt kann man gleich im Anschluss auch
debuggen, und das direkt aus der IDE.
Und System Workbench müsste GDB unter der Haube ohnehin als Debugger
benutzen - basiert ja auf Eclipse.
Jim M. schrieb:> Wenn man das korrekt aufsetzt kann man gleich im Anschluss auch> debuggen, und das direkt aus der IDE.
Das das Debuggen in der IDE korrekt aufgesetzt ist, davon ging ich
stillschweigend aus. Er fragte explizit nach dem Flashen, also nahm
ich an er will wissen wie man ein standalone Flash-only-Tool aufsetzt.
S. S. schrieb:> Die Firmware startet ab einer Offsetadresse (Linkerscript), weil am> Flashanfang noch ein Bootloader sitzt.
Falls nicht sowieso schon getan, nicht vergessen noch den Offset für den
NVIC einzurichten. Da sollte es in der system_stm32fxxx.c irgendwo ein
Also eben nochmal probiert; es wird definitiv ab 0x8000000 geschrieben,
obwohl das Programm erst ab 0x8002000 anfängt. Jetzt frage ich mich wo
ich das in der System Workbench denn einstellen kann.
S
S. S. schrieb:> Also eben nochmal probiert; es wird definitiv ab 0x8000000 geschrieben,> obwohl das Programm erst ab 0x8002000 anfängt. Jetzt frage ich mich wo> ich das in der System Workbench denn einstellen kann.
Stichwort: Linker Skript.
S. S. schrieb:> Also eben nochmal probiert; es wird definitiv ab 0x8000000 geschrieben
Was genau hast Du probiert?
Gib doch bitte ausführliche (vollständige) Informationen was genau Du
da tust und wie Du es tust und die vollständigen Konsolen- (oder
anderweitige) Ausgaben anhand derer Du versuchst zu erkennen ob und was
geklappt hat oder nicht. Wie sonst soll man als Unbeteiligter
herausfinden an welcher Stelle genau Du den entscheidenden Fehler
begehst?
Das Linkersymbol:
--defsym=__begin_flash__=0x08002000
Die erzeugte .hex Datei fängt ordnungsgemäß bei 0x08002000 an. Soweit so
gut, mit dem ST-Link flashen und alles passt.
Dann den µC nochmal leeren, und in der Workbench "Run" aufrufen, die
Firmware wird geflasht, landet hier aber bei 0x08000000.
1
Open On-Chip Debugger 0.10.0-dev-00275-gd486ac2-dirty (2017-03-06-15:22)
2
Licensed under GNU GPL v2
3
For bug reports, read
4
http://openocd.org/doc/doxygen/bugs.html
5
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
6
adapter speed: 1000 kHz
7
adapter_nsrst_delay: 100
8
srst_only separate srst_nogate srst_open_drain connect_assert_srst
9
srst_only separate srst_nogate srst_open_drain connect_assert_srst
10
Info : Unable to match requested speed 1000 kHz, using 950 kHz
11
Info : Unable to match requested speed 1000 kHz, using 950 kHz
12
Info : clock speed 950 kHz
13
Info : STLINK v2 JTAG v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
14
Info : using stlink api v2
15
Info : Target voltage: 3.214173
16
Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints
17
Info : Unable to match requested speed 1000 kHz, using 950 kHz
18
Info : Unable to match requested speed 1000 kHz, using 950 kHz
19
adapter speed: 950 kHz
20
stm32f0x.cpu: target state: halted
21
target halted due to debug-request, current mode: Thread
22
xPSR: 0xc1000000 pc: 0xfffffffe msp: 0xfffffffc
23
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
24
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
25
adapter speed: 4000 kHz
26
** Programming Started **
27
auto erase enabled
28
Info : device id = 0x20006440
29
Info : flash size = 64kbytes
30
stm32f0x.cpu: target state: halted
31
target halted due to breakpoint, current mode: Thread
32
xPSR: 0x61000000 pc: 0x2000003a msp: 0xfffffffc
33
wrote 21504 bytes from file Debug/SCU.elf in 1.137793s (18.457 KiB/s)
34
** Programming Finished **
35
** Verify Started **
36
stm32f0x.cpu: target state: halted
37
target halted due to breakpoint, current mode: Thread
38
xPSR: 0x61000000 pc: 0x2000002e msp: 0xfffffffc
39
stm32f0x.cpu: target state: halted
40
target halted due to breakpoint, current mode: Thread
41
xPSR: 0x61000000 pc: 0x2000002e msp: 0xfffffffc
42
verified 20760 bytes in 0.105167s (192.774 KiB/s)
43
** Verified OK **
44
** Resetting Target **
45
Info : Unable to match requested speed 1000 kHz, using 950 kHz
46
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Wie genau sieht denn der OpenOCD Aufruf aus?
S. S. schrieb:> stm32f0x.cpu: target state: halted> target halted due to breakpoint, current mode: Thread> xPSR: 0x61000000 pc: 0x2000003a msp: 0xfffffffc> wrote 21504 bytes from file Debug/SCU.elf in 1.137793s (18.457 KiB/s)> ** Programming Finished **> ** Verify Started **> stm32f0x.cpu: target state: halted> target halted due to breakpoint, current mode: Thread> xPSR: 0x61000000 pc: 0x2000002e msp: 0xfffffffc> stm32f0x.cpu: target state: halted> target halted due to breakpoint, current mode: Thread> xPSR: 0x61000000 pc: 0x2000002e msp: 0xfffffffc
Der PC zeigt ins RAM und der MSP zeigt ins Nirvana, das finde ich
irgendwie merkwürdig. In deinem Linker-Script Ausschnitt gibt es auch
keinen RAM-Abschnitt.
S. S. schrieb:> Firmware wird geflasht, landet hier aber bei 0x08000000
Wie hast du das denn festgestellt?
>Wie hast du das denn festgestellt?
Man schaut z.B. mit dem STM32 Link nach wo die Daten liegen
>#define VECT_TAB_OFFSET 0xABCD
Sollte damit nichts zu tun haben, die erzeugte HEX Datei geht auch erst
ab 0x08002000 los?
S
S. S. schrieb:>>Wie hast du das denn festgestellt?>> Man schaut z.B. mit dem STM32 Link nach wo die Daten liegen>>>#define VECT_TAB_OFFSET 0xABCD>> Sollte damit nichts zu tun haben, die erzeugte HEX Datei geht auch erst> ab 0x08002000 los?
Die entscheidende Frage aus dem Posting, die Du beantworten solltest,
damit man weiterkommt, hast Du allerdings ignoriert.
S. S. schrieb:>> #define VECT_TAB_OFFSET 0xABCD>> Sollte damit nichts zu tun haben, die erzeugte HEX Datei geht auch erst> ab 0x08002000 los?
Hat nichts damit zu tun wo dein Programm im Flash landet aber hat, wenn
es an der gewünschten Stelle landet, damit zu tun ob es funktioniert wie
es soll. Wie Uwe richtig bemerkt hat kommt es auch noch auf das
Alignment an.
Nop schrieb:> Die entscheidende Frage aus dem Posting, die Du beantworten solltest,> damit man weiterkommt, hast Du allerdings ignoriert.Christopher J. schrieb:> Wie genau sieht denn der OpenOCD Aufruf aus?Bernd K. schrieb:> jetzt noch den Inhalt der "gdb traces" Konsole bitte.
>Wie genau sieht denn der OpenOCD Aufruf aus?
Wie komme ich denn an selbigen in der STM Workbench?
>jetzt noch den Inhalt der "gdb traces" Konsole bitte.
Ich kann nur "Trace Control" finden, da taucht jedoch nichts auf.
>Hat nichts damit zu tun wo dein Programm im Flash landet aber hat, wenn>es an der gewünschten Stelle landet, damit zu tun ob es funktioniert wie>es soll
Wenn ich extern mit dem STM32 Link Utility flashe klappt alles
wunderbar, d. h. der Teil ist in Ordnung
Christopher J. schrieb:> S. S. schrieb:>>> #define VECT_TAB_OFFSET 0xABCD>>>> Sollte damit nichts zu tun haben, die erzeugte HEX Datei geht auch erst>> ab 0x08002000 los?>> Hat nichts damit zu tun wo dein Programm im Flash landet aber hat, wenn> es an der gewünschten Stelle landet, damit zu tun ob es funktioniert wie> es soll. Wie Uwe richtig bemerkt hat kommt es auch noch auf das> Alignment an.
Das es hier um einen Cortex-M0 geht, funktioniert das mit der
Vektortabelle eh' anders. Aber das ist nicht das angesprochene Problem
des TO.
>> Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints
Christian T. schrieb:> Habe leider das gleiche Problem...
Das halte ich für ein Gerücht, da der TO sein Problem ja selbst nicht
wirklich eingrenzen konnte.
Wenn man mit Booloadern arbeitet, sollte man in etwa wissen, was ab dem
ersten Takt in einem Cortex-M passiert. Das hört sich auch jetzt
wirklich viel komplizierter an als es tatsächlich ist, also nur Mut. Der
Joseph Yiu ist in diesem Fall dein bester Freund.
Mit Angaben wie "gleiches Problem" kann kein Mensch etwas anfangen, vor
allem weil es zu 99,9% nicht das gleiche Problem ist, sondern eben ein
anderes (andere Software-Versionen, etc.). Mach am besten einen neuen
Thread auf.
Christopher J. schrieb:> Das halte ich für ein Gerücht, da der TO sein Problem ja selbst nicht> wirklich eingrenzen konnte.
Er beschreibt das Problem doch eigentlich ganz gut:
Stefan S. schrieb:> Die Firmware> startet ab einer Offsetadresse (Linkerscript), weil am Flashanfang noch> ein Bootloader sitzt. Wie kann ich dem OCD sagen dass das Komplilat an> eine andere Adresse geflasht werden soll?Stefan S. schrieb:> es wird definitiv ab 0x8000000 geschrieben,> obwohl das Programm erst ab 0x8002000 anfängtStefan S. schrieb:> Die erzeugte .hex Datei fängt ordnungsgemäß bei 0x08002000 an. Soweit so> gut, mit dem ST-Link flashen und alles passt.>> Dann den µC nochmal leeren, und in der Workbench "Run" aufrufen, die> Firmware wird geflasht, landet hier aber bei 0x08000000.Christopher J. schrieb:> Wenn man mit Booloadern arbeitet, sollte man in etwa wissen, was ab dem> ersten Takt in einem Cortex-M passiert. Das hört sich auch jetzt> wirklich viel komplizierter an als es tatsächlich ist, also nur Mut. Der> Joseph Yiu ist in diesem Fall dein bester Freund.
Wenn ich die .hex des Bootloaders (mit Flash Erase) und anschließend die
des eigentlichen Programms (ohne Flash Erase) per ST-Link-Utility flashe
funktioniert alles. Ein Problem mit dem eigentlichen Programm besteht
also nicht. Das Problem liegt hier im flashen mit OpenOCD, welcher immer
an die Adresse des ersten Sektors flasht, obwohl in der .ld und .map der
Adressbereich des dritten Sektors vermerkt ist.
Christopher J. schrieb:> Mach am besten einen neuen> Thread auf.
Ich hatte die Hoffnung, dass der Thread-Ersteller vielleicht eine Lösung
gefunden hat...
VG Chris
Christian T. schrieb:> Das Problem liegt hier im flashen mit OpenOCD, welcher immer an die> Adresse des ersten Sektors flasht, obwohl in der .ld und .map der> Adressbereich des dritten Sektors vermerkt ist.
Vermutlich liegt das Problem eher im Aufruf von OpenOCD durch die
"System Workbench" und nicht in OpenOCD an sich. Andererseits ist ohne
den genauen Aufruf (den ja der TO schon vermissen ließ) alles nur
Mutmaßung. Nichts genaues weiß man nicht.
Christian T. schrieb:> Ich hatte die Hoffnung, dass der Thread-Ersteller vielleicht eine Lösung> gefunden hat...
Der ist über alle Berge, der Thread ist fünf Jahre alt. Nicht jeder
trackt alle seine Threads hier, in denen er jemals was geschrieben hat.
Wenn er das nicht macht, ist deine Chance, dass er nun drauf reagiert,
nahe null.
Mach einen neuen Thread auf und beschreibe möglichst genau dein Problem.
Am besten mit Beispieldateien (kann ja ein runter gestricktes
Minimalbeispiel sein) und den tatsächlich verwendeten Kommandozeilen.
Jörg W. schrieb:> Mach einen neuen Thread auf und beschreibe möglichst genau dein Problem.> Am besten mit Beispieldateien (kann ja ein runter gestricktes> Minimalbeispiel sein) und den tatsächlich verwendeten Kommandozeilen.
Habe ich gemacht, ist zu finden unter
Beitrag "OpenOCD STM32F4 Flash Adresse"
