Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Computer Controls
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

OpenOCD ustawienia w Eclipse Galileo

mieczotronix 18 Lis 2009 01:52 4621 12
  • #1 18 Lis 2009 01:52
    mieczotronix
    Poziom 15  

    Mam parę pytań do praktyków w powyższym temacie.

    Najpierw miejsce:
    W Run>Debug configurations...
    Pod GDB Hardware Debugging:
    zakładka Debugger

    1. Gdzie się teraz ustawia żeby pierwszy breakpoint był na main? Znikła ta opcja w Galileo?

    I dalej...
    zakładka "startup"

    W Initialization Commands mam:

    Code:

    monitor reset
    monitor wait 500
    monitor soft_reset_halt
    load

    2. to load w dobrym miejscu mam?

    3. W ramce "Load Image" Zaznaczam [x] Automatically load image, poniżej wpisuję pełną ścieżkę do .hexa w wersji Debug. Czy to jest do tego "load" opisanego powyżej, czy niezależnie od tego jeszcze raz mi programuje?

    4. Takie oto mi errory zapodaje
    Code:

    Unknown command: wait 500
    requesting target halt and executing a soft reset
    target state: halted
    target halted due to breakpoint, current mode: Thread
    xPSR: 0x01000000 pc: 0x08000f78 msp: 0x20005000
    Warn : not enough working area available(requested 16384, free 16336)
    Warn : not enough working area available(requested 16384, free 8144)
    Warn : stepi ignored. GDB will now fetch the register state from the target.
    Error: AHBAP Cached values: dp_select 0x0, ap_csw 0xa2000012, ap_tar 0xffffffff
    Error: SWJ-DP STICKY ERROR
    Error: Read MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc
    (...)
    Warn : Block read error address 0xfffffff8, count 0x1
    (...itd...)

    4. Które z nich są istotne, a które nie?

    5. Co wpisuje się w "Run Commands" ? (wcześniej tego pola nie było)

    6. Jeszcze nie wiem do końca co się dzieje. Ostatnio mi debugował. A teraz zaczyna jakby dobrze - zatrzymuje się na początku jakiejś funkcji (choć nie wiem dlaczego akurat tam) i F6 sobie kroczy działa dopóki nie dojdzie do końca tej funkcji, a potem skacze w kosmos i łapie go HardFaultHandler...

    To jest kosmos ten OpenOCD. Siedzę nad tym 2 godziny i widzę że tydzień to chyba będzie mało...

    0 12
  • Computer Controls
  • #2 18 Lis 2009 07:30
    Freddie Chopin
    Specjalista - Mikrokontrolery

    mieczotronix napisał:
    1. Gdzie się teraz ustawia żeby pierwszy breakpoint był na main? Znikła ta opcja w Galileo?

    W zakładce startup na samym dole - "Set breakpoint at" i doklikujesz pod tym "Resume" - u mnie takie opcje są normalnie dostępne.

    Cytat:
    W Initialization Commands mam:
    Code:

    monitor reset
    monitor wait 500
    monitor soft_reset_halt
    load

    2. to load w dobrym miejscu mam?

    Load jest w dobrym miejscu, ale po co reszta? Chyba tylko po to, żeby sobie problemów narobić... NIGDY nie używaj soft_reset_halt bez ABSOLUTNEJ konieczności. Takowa jest tylko na LPC, STM32 to zupełnie inne układy, bez tej "wady". Użyj po prostu "monitor reset halt" + "load".

    Cytat:
    3. W ramce "Load Image" Zaznaczam [x] Automatically load image, poniżej wpisuję pełną ścieżkę do .hexa w wersji Debug. Czy to jest do tego "load" opisanego powyżej, czy niezależnie od tego jeszcze raz mi programuje?

    To jest niezależna opcja. Lepiej nie ruszaj tego okienka, u mnie w ogóle ciężko było zmusić je do działania. Jeśli masz w komendach "load", to debugger wgra Ci plik elf który podałeś mu w pierwszej zakładce.

    Cytat:
    Unknown command: wait 500

    Powinno być "sleep".

    Cytat:
    4. Które z nich są istotne, a które nie?

    Praktycznie żadne nie są istotne.

    Cytat:
    5. Co wpisuje się w "Run Commands" ? (wcześniej tego pola nie było)

    To że jakieś pole "jest", nie znaczy że coś trzeba w nie wpisać, więc skoro nie masz pomysłu co tam napisać, to nie pisz nic. (Okno było wcześniej, było zawsze, tyle że na samym dole)

    Cytat:
    6. Jeszcze nie wiem do końca co się dzieje. Ostatnio mi debugował. A teraz zaczyna jakby dobrze - zatrzymuje się na początku jakiejś funkcji (choć nie wiem dlaczego akurat tam) i F6 sobie kroczy działa dopóki nie dojdzie do końca tej funkcji, a potem skacze w kosmos i łapie go HardFaultHandler...

    Łapie wyjątek krytyczny, bo program ma gdzieś równie krytyczny błąd. Istnieje szansa, że zajeżdżasz stos danymi (zbyt mały stos) i przy powrocie z funkcji adres sciągnięty ze stosu jest niepoprawny.

    Cytat:
    To jest kosmos ten OpenOCD. Siedzę nad tym 2 godziny i widzę że tydzień to chyba będzie mało...

    OpenOCD nie ma zbyt wiele do rzeczy tutaj akurat. No i nie bądź mientki <: bo ja siedzę nad tym już ponad rok, a wciąż codziennie dowiaduję się czegoś nowego [; Czemu wszystkim wydaje się, że ARMy są proste? <:

    4\/3!!

    0
  • #3 18 Lis 2009 13:30
    mieczotronix
    Poziom 15  

    Dzięki za szybką odpowiedź. Ja niestety dopiero teraz miałem okazję zajrzeć.

    Freddie Chopin napisał:
    zakładce startup na samym dole - "Set breakpoint at" i doklikujesz pod tym "Resume" - u mnie takie opcje są normalnie dostępne.

    No w moim eclipsie tego nie ma.
    Na dole mam Run Commands, pod tym przycisk Variables i Apply i Reset -nic więcej


    Zmieniłem initialization command na "monitor reset halt" i "load". Wyłączyłem Automatically load image. I kurka coś się chrzani.
    Jak teraz odpaliłem eclipse to na początku się ładnie wszystko debugowało. Potem zmieniłem projekt, też było okej. Nagle coś się nagle skopało i program zaczął mi wskakiwać do BusFaultHandler. Wróciłem do poprzedniego projektu, który działł okej, a teraz tam mi wskakuje do HardFault handlera. No to z powrotem do 2-giego projektu. Ten działa. Zatrzymuję uruchamiam kilka razy i znowu BusFaultHandler. Oczywiście oba programy chodzą w wersji Debug na płytce OK i się nie wieszają, więc to nie wina ich, ani buildu.
    Co się dzieje? Jak zresetować debugger i układ. Nie wystarczy kliknąć na czerwone kwadraty od GDB i OpenOCD (Terminate) ?
    W ogóle po takiej sesji płytka mi stoi (pewnie na tym handlerze). Zamykam GDB, OpenOCD, wychodzę z eclipse, a płytka dalej stoi. Pykam jej resetem i nic (zapala się led od resetu na lockpicku i tyle). Jak odepnę jtaga całkiem od płytki i zresetuję - dalej stoi i odpala w niej firmowy bootloader (poznaję po ledach). Jakby programu nie było w niej w cale, a przecież działał wcześniej.... Dziwne, dziwne...

    Wyłączyłem eclipse, wrzuciłem hexa w buildzie Debug za pomocą bootloadera. Stoi. Nie działa. A przecież działał. No to odpalam eclipsa. Rebuilduję Debuga w perspektywie C/C++ (myślę że może bez breakpointów wtedy będzie). Wrzucam bootloaderem i dalej nie działa.

    0
  • Computer Controls
  • #4 18 Lis 2009 14:04
    Freddie Chopin
    Specjalista - Mikrokontrolery

    No cóż, u mnie takie rewelacje się nie dzieją, a stosowne opcje w ustawieniach są dostępne...

    OpenOCD ustawienia w Eclipse Galileo

    Na pewno używasz GDB Hardware Debugging? Może Zylina?

    Jeśli rdzeń był zatrzymany to "wyłączenie" Eclipse'a, OpenOCD i GDB nic nie zmienia - trzeba go zresetowąć. Do tego układ z podłączonym JTAGiem, który jest niezasilany (odłączony od USB w kompie) na 99% będzie trzymał cały układ w resecie.

    Żeby sprawdzić czy coś w pamięci jest wystarczy ją odczytać i porównać obrazy (albo choć kilka wartości w różnych miejscach).

    4\/3!!

    0
  • #5 18 Lis 2009 18:02
    mieczotronix
    Poziom 15  

    Inne mam okienko zupełnie. Zylina nie używam. Napewno.

    Dziwne się rzeczy dzieją.
    Czuję, że problem mam raczej hardwareowy.
    Polutowałem i posprawdzałem pinheader, bufory i drabinki, ale nic to nie zmieniło. Zgniotłem kabel dokładniej, wymieniłem dżumper od zasilania bufora.
    Czasem działa (głównie "na początku" - jeszcze nie wiem co dokładnie to znaczy). Coraz rzadziej.

    Teraz np. wyświetlił:

    Code:
    load
    
    Loading section .isr_vector, size 0x10c lma 0x8000000
    Load failed

    Disassembly wyświetla jakieś głupoty
    Code:

    x00000000 andcs         r5, r0, r0
    0x00000004 stmdaeq       r0, {r0, r3, r4, r5, r6, r8, r9, r10, r11}
    0x00000008 stmdaeq       r0, {r0, r2, r3, r4, r8, r9, r10, r11}
    0x0000000c stmdaeq       r0, {r0, r3, r5, r8, r9, r10, r11}
    0x00000010 stmdaeq       r0, {r0, r4, r5, r8, r9, r10, r11}
    0x00000014 stmdaeq       r0, {r0, r3, r4, r5, r8, r9, r10, r11}
    0x00000018 stmdaeq       r0, {r0, r6, r8, r9, r10, r11}
    0x0000001c andeq         r0, r0, r0
    itd...

    Czyli pewnie same zera...
    Pamięci w zakładce "Memory" nie może odczytać. Wyświetla errory w konsoli:
    Code:

    Warn : Block write error address 0x8000000, wcount 0x43
    Error: unexpected error -107
    Warn : Block read error address 0x80000000, count 0x19

    a potem w zakładce Memory od 0x80000000 są same zera.

    Czasem zatrybi, ale rozpoczyna pracę od jakiejś przypadkowej procedury. Mogę przestepować przez nią F6, ale jak dojdę do końca i F6 dalej się nie da, to F8 leci w kosmos i do handlera...

    Jak jeżdżę po okienku memory, to raz że są same zera, a dwa że mi "Warn : Block read error" na czerwono migają.

    Czasem load zadziała i program się zuploaduje, ale debugowanie nie działa.

    0
  • #6 18 Lis 2009 20:15
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Próbuj po kolei.

    0. Wywal całego Eclipse'a i zainstaluj od nowa (najlepiej razem z Java i Java SDK [ponoć jest potrzebne] ), na początek pomiń Twoją ulubioną wtyczkę - zrób po prostu po kolei wszystko z mojego tutoriala. Okienko od GDB Hardware Debugging MUSI wyglądać tak jak na obrazku wyżej - nawet teraz ściągnąłem tą wtyczkę raz jeszcze na prawie czystym Eclipse i efekt prawidłowy.

    1. Pobierz mój przykładzik dla STM32, zmień kwarc i port/pin diodki w pliku config.h, skompiluj go przy użyciu dołączonego Makefile'a (nawet bez Eclipse - po prostu wewnątrz katalogu wklep cs-make all) i wgraj hex'a do procka bootloaderem - jak diodka będzie migać, to jest pierwszy sukces

    2. Teraz zrób to samo w Eclipse (bez Twojej ulubionej wtyczki) ale spróbuj debuggować, korzystając ze skrótów dostarczonych w przykładzie

    3. Jeśli się coś krzaczy, na początek spróbuj wyłaczyć PLLa i wszelkie inne udziwnienia

    4. Jeśli się nie krzaczy, to szukaj błędów w swoim kodzie / jego kompilacji / jego linkowaniu

    4\/3!!

    0
  • #7 19 Lis 2009 01:01
    mieczotronix
    Poziom 15  

    Taaa i wodą święconą mam też popryskać?
    Programy mi się kompilują i działają ok, jak je wgrywam na płytkę bootloaderem przez RS-a. Te same hexy raz się wgrywają, a raz nie prze jtaga. Mam jakiś problem z komunikacją gdzieś pomiędzy openOCD, jtagiem a płytką...

    Dodano po 3 [godziny] 53 [minuty]:

    Rozbudowałem trochę Initialization commands, teraz mam tak:

    Code:

    monitor reset
    monitor halt
    monitor sleep 100
    load
    break main
    continue

    Jest lepiej. Już raczej działa, nie mam tylu problemów
    Czuję, że sleep pomogło (zjechałem z 500 do 100)
    Problem mam tylko z brejkpointem, to "break main" jakoś nie chce działać, niby wyświetla się
    Code:
    "Breakpoint 1 at 0x80007de: file ../main.c, line 31.
    
    Note: automatically using hardware breakpoints for read-only addresses."

    Ale się tam nie zatrzymuje. Ten brejkpoint wyświetla się z małą strzałką u góry. Na nim się nie zatrzymuje. Na ustawionym ręcznie, bez strzałki, staje..

    0
  • #8 07 Lut 2010 23:04
    ComaY
    Poziom 10  

    No to pociągnę dalej wątek, walczę już drugi dzień, nic już mi do głowy nie przychodzi. Mój mikrokontroler to AT91SAM7S64.

    Program się kompiluje bez błędów. Tu trochę musiałem powalczyć, bo make uruchamiany z konsoli działał bez problemów, a uruchamiany z eclipse się buntował i wymagał podania pełnych ścieżek do kompilatora (CodeSourcery).

    OpenOCD widzi mikrokontroler:

    Cytat:

    Open On-Chip Debugger 0.2.0-in-development (2009-06-30-01:49) svn:r2403


    BUGS? Read /usr/share/doc/openocd/BUGS


    $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
    Info : JTAG tap: sam7x64.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
    Info : JTAG Tap/device matched



    Natomiast debugowanie ni w ząb mi nie wychodzi. :(
    Cytat:

    target remote localhost:3333
    0x00200a12 in ?? ()
    monitor reset
    JTAG tap: sam7x64.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
    JTAG Tap/device matched
    monitor halt
    target state: halted
    target halted in Thumb state due to debug-request, current mode: Supervisor
    cpsr: 0x600000b3 pc: 0x0020022e
    monitor sleep 100
    load
    Error erasing flash with vFlashErase packet
    break main
    Breakpoint 1 at 0x1000ec: file main.c, line 113.
    Note: automatically using hardware breakpoints for read-only addresses.
    continue

    Program received signal SIGINT, Interrupt.
    0x00200cc4 in ?? ()


    Ustawienia do tego wyglądaja tak:
    Cytat:

    target remote localhost:3333
    #monitor reset halt
    #monitor arm7_9 sw_bkpts enable
    #monitor poll
    #monitor flash write_image erase main.bin
    #load

    monitor reset
    monitor halt
    monitor sleep 100
    load
    break main
    continue


    I przetestowałem już tysiące chyba możliwości - co widać po zaremowanych liniach.

    A OpenOCD na koniec wypluł mi jeszcze coś takiego:
    Cytat:

    Info : accepting 'gdb' connection from 0
    target state: halted
    target halted in Thumb state due to debug-request, current mode: Supervisor
    cpsr: 0x000000b3 pc: 0x00200a12
    Warn : acknowledgment received, but no packet pending
    Info : JTAG tap: sam7x64.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
    Info : JTAG Tap/device matched
    target state: halted
    target halted in Thumb state due to debug-request, current mode: Supervisor
    cpsr: 0x600000b3 pc: 0x0020022e
    Error: status register: 0x30005
    Error: Lock Error Bit Detected, Operation Abort
    Error: failed erasing sectors 0 to 0 (-902)
    Error: flash_erase returned -902
    Info : dropped 'gdb' connection - error -400


    Jakakolwiek pomoc jest wysoce mile widziana.

    Pozdrawiam!

    0
  • #9 08 Lut 2010 07:23
    Freddie Chopin
    Specjalista - Mikrokontrolery
  • #10 08 Lut 2010 19:04
    ComaY
    Poziom 10  

    Wciąż brak efektu :(
    OpenOCD:

    Cytat:

    Open On-Chip Debugger 0.2.0-in-development (2009-06-30-01:49) svn:r2403


    BUGS? Read /usr/share/doc/openocd/BUGS


    $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
    Info : JTAG tap: sam7x64.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
    Info : JTAG Tap/device matched
    Info : accepting 'gdb' connection from 0
    target state: halted
    target halted in Thumb state due to debug-request, current mode: Supervisor
    cpsr: 0x200000b3 pc: 0x00200a7a
    Warn : acknowledgment received, but no packet pending
    Info : JTAG tap: sam7x64.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
    Info : JTAG Tap/device matched
    Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
    target state: halted
    target halted in ARM state due to debug-request, current mode: Supervisor
    cpsr: 0x20000093 pc: 0x000000a0
    Error: status register: 0x30005
    Error: Lock Error Bit Detected, Operation Abort
    Error: failed erasing sectors 0 to 0 (-902)
    Error: flash_erase returned -902
    Info : dropped 'gdb' connection - error -400
    Info : accepting 'gdb' connection from 0
    Warn : acknowledgment received, but no packet pending
    Info : JTAG tap: sam7x64.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
    Info : JTAG Tap/device matched
    Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
    target state: halted
    target halted in ARM state due to debug-request, current mode: Supervisor
    cpsr: 0x20000093 pc: 0x000000a4
    Error: status register: 0x30005
    Error: Lock Error Bit Detected, Operation Abort
    Error: failed erasing sectors 0 to 0 (-902)
    Error: flash_erase returned -902
    Info : dropped 'gdb' connection - error -400


    GDB
    Cytat:

    target remote localhost:3333
    0x00200cae in ?? ()
    monitor reset halt
    JTAG tap: sam7x64.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
    JTAG Tap/device matched
    srst pulls trst - can not reset into halted mode. Issuing halt after reset.
    target state: halted
    target halted in ARM state due to debug-request, current mode: Supervisor
    cpsr: 0x20000093 pc: 0x000000a4
    monitor sleep 100
    load
    Error erasing flash with vFlashErase packet
    break main
    Breakpoint 1 at 0x1000ec: file main.c, line 113.
    continue
    Note: automatically using hardware breakpoints for read-only addresses.

    Program received signal SIGINT, Interrupt.
    0x002001d8 in ?? ()
    kill


    To co mi przychodzi do głowy to ewentualnie jeszcze skrypt startowy do OpenOCD
    Cytat:

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

    if { [info exists CHIPNAME] } {
    set _CHIPNAME $CHIPNAME
    } else {
    set _CHIPNAME sam7x64
    }

    if { [info exists ENDIAN] } {
    set _ENDIAN $ENDIAN
    } else {
    set _ENDIAN little
    }

    if { [info exists CPUTAPID ] } {
    set _CPUTAPID $CPUTAPID
    } else {
    set _CPUTAPID 0x3f0f0f0f
    }

    jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID

    set _TARGETNAME [format "%s.cpu" $_CHIPNAME]

    target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position $_TARGETNAME -variant arm7tdmi
    $_TARGETNAME configure -event reset-init {
    # disable watchdog
    mww 0xfffffd44 0x00008000
    # enable user reset
    mww 0xfffffd08 0xa5000001
    # CKGR_MOR : enable the main oscillator
    mww 0xfffffc20 0x00000601
    sleep 10
    # CKGR_PLLR: 96.1097 MHz
    mww 0xfffffc2c 0x00481c0e
    sleep 10
    # PMC_MCKR : MCK = PLL / 2 ~= 48 MHz
    mww 0xfffffc30 0x00000007
    sleep 10
    # MC_FMR: flash mode (FWS=1,FMCN=60)
    mww 0xffffff60 0x003c0100
    sleep 100
    }

    $_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x00200000 -work-area-size 0x4000 -work-area-backup 0

    #flash bank <driver> <base_addr> <size> <chip_width> <bus_width> <target_number> [<target_name> <banks> <sectors_per_bank> <pages_per_sector> <page_size> <num_nvmbits> <ext_freq_khz>]
    flash bank at91sam7 0 0 0 0 0 0 0 0 0 0 0 0 18432

    # For more information about the configuration files, take a look at:
    # openocd.texi


    Skrypt przerobiłem samodzielnie z załączonego do OpenOCD sam7x256.cfg




    ----------------------------------------------------------
    Probem częściowo już rozwiązałem, jak się okazuje SAM-BA ustawia na dwóch stronach bity blokujące je. Dlatego nie można było wgrać żadnego programu. Gdyby ktoś miał podobny problem to trzeba:
    1. Się połączyć telnetem do OpenOCD
    2. wykonać tam takie polecenie: flash protect 0 0 1 off

    0
  • #11 15 Kwi 2010 15:25
    Smashing
    Poziom 20  

    Witam
    Ja używam 3 skryptów do SAM7.
    Jtag i Open OCD 3.1, .cfg z Open OCD wszystko od kolegi Freddie Chopin.
    Programowanie Flash SAM7przez OCD:
    init
    reset halt
    wait halt
    poll
    flash write_image erase main.bin 0x100000 bin
    reset run
    resume

    Debag Flash
    monitor reset halt
    monitor gdb_breakpoint_override hard
    load
    tbreak main
    continue

    Debag Ram + zmiana skryptu linkera na ram + kompilacja

    monitor reset
    monitor soft_reset_halt
    monitor mww 0xffffff00 0x01 -- remap
    load
    tbreak main
    continue

    Nie wiem czy te ustawienia maja sens ale nigdy nie miałem problemu z debag'iem i programowaniem

    0
  • #12 22 Kwi 2010 07:38
    flapo213
    Poziom 21  

    Czy Twój problem nie polega przypadkiem na tym że odpalasz openocd w trybie debug, openocd oczekuje na połączenie i w tym momencie dajesz w eclipse debug i coś tam coś tam rzeźbi po czym w eclipsie przechodzi do zakładki debug-u i zrywa połączenie z openocd. Jeśli tak to masz złe ustawienia eclipse. Ja miałem kiedyś takiego typu problem, ale zmęczyłem go i chodzi u mnie już, jak zechcesz to podeślę Ci dokument co i jak zrobić aby śmigało.

    Z tego co zauważyłem u Ciebie to jest problem z flashem czy nie masz go przypadkiem zablokowanego?

    Code:
    Error: Lock Error Bit Detected, Operation Abort 
    
    Error: failed erasing sectors 0 to 0 (-902)
    Error: flash_erase returned -902


    Pozdrawiam

    0
  • #13 23 Kwi 2010 19:22
    ComaY
    Poziom 10  

    flapo213 napisał:
    Czy Twój problem nie polega przypadkiem na tym że odpalasz openocd w trybie debug, openocd oczekuje na połączenie i w tym momencie dajesz w eclipse debug i coś tam coś tam rzeźbi po czym w eclipsie przechodzi do zakładki debug-u i zrywa połączenie z openocd. Jeśli tak to masz złe ustawienia eclipse. Ja miałem kiedyś takiego typu problem, ale zmęczyłem go i chodzi u mnie już, jak zechcesz to podeślę Ci dokument co i jak zrobić aby śmigało.

    Z tego co zauważyłem u Ciebie to jest problem z flashem czy nie masz go przypadkiem zablokowanego?

    Code:
    Error: Lock Error Bit Detected, Operation Abort 
    
    Error: failed erasing sectors 0 to 0 (-902)
    Error: flash_erase returned -902


    Pozdrawiam


    Tak, tak było, zaraz jak to rozkminiłem, to umieściłem odpowiedź jeszcze w tym samym poście, wrzuciłem rozwiązanie dla innych, gdyby mieli z tym problem.

    Pozdrawiam!

    0