-
        

Ergebnis 1 bis 2 von 2

Thema: OOCD mit STM32F103

  1. #1

    OOCD mit STM32F103

    Anzeige

    SMARTPHONES & TABLETS-bis zu 77% RABATT-Kostenlose Lieferung-Aktuell | Cool | Unentbehrlich
    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
    ================================================== =============================

  2. #2
    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

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •