www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik OpenOCD Wiggler STM32-P103 flashen


Autor: Johann Knechtel (jo-hann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Als Einsteiger bin ich inzwischen soweit gekommen, mir die Toolchain von 
CodeSourcery einzubinden und die Beispielprojekte von Olimex mal zu 
kompilieren. Das Verbinden per OpenOCD funktioniert auch soweit, aber am 
Flashen scheitert es nun und ich komme nicht so recht weiter, andere 
Beiträge haben leider auch nicht geholfen....

Anbei mein cfg fürs Flashen, die Fehlermeldung ist folgende:
Info:    options.c:50 configuration_output_handler():   #127: 0x0001fc00 (0x400 1kB) not protected
Info:    options.c:50 configuration_output_handler(): stm32x flash driver info
Error:   flash.c:890 get_flash_bank_by_addr(): No flash at address 0x00000000

Info:    options.c:50 configuration_output_handler(): wrote 0 byte from file main.bin in 0.000074s (0.000000 kb/s)
Info:    jtag.c:1389 jtag_examine_chain(): JTAG device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0xba00, Version: 0x3)
Info:    jtag.c:1389 jtag_examine_chain(): JTAG device found: 0x16410041 (Manufacturer: 0x020, Part: 0x6410, Version: 0x1)
#daemon configuration
telnet_port 4444
gdb_port 3333

#interface
interface parport
parport_port 0x378
parport_cable wiggler
jtag_speed 10

reset_config srst_only

#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe
jtag_device 5 0x1 0x1 0x1e

#target configuration
daemon_startup reset

#target <type> <startup mode>
#target cortex_m3 <endianness> <reset mode> <chainpos> <variant>
#target cortex_m3 little run_and_halt 0
target cortex_m3 little run_and_init 0
#run_and_halt_time 0 30

#flash bank <driver> <base> <size> <chip_width> <bus_width>
flash bank stm32x 0x08000000 0x00010000 0 0 0
flash auto_erase on

# 4k working area at base of ram
#working_area 0 0x20000800 0x1200 nobackup
# all ram
working_area 0 0x20000000 0x2000 nobackup

# script running on reset
target_script 0 reset lmi.script

lmi.script:
flash probe 0
flash erase_check 0
flash protect_check 0
flash info 0

flash write_image main.bin 0 bin

sleep 200

reset run
shutdown

Wenn ich dann intuitiv die Datei lmi.script anpasse, sodass write_image 
mit dem Offset 0x08000000 arbeitet wird folgendes ausgegeben:
Warning: target.c:853 target_alloc_working_area(): not enough working area available(requested 8192, free 8144)
Error:   stm32x.c:556 stm32x_write(): flash writing failed with error code: 0xfffffc7a
Error:   flash.c:103 flash_driver_write(): error writing to flash at address 0x08000000 at offset 0x00000000 (-902)


Ich bin für jeden Hinweise dankbar....

Grüße
Johann

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OpenOCD CFG Datei:
#daemon configuration
telnet_port 4444
gdb_port 3333

# tell gdb our flash memory map
# and enable flash programming
#gdb_memory_map enable
gdb_flash_program enable

#interface
interface ft2232
ft2232_device_desc "Olimex OpenOCD JTAG A"
ft2232_layout "olimex-jtag"
ft2232_vid_pid 0x15BA 0x0003
jtag_speed 10
jtag_nsrst_delay 100
jtag_ntrst_delay 100

#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config trst_and_srst

#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe
jtag_device 5 0x1 0x1 0x1e

daemon_startup reset
#run_and_halt_time 0 30

#target configuration
target cortex_m3 little reset_halt 0
#target cortex_m3 little run_and_halt 0

working_area 0 0x20000000 0x5000 nobackup

#flash configuration
#target_script 0 reset openocd_lpc2368_flash.script
#flash bank lpc2000 <base> <size> 0 0 0 <target#> <variant>
flash bank stm32x 0x08000000 0x20000 0 0 0

