Open OCD: Target Adresse im Flash

[Stefan S. (energizer)]

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

[pegel (Gast)]

http://openocd.org/doc/html/Flash-Programming.html

[Jim M. (turboj)]

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. (prof7bit)]

Jim M. schrieb:
> Normales gdb load mit dem .elf

gdb zum Flashen ist overkill und komplizierter als nötig, openocd kann 
das alleine.

[Jim M. (turboj)]

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.

[Bernd K. (prof7bit)]

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.

[Christopher J. (christopher_j23)]

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

#define VECT_TAB_OFFSET 0xABCD

 geben.

[Stefan S. (energizer)]

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

[Jim M. (turboj)]

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.

[Bernd K. (prof7bit)]

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?

[Stefan S. (energizer)]

Also,

eine Anwendung in der STM Workbench, am Anfang vom Linkerskript steht:

MEMORY
{
  FLASH (rx)  : ORIGIN = __begin_flash__, LENGTH = 64K - 8K
}

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.

Open On-Chip Debugger 0.10.0-dev-00275-gd486ac2-dirty (2017-03-06-15:22)
Licensed under GNU GPL v2
For bug reports, read
  http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
srst_only separate srst_nogate srst_open_drain connect_assert_srst
srst_only separate srst_nogate srst_open_drain connect_assert_srst
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.214173
Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
adapter speed: 950 kHz
stm32f0x.cpu: target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0xc1000000 pc: 0xfffffffe msp: 0xfffffffc
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
adapter speed: 4000 kHz
** Programming Started **
auto erase enabled
Info : device id = 0x20006440
Info : flash size = 64kbytes
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
verified 20760 bytes in 0.105167s (192.774 KiB/s)
** Verified OK **
** Resetting Target **
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
adapter speed: 950 kHz
shutdown command invoked

S

[Bernd K. (prof7bit)]

jetzt noch den Inhalt der "gdb traces" Konsole bitte.

[Christopher J. (christopher_j23)]

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?

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Christopher J. schrieb:

>

#define VECT_TAB_OFFSET 0xABCD

 geben.

Vorsicht VTOR muss alignt sein!

[Stefan S. (energizer)]

>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

[Stefan S. (energizer)]

>In deinem Linker-Script Ausschnitt gibt es auch
>keinen RAM-Abschnitt.

Der wurde entfernt weil es ja nur um da Flash geht:

Das Ganze:

MEMORY
{
  FLASH (rx)  : ORIGIN = __begin_flash__, LENGTH = 64K - 8K
  VTRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 0xc0  /* vector table */
  RAM (rwx)   : ORIGIN = 0x200000c0, LENGTH = 8K - 0xc0
}

[Nop (Gast)]

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.

[Christopher J. (christopher_j23)]

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.

[Stefan S. (energizer)]

>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

[Steffen R. (steffen_rose)]

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