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


von Johann K. (jo-hann)


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:
1
Info:    options.c:50 configuration_output_handler():   #127: 0x0001fc00 (0x400 1kB) not protected
2
Info:    options.c:50 configuration_output_handler(): stm32x flash driver info
3
Error:   flash.c:890 get_flash_bank_by_addr(): No flash at address 0x00000000
4
5
Info:    options.c:50 configuration_output_handler(): wrote 0 byte from file main.bin in 0.000074s (0.000000 kb/s)
6
Info:    jtag.c:1389 jtag_examine_chain(): JTAG device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0xba00, Version: 0x3)
7
Info:    jtag.c:1389 jtag_examine_chain(): JTAG device found: 0x16410041 (Manufacturer: 0x020, Part: 0x6410, Version: 0x1)
1
#daemon configuration
2
telnet_port 4444
3
gdb_port 3333
4
5
#interface
6
interface parport
7
parport_port 0x378
8
parport_cable wiggler
9
jtag_speed 10
10
11
reset_config srst_only
12
13
#jtag scan chain
14
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
15
jtag_device 4 0x1 0xf 0xe
16
jtag_device 5 0x1 0x1 0x1e
17
18
#target configuration
19
daemon_startup reset
20
21
#target <type> <startup mode>
22
#target cortex_m3 <endianness> <reset mode> <chainpos> <variant>
23
#target cortex_m3 little run_and_halt 0
24
target cortex_m3 little run_and_init 0
25
#run_and_halt_time 0 30
26
27
#flash bank <driver> <base> <size> <chip_width> <bus_width>
28
flash bank stm32x 0x08000000 0x00010000 0 0 0
29
flash auto_erase on
30
31
# 4k working area at base of ram
32
#working_area 0 0x20000800 0x1200 nobackup
33
# all ram
34
working_area 0 0x20000000 0x2000 nobackup
35
36
# script running on reset
37
target_script 0 reset lmi.script

lmi.script:
1
flash probe 0
2
flash erase_check 0
3
flash protect_check 0
4
flash info 0
5
6
flash write_image main.bin 0 bin
7
8
sleep 200
9
10
reset run
11
shutdown

Wenn ich dann intuitiv die Datei lmi.script anpasse, sodass write_image 
mit dem Offset 0x08000000 arbeitet wird folgendes ausgegeben:
1
Warning: target.c:853 target_alloc_working_area(): not enough working area available(requested 8192, free 8144)
2
Error:   stm32x.c:556 stm32x_write(): flash writing failed with error code: 0xfffffc7a
3
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

von ich (Gast)


Lesenswert?

OpenOCD CFG Datei:
1
#daemon configuration
2
telnet_port 4444
3
gdb_port 3333
4
5
# tell gdb our flash memory map
6
# and enable flash programming
7
#gdb_memory_map enable
8
gdb_flash_program enable
9
10
#interface
11
interface ft2232
12
ft2232_device_desc "Olimex OpenOCD JTAG A"
13
ft2232_layout "olimex-jtag"
14
ft2232_vid_pid 0x15BA 0x0003
15
jtag_speed 10
16
jtag_nsrst_delay 100
17
jtag_ntrst_delay 100
18
19
#use combined on interfaces or targets that can't set TRST/SRST separately
20
reset_config trst_and_srst
21
22
#jtag scan chain
23
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
24
jtag_device 4 0x1 0xf 0xe
25
jtag_device 5 0x1 0x1 0x1e
26
27
daemon_startup reset
28
#run_and_halt_time 0 30
29
30
#target configuration
31
target cortex_m3 little reset_halt 0
32
#target cortex_m3 little run_and_halt 0
33
34
working_area 0 0x20000000 0x5000 nobackup
35
36
#flash configuration
37
#target_script 0 reset openocd_lpc2368_flash.script
38
#flash bank lpc2000 <base> <size> 0 0 0 <target#> <variant>
39
flash bank stm32x 0x08000000 0x20000 0 0 0

GDB Kommandos:
1
set complaints 1
2
set output-radix 16
3
set input-radix 16
4
set prompt (arm-gdb)
5
target remote localhost:3333
6
set remote memory-write-packet-size 1024
7
set remote memory-write-packet-size fixed
8
set remote memory-read-packet-size 1024
9
set remote memory-read-packet-size fixed
10
set remote hardware-watchpoint-limit 6
11
set remote hardware-breakpoint-limit 6
12
monitor reset
13
monitor sleep 200
14
monitor poll
15
monitor soft_reset_halt
16
monitor stm32x unlock 0
17
monitor stm32x mass_erase 0
18
monitor flash write_image main.elf 0x08000000 elf
19
monitor reset
20
monitor poll
21
break main
22
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"

von Johann K. (jo-hann)


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:
1
.linking ram elf
2
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
3
arm-none-linux-gnueabi-gcc: main.o: linker input file unused because linking not done

Mein makefile:
1
NAME   = stm_p103
2
3
CC      = arm-none-linux-gnueabi-gcc
4
LD      = arm-none-linux-gnueabi-ld -v
5
AR      = arm-none-linux-gnueabi-ar
6
AS      = arm-none-linux-gnueabi-as
7
CP      = arm-none-linux-gnueabi-objcopy
8
OD  = arm-none-linux-gnueabi-objdump
9
  
