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.
Jim M. schrieb: > Normales gdb load mit dem .elf gdb zum Flashen ist overkill und komplizierter als nötig, openocd kann das alleine.
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
1 | #define VECT_TAB_OFFSET 0xABCD
|
geben.
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?
Also, eine Anwendung in der STM Workbench, am Anfang vom Linkerskript steht:
1 | MEMORY |
2 | {
|
3 | FLASH (rx) : ORIGIN = __begin_flash__, LENGTH = 64K - 8K |
4 | } |
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 |
47 | adapter speed: 950 kHz |
48 | shutdown command invoked |
S
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
>In deinem Linker-Script Ausschnitt gibt es auch >keinen RAM-Abschnitt. Der wurde entfernt weil es ja nur um da Flash geht: Das Ganze:
1 | MEMORY |
2 | {
|
3 | FLASH (rx) : ORIGIN = __begin_flash__, LENGTH = 64K - 8K |
4 | VTRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 0xc0 /* vector table */ |
5 | RAM (rwx) : ORIGIN = 0x200000c0, LENGTH = 8K - 0xc0 |
6 | } |
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
Wurde eine Lösung gefunden? Habe leider das gleiche Problem... VG Chris
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ängt Stefan 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"
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.