GDB Kommandos:
set complaints 1
set output-radix 16
set input-radix 16
set prompt (arm-gdb)
target remote localhost:3333
set remote memory-write-packet-size 1024
set remote memory-write-packet-size fixed
set remote memory-read-packet-size 1024
set remote memory-read-packet-size fixed
set remote hardware-watchpoint-limit 6
set remote hardware-breakpoint-limit 6
monitor reset
monitor sleep 200
monitor poll
monitor soft_reset_halt
monitor stm32x unlock 0
monitor stm32x mass_erase 0
monitor flash write_image main.elf 0x08000000 elf
monitor reset
monitor poll
break main
continue

Immer wenn ich debugge wird das Flash automatisch geschrieben. Das geht 
auch direkt über OpenOCD, das sind die "monitor" Befehle, die tut der 
GDB direkt OpenOCD weiterleiten.

Ich nutze OpenOCD Version r-247. Siehe:
Beitrag "Re: OpenOCD mit AT91SAM7X-EK und Wiggler aus einem Batch oder aus Eclipse"

Autor: Johann Knechtel (jo-hann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erstmal besten Dank für den Hinweis, ich werde es mal mit dem GDB 
versuchen zu flashen. Dafür brauche ich aber offensichtlich erstmal ein 
gelinktes ELF. Um das zu erstellen habe ich mein Makefile entsprechend 
des Templates von Martin Thomas angepasst, komme damit jetzt aber nicht 
weiter. Direkt das Template wollte ich nicht unbedingt nehmen, da ich da 
wenig Lerneffekt habe und ich mir auch nicht sicher bin, ob es 
entsprechend für den STM32 anpassbar ist...

Meine Versuche haben bisher zu dieser Fehlermeldung geführt:
.linking ram elf
arm-none-linux-gnueabi-gcc -I./ -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb  main.o stm32f10x_rcc.o stm32f10x_gpio.o --output main.elf -T ram.cmd -nostartfiles -Wl,-Map=main.map,--cref
arm-none-linux-gnueabi-gcc: main.o: linker input file unused because linking not done

Mein makefile:
NAME   = stm_p103

CC      = arm-none-linux-gnueabi-gcc
LD      = arm-none-linux-gnueabi-ld -v
AR      = arm-none-linux-gnueabi-ar
AS      = arm-none-linux-gnueabi-as
CP      = arm-none-linux-gnueabi-objcopy
OD  = arm-none-linux-gnueabi-objdump
  
CFLAGS  =  -I./ -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb 
AFLAGS  = -ahls -mapcs-32 -o crt.o
LFLAGS  = -T $(LINK).cmd -nostartfiles
LELFFLAGS = $(LFLAGS) -Wl,-Map=main.map,--cref
CPFLAGS = -O binary
ODFLAGS  = -S

all: rom
rom: compile link copy
LINK = rom
ram: compile link copy
LINK = ram

compile: main.o stm32f10x_rcc.o stm32f10x_gpio.o

clean:
  -rm main.lst main.o main.out main.hex main.map stm32f10x_rcc.o stm32f10x_gpio.o

copy:
  @ echo "...copying"
  $(CP) $(CPFLAGS) main.out main.bin
  $(OD) $(ODFLAGS) main.out > main.lst

link: main.elf
  @ echo "..linking $(LINK) bin"
  $(LD) $(LFLAGS) -o main.out  main.o stm32f10x_rcc.o stm32f10x_gpio.o 

main.elf:
  @ echo ".linking $(LINK) elf"
  $(CC) $(CFLAGS) main.o stm32f10x_rcc.o stm32f10x_gpio.o --output main.elf $(LELFFLAGS)

stm32f10x_rcc.o: stm32f10x_rcc.c 
  @ echo ".compiling"
  $(CC) $(CFLAGS) stm32f10x_rcc.c 
   
stm32f10x_gpio.o: stm32f10x_gpio.c
  @ echo ".compiling"
  $(CC) $(CFLAGS) stm32f10x_gpio.c 

main.o: main.c
  @ echo ".compiling"
  $(CC) $(CFLAGS) main.c

Ich bin natürlich auch für jeglich weitere Hinweise bzgl. des makefiles 
offen, da das auch noch Neuland für mich ist...

Grüße
Johann

Autor: Johann Knechtel (jo-hann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe eben noch eine gute Vorlage für ein makefile gefunden, von 
mmvisual unter Beitrag "Re: Debuggen von LPC2368 mit Eclipse und OpenOCD?".

Das habe ich mir nur etwas angepasst, siehe hier:
< TRGT = arm-none-linux-gnueabi-
---
> TRGT = arm-elf-
22c22
< AS   = $(TRGT)as
---
> AS   = $(TRGT)gcc -x assembler-with-cpp
26,27c26,29
< MCU  = cortex-m3
< THUMB    = -mthumb
---
> MCU  = arm7tdmi-s
> #SUBMDL = LPC2368
> #THUMB    = -mthumb
> THUMB_IW = -mthumb-interwork
55,57c57,58
< # Define linker script file here
< #TODO
< LDSCRIPT= ram.cmd
---
> # Define linker script file here
> LDSCRIPT= ./prj/lpc2368.ld
66c67
< SRC  = main.c stm32f10x_rcc.c stm32f10x_gpio.c
---
> SRC  = ./src/main.c ./src/target.c ./src/irq.c
69c70
< ASRC =
---
> ASRC = ./src/boot.s
72c73
< UINCDIR = ./
---
> UINCDIR = ./inc
96,97c97,98
< ASFLAGS = $(MCFLAGS) -g -gdwarf-2 $(THUMB) $(THUMB_IW) -Wa,-amhls=$(<:.s=.lst) $(ADEFS)
< #ASFLAGS = $(MCFLAGS) -g -gdwarf-2 -Wa,-amhls=$(<:.s=.lst) $(ADEFS)
---
> #ASFLAGS = $(MCFLAGS) -g -gdwarf-2 $(THUMB) $(THUMB_IW) -Wa,-amhls=$(<:.s=.lst) $(ADEFS)
> ASFLAGS = $(MCFLAGS) -g -gdwarf-2 -Wa,-amhls=$(<:.s=.lst) $(ADEFS)


Was hat es mit dem gdwarf2 auf sich? Hab irgendwie gelesen dass das ein 
Fileformat für AVR-GCC ist? Ist das dann hier relevant?
Ist das direkte verwenden von as (aus der CodeSourcery Toolchain) 
anstelle dem gcc mit assembler Parameter günstig?

Achja, und jetzt zum Flashen mit GDB: Prinzipiell hat es erstmal 
funktioniert :)
Aber: die Definition der memory-packet-size wurde bemerket, dass das 
Gerät das eventuell nicht unterstützen würde und ob man die Größe ändern 
möchte. Da habe ich dieses Befehle dann einfach weggelassen. Beim 
schreiben habe ich den offset auf 0 gesetzt, da das imho bereits in dem 
Linkerscript enthalten ist:

MEMORY
{
  ram (rwx) : ORIGIN = 0x20000000, LENGTH = 20K
  rom (rx) : ORIGIN = 0x00000000, LENGTH = 128K
}
SECTIONS
  {
  .  = 0x0;          /* From 0x00000000 */
    .text : {
    *(vectors)      /* Vector table */
    *(.text)        /* Program code */
    *(.rodata)      /* Read only data */
    } >ram
    .  = 0x20000000;   /* From 0x20000000 */      
    .data : {
    *(.data)        /* Data memory */
    } >ram
    .cs3.rom :
  {
    __cs3_region_start_rom = .;
    *(.cs3.region-head.rom)
    *(.rom)
    . = ALIGN (8);
  } >rom
  .cs3.rom.bss :
  {
    *(.rom.b)
    . = ALIGN (8);
  } >rom
  .bss : {
    *(.bss)         /* Zero-filled run time allocate data memory */
    } >ram
 }  
/*========== end of file ==========*/

Und der unschönste Fehler: ich kann nicht nochmal flashen, bzw. 
zugreifen zum debuggen:
Remote debugging using localhost:3333
Cannot access memory at address 0xb2ab6a3e

Openocd gibt offensichtlich einen Fehler bzgl. Zugriff aus:
Error:   cortex_swjdp.c:222 swjdp_transaction_endcheck(): SWJ-DP STICKY ERROR
Error:   cortex_swjdp.c:236 swjdp_transaction_endcheck(): dcb_dhcsr 0x30003, nvic_shcsr 0x20000, nvic_cfsr 0x0, nvic_bfar 0xe000edf8
Error:   gdb_server.c:1024 gdb_error(): unexpected error -107

Also bin ich einen Schritt weiter, aber wieder ausgebremst ;)

