Forum: Mikrocontroller und Digitale Elektronik Open OCD: Target Adresse im Flash


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Stefan S. (energizer)


Bewertung
0 lesenswert
nicht lesenswert
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

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Jim M. schrieb:
> Normales gdb load mit dem .elf

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

von Jim M. (turboj)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan S. (energizer)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Stefan S. (energizer)


Bewertung
0 lesenswert
nicht lesenswert
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

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
jetzt noch den Inhalt der "gdb traces" Konsole bitte.

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:

>
1
#define VECT_TAB_OFFSET 0xABCD
 geben.

Vorsicht VTOR muss alignt sein!

von Stefan S. (energizer)


Bewertung
0 lesenswert
nicht lesenswert
>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

von Stefan S. (energizer)


Bewertung
0 lesenswert
nicht lesenswert
>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
}

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan S. (energizer)


Bewertung
0 lesenswert
nicht lesenswert
>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

von Steffen R. (steffen_rose)


Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

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

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.