10
CFLAGS  =  -I./ -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb 
11
AFLAGS  = -ahls -mapcs-32 -o crt.o
12
LFLAGS  = -T $(LINK).cmd -nostartfiles
13
LELFFLAGS = $(LFLAGS) -Wl,-Map=main.map,--cref
14
CPFLAGS = -O binary
15
ODFLAGS  = -S
16
17
all: rom
18
rom: compile link copy
19
LINK = rom
20
ram: compile link copy
21
LINK = ram
22
23
compile: main.o stm32f10x_rcc.o stm32f10x_gpio.o
24
25
clean:
26
  -rm main.lst main.o main.out main.hex main.map stm32f10x_rcc.o stm32f10x_gpio.o
27
28
copy:
29
  @ echo "...copying"
30
  $(CP) $(CPFLAGS) main.out main.bin
31
  $(OD) $(ODFLAGS) main.out > main.lst
32
33
link: main.elf
34
  @ echo "..linking $(LINK) bin"
35
  $(LD) $(LFLAGS) -o main.out  main.o stm32f10x_rcc.o stm32f10x_gpio.o 
36
37
main.elf:
38
  @ echo ".linking $(LINK) elf"
39
  $(CC) $(CFLAGS) main.o stm32f10x_rcc.o stm32f10x_gpio.o --output main.elf $(LELFFLAGS)
40
41
stm32f10x_rcc.o: stm32f10x_rcc.c 
42
  @ echo ".compiling"
43
  $(CC) $(CFLAGS) stm32f10x_rcc.c 
44
   
45
stm32f10x_gpio.o: stm32f10x_gpio.c
46
  @ echo ".compiling"
47
  $(CC) $(CFLAGS) stm32f10x_gpio.c 
48
49
main.o: main.c
50
  @ echo ".compiling"
51
  $(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

von Johann K. (jo-hann)


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:
1
< TRGT = arm-none-linux-gnueabi-
2
---
3
> TRGT = arm-elf-
4
22c22
5
< AS   = $(TRGT)as
6
---
7
> AS   = $(TRGT)gcc -x assembler-with-cpp
8
26,27c26,29
9
< MCU  = cortex-m3
10
< THUMB    = -mthumb
11
---
12
> MCU  = arm7tdmi-s
13
> #SUBMDL = LPC2368
14
> #THUMB    = -mthumb
15
> THUMB_IW = -mthumb-interwork
16
55,57c57,58
17
< # Define linker script file here
18
< #TODO
19
< LDSCRIPT= ram.cmd
20
---
21
> # Define linker script file here
22
> LDSCRIPT= ./prj/lpc2368.ld
23
66c67
24
< SRC  = main.c stm32f10x_rcc.c stm32f10x_gpio.c
25
---
26
> SRC  = ./src/main.c ./src/target.c ./src/irq.c
27
69c70
28
< ASRC =
29
---
30
> ASRC = ./src/boot.s
31
72c73
32
< UINCDIR = ./
33
---
34
> UINCDIR = ./inc
35
96,97c97,98
36
< ASFLAGS = $(MCFLAGS) -g -gdwarf-2 $(THUMB) $(THUMB_IW) -Wa,-amhls=$(<:.s=.lst) $(ADEFS)
37
< #ASFLAGS = $(MCFLAGS) -g -gdwarf-2 -Wa,-amhls=$(<:.s=.lst) $(ADEFS)
38
---
39
> #ASFLAGS = $(MCFLAGS) -g -gdwarf-2 $(THUMB) $(THUMB_IW) -Wa,-amhls=$(<:.s=.lst) $(ADEFS)
40
> 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:
1
MEMORY
2
{
3
  ram (rwx) : ORIGIN = 0x20000000, LENGTH = 20K
4
  rom (rx) : ORIGIN = 0x00000000, LENGTH = 128K
5
}
6
SECTIONS
7
  {
8
  .  = 0x0;          /* From 0x00000000 */
9
    .text : {
10
    *(vectors)      /* Vector table */
11
    *(.text)        /* Program code */
12
    *(.rodata)      /* Read only data */
13
    } >ram
14
    .  = 0x20000000;   /* From 0x20000000 */      
15
    .data : {
16
    *(.data)        /* Data memory */
17
    } >ram
18
    .cs3.rom :
19
  {
20
    __cs3_region_start_rom = .;
21
    *(.cs3.region-head.rom)
22
    *(.rom)
23
    . = ALIGN (8);
24
  } >rom
25
  .cs3.rom.bss :
26
  {
27
    *(.rom.b)
28
    . = ALIGN (8);
29
  } >rom
30
  .bss : {
31
    *(.bss)         /* Zero-filled run time allocate data memory */
32
    } >ram
33
 }  
34
/*========== end of file ==========*/

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

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

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

Viele Grüße
Johann

von ich (Gast)


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.

von Johann K. (jo-hann)


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?

von ich (Gast)


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.

von Johann K. (jo-hann)


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:
1
< AS   = $(TRGT)as
2
---
3
> 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:
1
MEMORY
2
{
3
  ram (rwx) : ORIGIN = 0x20000000, LENGTH = 20K
4
  rom (rx) : ORIGIN = 0x00000000, LENGTH = 128K
5
}
und beim flashen dann mittels
1
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

von ich (Gast)


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.

von Johann K. (jo-hann)


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

Bitte 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
Noch kein Account? Hier anmelden.