Viele Grüße
Johann

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Prinzipiell kann der OpenOCD auch ein bin oder hex file flashen, siehe 
Doku von OpenOCD.

Was es mit dem -gdwarf-2 auf sich hat steht in der Doku von 
www.gnuarm.org >> Support.

Ich denke mit dieser Doku studieren ist der Lerneffekt am größten, und 
die Doku lügt nicht.

Autor: Johann Knechtel (jo-hann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok da werde ich dort mal demnächst reinschauen wegen diese Punkten.
Und hättest du noch event. Hinweise für mich wegen dem Problem mit "set 
remote memory-write-packet-size 1024" und "set remote 
memory-read-packet-size 1024"?
Aber was noch ärgerlicher ist: Wieso kann ich nicht mehr flashen? Der 
Zugriff ist doch jetzt auf einen völlig unsinnigen Bereich (Cannot 
access memory at address 0xb2ab6a3e) obwohl ich sonst nichts weiter 
geändert habe?

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die OpenOCD Kommandos (wie auch das Flashen) können direkt über Telnet 
(Hyperterminal mit Port 4444) eingegeben werden, dann können Sie auch 
ohne GDB flashen und der GDB spuck nicht mit irgend welchen fragwürdigen 
Befehlen rein.
Bzw. dann wissen Sie ob es der OpenOCD oder der GDB ist.
Der "set remote memory..." kann auch weg gelassen werden.

Autor: Johann Knechtel (jo-hann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok Super per Telnet gehts auch wieder mit dem flashen. Da muss ich mir 
jetzt nur mit den verschiedenen Speicherbereichen mal klar werden, dann 
versteh ich auch die entsprechenden Linker-Skripts und Flashbefehle 
besser und kann mir ein entsprechends config-File anlegen....
Besten Dank soweit erstmal!

Eine Frage habe ich aktuell noch: was ist der praktische Unterschied von 
den beiden Assemblerbefehlen:
< AS   = $(TRGT)as
---
> AS   = $(TRGT)gcc -x assembler-with-cpp

Das der gcc mit Präprozessor das auch machen kann, habe ich in der Doku 
gefunden, aber ist dann praktisch noch ein Unterschied zur Verwendung 
von as und was sollte man nutzen?

Ach und versteh ich folgendes richtig: wenn ich im Linker-Skript 
folgende Bereiche definiere:
MEMORY
{
  ram (rwx) : ORIGIN = 0x20000000, LENGTH = 20K
  rom (rx) : ORIGIN = 0x00000000, LENGTH = 128K
}
und beim flashen dann mittels
flash write_image test.elf 0x08000000 elf
 einen Offset angebe, wird im Programm mit einem Adressraum beginnend ab 
0x0 gearbeitet, aber geflasht wird es im Chip-spezifischen Bereich?

Viele Grüße
Johann

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitteschön.
Also wenn man vom Flash lesen / schreiben möchte, dann ist der ab 
0x0800000. Anhand der BOOT-Pins wird der aber gemappt auf 0x00000000 und 
das Programm läuft dann am 0x00000000. (Siehe STM Doku, irgendwo steht 
das.)
Unterschiede as gcc weiß ich nicht.

Autor: Johann Knechtel (jo-hann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ahja ok so habe ich mir das auch schon gedacht, habe es eben in der 
Application Note von ST "getting started" oder so auch so gelesen.
Ist aber irgendwie etwas verwirrend, wenn ich im Linkerscript den 
RAM-Bereich so angebe, wie er im Chip implementiert ist (0x20000000) und 
den Flash nicht. Aber beim Flashen gebe ich dann den Offset an. Naja, 
aber wenn man weiß, dass der Flash per Boot-Pin gemappt wird, dann 
machts schon Sinn....

Viele Grüße
Johann

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.