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
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang