OOCD mit STM32F103

[rwlfk]

Hallo alle zusammen

Ich benutzte zur zeit die STM32F103 Serie in einer Embedded App. zusammen mit OOCD und habe dabei ein Problem:

Erste Konfiguration:
STM32 Evalboard von KEIL mit STM32 in 64 Pinout und 64 K Flash
(STM32F103R8T6)
Amontec-JTAG-Key
OOCD r423 and r717

Lief alles super


Zweite Konfiguration:
STM32 jetzt in meiner Embedded app. und in 48 pinout 64 k flash
(STM32F103C8T6)
Amontec-JTAG-Key
OOCD r423 and r717

Lief nicht!

Naja nicht ganz, denn OOCD findet beide JTAG-Devices im µC und hängt sich dann auf.
Der output von OOCD mit debug = 3:

================================================== =============================
Debug: 8 0 command.c:432 command_run_line(): telnet_port 4444
Debug: 10 0 command.c:432 command_run_line(): gdb_port 3333
Debug: 12 0 command.c:432 command_run_line(): interface ft2232
Debug: 14 0 command.c:432 command_run_line(): ft2232_device_desc
"Amontec JTAGkey A"
Debug: 16 0 command.c:432 command_run_line(): ft2232_layout jtagkey
Debug: 18 0 command.c:432 command_run_line(): jtag_speed 9
Debug: 19 0 jtag.c:1863 handle_jtag_speed_command(): handle jtag speed
Info: 20 0 options.c:50 configuration_output_handler(): jtag_speed:
9, 9
Debug: 22 0 command.c:432 command_run_line(): jtag_nsrst_delay 500
Debug: 24 0 command.c:432 command_run_line(): jtag_ntrst_delay 500
Debug: 26 0 command.c:432 command_run_line(): reset_config trst_only
Debug: 28 0 command.c:432 command_run_line(): jtag_device 4 0x1 0xf
0xe
Debug: 30 0 command.c:432 command_run_line(): jtag_device 5 0x1 0x1
0x1e
Debug: 32 0 command.c:432 command_run_line(): daemon_startup attach
Info: 33 0 options.c:50 configuration_output_handler(): Open On-Chip
Debugger (2008-06-19 19:00) svn: 717
Debug: 35 0 command.c:432 command_run_line(): target cortex_m3 little
run_and_halt 0
Debug: 37 0 command.c:432 command_run_line(): run_and_halt_time 0 30
Debug: 39 0 command.c:432 command_run_line(): working_area 0
0x20000000 0x4000 nobackup
Debug: 41 0 command.c:432 command_run_line(): flash bank stm32x
0x08000000 0x10000 0 0 0
Debug: 43 0 command.c:432 command_run_line(): gdb_memory_map enable
Debug: 45 0 command.c:432 command_run_line(): init
Debug: 46 0 openocd.c:102 handle_init_command(): target init complete
Debug: 47 0 ft2232.c:1374 ft2232_init_ftd2xx(): 'ft2232' interface
using FTD2XX with 'jtagkey' layout (0403:6010)
Debug: 48 30 ft2232.c:1463 ft2232_init_ftd2xx(): current latency
timer: 2
Debug: 49 40 ft2232.c:1729 jtagkey_init(): 80 08 1b
Debug: 50 40 ft2232.c:1787 jtagkey_init(): 82 09 0f
Debug: 51 40 ft2232.c:253 ft2232_speed(): 86 09 00
Debug: 52 50 openocd.c:109 handle_init_command(): jtag interface init
complete
Debug: 53 50 jtag.c:1537 jtag_init_inner(): Init JTAG chain
Debug: 54 50 jtag.c:326 jtag_call_event_callbacks(): jtag event: JTAG
controller reset (TLR or TRST)
Debug: 55 50 jtag.c:1295 jtag_reset_callback(): -
Debug: 56 50 jtag.c:1295 jtag_reset_callback(): -
Debug: 57 50 jtag.c:326 jtag_call_event_callbacks(): jtag event: JTAG
controller reset (TLR or TRST)
Debug: 58 50 jtag.c:1295 jtag_reset_callback(): -
Debug: 59 50 jtag.c:1295 jtag_reset_callback(): -
Info: 60 60 jtag.c:1389 jtag_examine_chain(): JTAG device found:
0x3ba00477 (Manufacturer: 0x23b, Part: 0xba00, Version: 0x3)
Info: 61 60 jtag.c:1389 jtag_examine_chain(): JTAG device found:
0x16410041 (Manufacturer: 0x020, Part: 0x6410, Version: 0x1)
Debug: 62 60 jtag.c:326 jtag_call_event_callbacks(): jtag event: JTAG
controller reset (TLR or TRST)
Debug: 63 60 jtag.c:1295 jtag_reset_callback(): -
Debug: 64 60 jtag.c:1295 jtag_reset_callback(): -
Debug: 65 60 openocd.c:116 handle_init_command(): jtag init complete
Debug: 66 60 cortex_swjdp.c:946 ahbap_debugport_init():
Debug: 67 60 cortex_swjdp.c:965 ahbap_debugport_init(): swjdp: wait
CDBGPWRUPACK
Debug: 68 80 cortex_swjdp.c:965 ahbap_debugport_init(): swjdp: wait
CDBGPWRUPACK
Debug: 69 90 cortex_swjdp.c:965 ahbap_debugport_init(): swjdp: wait
CDBGPWRUPACK
Debug: 70 100 cortex_swjdp.c:965 ahbap_debugport_init(): swjdp: wait
CDBGPWRUPACK
Debug: 71 110 cortex_swjdp.c:965 ahbap_debugport_init(): swjdp: wait
CDBGPWRUPACK
Debug: 72 120 cortex_swjdp.c:965 ahbap_debugport_init(): swjdp: wait
CDBGPWRUPACK
Debug: 73 130 cortex_swjdp.c:965 ahbap_debugport_init(): swjdp: wait
CDBGPWRUPACK
Debug: 74 140 cortex_swjdp.c:965 ahbap_debugport_init(): swjdp: wait
CDBGPWRUPACK
Debug: 75 150 cortex_swjdp.c:965 ahbap_debugport_init(): swjdp: wait
CDBGPWRUPACK
Debug: 76 160 cortex_swjdp.c:965 ahbap_debugport_init(): swjdp: wait
CDBGPWRUPACK
Debug: 77 170 cortex_swjdp.c:208 swjdp_transaction_endcheck(): swjdp:
CTRL/STAT error 0x20
Debug: 78 170 cortex_swjdp.c:946 ahbap_debugport_init():
Debug: 79 170 cortex_swjdp.c:965 ahbap_debugport_init(): swjdp: wait
CDBGPWRUPACK
...
...
...
================================================== ===========================

Beide Versionen von OOCD machen das gleiche.
Also habe ich mal im Soucrecode unter 'cortex_swjdp.c:965' nachgeschaut was 'CDBGPWRUPACK' heist: irgentwas mit 'waiting for the debug port to power up' oder so ähnlich. Also im STM32 manual nachgeschaut: es gibt nur eine (hoffentlich habe ich mich nicht verlesen) Möglichkeit den Debug port abzuknipsen: der tiefste schlafmodus (der 'DEEPSLEEP' oer so ähnlich genannt wird). Obwohl ich mir nicht vostellen kann wie der Chip dahin kommt (der µC iss Fabrickneu) habe ich mal versucht ihn wieder aufzuwecken, das soll laut Datenblatt mit einem toggeln von WAKEUP_PIN oder einem generellen Reset (NRESET) funktionieren. Ich hab beides versucht und es hat nix geändert (wärend OOCD obiges anzeigt und auch einmal vor starten von OOCD)

Halt! jezt der Mysteriöse teil:
Ich hab den uLink me von KEIL, der beim Evalboard dabei war mal an meine ebedded app. angesteckt und ihn versucht mit µVision zu programmieren: µVision sagt das da funktioniert hat! Allerdings sieht es nicht danach aus als ob das programmierte wirklich funktionieren würde (ich hab das übliche LED toggeln versucht, und konnte mit nem DSO nichts dergleichen erkennen).
So, nu habe ich den JTAGKey wieder angesteckt und versucht den OOCD zu starten, und ca. nach dem 10ten Versuch hats auf einmal funktioniert! Ich konnete das Flash lesen, schreiben und nochmal lesen, dann hats weider nicht mehr funktioniert. Vision sagt immer noch, das er den µC programmiert bekommt, wenn ich allerdings versuche den Chip mit µVision zu debuggen, gibts nur unverständlichen müll vonsich oder stürzt gleich ab.
Nebenbei: nach obiger Prozedur habe ich nochmal verscuht das Evalboard mit dem JTAGKey zu debuggen/flashen, was immer noch super funktioniert also der Adapter iss in ordnung.

Gut Ich hab gedacht 'Wackelkontakt am Stecker' zu meiner embedded app. aber das kann eigentlich nicht sein, da (neben zweimaligen durchpiepsen) OOCD JEDES MAL die beiden JTAG-Devices zuverlässig findet, samt ID u.ä.
Iss vielleicht der µC kaputt???

HIIIIIIILFE !


Angehängt, die Konfiguration für OOCD r717:
================================================== =============================
debug_level 3
#log_output "c:\oocd_r717_err.log"

#daemon configuration
telnet_port 4444
gdb_port 3333

#interface
interface ft2232
ft2232_device_desc "Amontec JTAGkey A"
ft2232_layout jtagkey
jtag_speed 9

jtag_nsrst_delay 500
jtag_ntrst_delay 500

#use combined on interfaces or targets that can’t set TRST/SRST
separately
reset_config trst_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 attach

#target <type> <startup mode>
#target cortex_m3 <endianness> <reset mode> <chainpos> <variant>
target cortex_m3 little run_and_halt 0
run_and_halt_time 0 30
working_area 0 0x20000000 0x4000 nobackup

#flash bank <driver> <base> <size> <chip_width> <bus_width>
flash bank stm32x 0x08000000 0x10000 0 0 0

#debug
gdb_memory_map enable
================================================== =============================

[rwlfk]

Hallo nochmal!

Ich habs raus: der Chip war tatsächlich kaputt. Nach dem ich einen neuen in vergleichbarer Konfiguration zum test eingesetzt habe, funktioniert dieser bestens.

cYa