Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

LPC17xx - program działa, ale debugger ląduje w HardFault

dexterslab 16 Apr 2012 13:11 2690 23
Nazwa.pl
  • #1
    dexterslab
    Level 13  
    Witam, mam problem z debugowaniem procka LPC1788.
    Otóż program sam w sobie działa poprawnie po wgraniu do flash za pomocą OpenOCD. Jednak z debugowaniem sprawa przedstawia się następująco:
    - jeśli dany program był wcześniej uruchomiony na procku, to po uruchomieniu debuggera ResetISR() wykonuje się prawidłowo i program działa, można sobie steppować itd
    - jeśli program nie był wcześniej uruchomiony lub program się wysypał na skutek błędu (wylądował w jakimś xxxFault), to ResetISR() dochodzi do momentu zerowania sekcji BSS i ląduje w HardFault().

    Code: c
    Log in, to see the code


    To jest standardowy plik cr_startup_lpc178x.c dołączony do przykładów z LpcExpresso.

    I moje pytanie - bo CM3 są dla mnie nowymi prockami - czy trzeba coś ekstra ustawiać/resetować na samym początku programu? Przerwania? tryb pracy? priorytety? Z pewnych względów nie używam środowiska CodeRED tylko klasycznie OpenOCD + CodeSourcery. Trochę się to nie trzyma kupy że program sam działa, a przy sesji debuggera działa tylko jeśli był wcześniej uruchomiony (czyli że niby jakaś konfiguracja została w rejestrach która pozwala na poprawną pracę?)
    Przewija się przez forum parę wątków gdzie ludzie twierdzą że część problemów wynika z samej CMSIS, ale im program w ogóle nie działał, a mi działa.... warunkowo :cry:
  • Nazwa.pl
  • #2
    Freddie Chopin
    MCUs specialist
    Jaką masz wersję OpenOCD? Problem wynika z tego, że w Cortexach jeden ze stosów jest inicjalizowany SPRZĘTOWO, po resecie, tak samo pobierany jest adres funkcji Reset_Handler(). Problem o którym piszesz jest znany i polega na tym, że procka resetujesz, on w tym momencie wczytuje sobie SP oraz adres funkcji Reset_Handler(), a następnie programujesz do niego coś nowego, zupełnie innego itd., po czym uruchamiasz rdzeń i on sobie startuje, tyle że używając STARYCH danych.

    Generalnie sprawdzałem to ostatnio i wydawało mi się, że rozwojowe wersje OpenOCD już to rozwiązały (nie mogłem wywołać tego problemu), stąd moje pytanie. Jeśli nie, to rozwiązaniem problemu jest drobna modyfikacja skryptu konfiguracyjnego dla używanego przez Ciebie układu.

    Daj więc znać i pokaż też plik konfiguracyjny którego używasz do OpenOCD.

    4\/3!!
  • #3
    dexterslab
    Level 13  
    Używam Twojej kompilacji 050. A potwierdzenie domysłu że coś pozostaje po resecie zaskoczyło mnie ;) Ale ja wgrywam właściwie to samo, bez zmian.
    No nie ważne. Skrypt (same ewenty, bez konfiga adaptera) :

    
    #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    #                       WGRANIE SOFTU
    #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    proc lpc1788_load_soft { } {
        echo " "
        echo "-- Loading image..."
    	flash write_image dist/Debug/PolarisHP.elf 0 elf
    }
    
    #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    #                       KONFIGURACJA EVENTÓW
    #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    $_TARGETNAME configure -event reset-init {
    	# Do not remap 0x0000-0x0020 to anything but the flash (i.e. select
    	# "User Flash Mode" where interrupt vectors are _not_ remapped,
    	# and reside in flash instead).
    	#
    	# See Table 612. Memory Mapping Control register (MEMMAP - 0x400F C040) bit description
    	# Bit Symbol Value Description Reset
    	# value
    	# 0 MAP Memory map control. 0
    	# 0 Boot mode. A portion of the Boot ROM is mapped to address 0.
    	# 1 User mode. The on-chip Flash memory is mapped to address 0.
    	# 31:1 - Reserved. The value read from a reserved bit is not defined. NA
    	#
    	# http://ics.nxp.com/support/documents/microcontrollers/?scope=LPC1768&type=user
    
        echo "-- reset-init"
    	mww 0x400FC040 0x01
    }
    
    $_TARGETNAME configure -event reset-start {
        echo "-- reset-start"
    	jtag_khz 100
    }
    
    $_TARGETNAME configure -event gdb-attach {
        echo " "
        echo "-- GDB Connected ---------------------"
    
    	reset init
    	sleep 200
    	soft_reset_halt
    	sleep 100
    	jtag_khz 1000
    	lpc1788_load_soft
    	echo " "
    	echo "-- Run "
    }
    
    $_TARGETNAME configure -event gdb-detach {
        echo " "
        echo "-- GDB Disconnected ---------------------"
    }
    


    Wiem że są 2 stosy (main i process), ale przecież wskaźnik to pierwsza wartość tablicy wektorów przerwań... No nie wiem, do tej pory miałem do czynienia tylko z ARM7 i niuanse CM3 nie są mi jeszcze znane.
  • Helpful post
    #4
    Freddie Chopin
    MCUs specialist
    Używanie komendy soft_reset_halt jest źródłem niezliczonej ilości problemów... Tak pozatym to przed wgrywaniem flasha warto byłoby go wyczyścić, np rozbudowując nieco obecną u Ciebie komendę:
    flash write_image erase ...

    Dodawanie "0 elf" jest zbędne.

    Jakiego masz JTAGa? Pokaż CAŁĄ konfigurację targeta, bo wydaje mi się, że Twój problem może rozwiązać dodanie do konfiguracji:
    reset_config trst_and_srst separate
    i pozbycie się resetu programowego

    4\/3!!
  • Nazwa.pl
  • #5
    dexterslab
    Level 13  
    No nieeee, to nie może być takie proste...
    Faktycznie przeoczyłem parametr erase przy ładowaniu wsadu, a w skrypcie do programowania parametr jest. Testowałem: kilka prób uruchomienia debuggera 'po staremu' i zawsze Fault, po dodaniu erase program elegancko zatrzymał się na breaku w main :D Czyli bez tego tylko nadpisywały się poprzednie bity i program wysypywał się w pierwszym miejscu gdzie była zmiana w stosunku do poprzedniego....

    Co do soft_reset_halt, też wykonałem kilka prób i nie zauważyłem problemów, nie ważne czy instrukcja jest czy zastąpiona zwykłym halt.

    Możesz powiedzieć coś więcej na temat instrukcji soft_reset_halt ? Jakie może sprawiać problemy? To jest przecież zwykły programowy reset procka zatrzymujący go na wektorze resetu, przydaje sie przy debuggowaniu jak procek pójdzie w maliny.
  • #6
    Freddie Chopin
    MCUs specialist
    Chodzi o to, że soft_reset_halt niczego tak naprawdę nie resetuje - po takim "resecie" układ może mieć rozkręcony PLL albo i nie, wyłączony jakiś zegar (albo i nie), może być przełączony na jakiś super wolny zegar RTC (albo i nie), może mieć coś wymieszane z pamięcią (albo i nie). Generalnie niczego nie można być pewnym, a czasem niektóre parametry (np właśnie prędkość rdzenia) mają duże znaczenie dla programowania.

    4\/3!!
  • #7
    dexterslab
    Level 13  
    Nie no, to wiadomo, to jest halt + ustawienie PC na początku programu, bez resetu sprzętowego, więc rejestry pozostają. A potem idzie normalny lowlevel init więc nie powinno to w niczym przeszkadzać. Przypadki szczególne pomińmy tutaj.
    Myślałem że instrukcja sama w sobie ma jakiś feler ;)
    Ech, ależ trzeba cierpliwości żeby to poskładać do kupy, a na wyciągnięcie reki jest gotowy komercyjny pakiet w którym wszystko działa. Tylko jak się często okazuje, 'wszystko' ma liczne niedoróby lub narzucone ograniczenia (wynikające ze ścieżki jaką poszli jego twórcy) na które nic nie można poradzić.
    Dlatego... Niech żyje OpenSource!
  • #8
    asier
    Level 11  
    Freddie Chopin wrote:
    Problem wynika z tego, że w Cortexach jeden ze stosów jest inicjalizowany SPRZĘTOWO, po resecie, tak samo pobierany jest adres funkcji Reset_Handler(). Problem o którym piszesz jest znany i polega na tym, że procka resetujesz, on w tym momencie wczytuje sobie SP oraz adres funkcji Reset_Handler(), a następnie programujesz do niego coś nowego, zupełnie innego itd., po czym uruchamiasz rdzeń i on sobie startuje, tyle że używając STARYCH danych.
    Generalnie sprawdzałem to ostatnio i wydawało mi się, że rozwojowe wersje OpenOCD już to rozwiązały (nie mogłem wywołać tego problemu), stąd moje pytanie. Jeśli nie, to rozwiązaniem problemu jest drobna modyfikacja skryptu konfiguracyjnego dla używanego przez Ciebie układu.

    Spotkałem się z tym problemem gdy przesiadałem się z Ride7 na Eclipsa. Po zmianach w moim programie, funkcja Reset_Handler() trafiała w inne miejsce i po załadowaniu programu do STM32 program lądował w HardFault_Handler. Poszedłem tropem tego jak rozwiązano ten problem w Ride7. W pliku linkera umieszczają oni polecenie STARTUP("startup_stm32f10x_hd.o"), co powoduje, że funkcje startowe są zawsze na początku pliku wynikowego. W swoim skrypcie linkera dodałem polecenia by wszystkie trzy funkcje z "startup_stm32f10x_hd.S" umieszczone były w pamięci tuż za tablicą wektorów. Dzięki temu Reset_Handler() mam zawsze w tym samym miejscu. To rozwiązanie wymyślone na szybko mi pomogło, ale pewnie są na ten problem lepsze rozwiązania.
  • #9
    dexterslab
    Level 13  
    Pojawił się nowy zgrzyt. Mianowicie, program dopóki jest mały (30kB) daje się bezproblemowo debugować. Ale gdy dołączę dodatkowe pliki i kod wzrasta do 90kB, to po wgraniu flash przez oocd 050 zgłaszane jest :

    Error: GDB missing ack(2) - assumed good
    Error: GDB missing ack(2) - assumed good

    a środowisko wyświetla komunikat "'Malformed response to offset query, S05"
    po czym następuje rozłączenie gdb od ocd.

    Sam program działa dobrze, więc coś jest chyba nie tak z konfiguracją debuggera/ocd. Niestety znakomita większość projekcików i przykładów zamyka się w 50kB kodu, więc problem nie jest powszechny i trudno się czegoś doszukać na ten temat.

    Czy ktoś zetknął się z czymś takim? Pytam użytkowników Sourcery G++ Lite 2011.03-42 i Openocd 050

    
    #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    # OpenOCD Configuration File for KT-LINK and LPC1788
    # 2012-03-21
    #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    echo " "
    echo "-- Initialize ports"
    
    # 0 - error 1 - warning 2 - info
    debug_level 0
    
    # Change the default telnet port...
    telnet_port 4444
    # GDB connects here
    gdb_port 3333
    # default tcl port
    tcl_port 6666
    
    echo " "
    echo "-- Initialize JTAG interface"
    
    interface ft2232
    ft2232_device_desc "KT-LINK"
    ft2232_layout ktlink
    ft2232_vid_pid 0x0403 0xBBE2
    
    # create target
    echo " "
    echo "-- Create target"
    
    set _CHIPNAME 	LPC1788
    set _CPUTAPID 	0x4ba00477
    set _TARGETNAME $_CHIPNAME.cpu
    set _CCLK 		4000
    
    # LPC17XX -> SRST and TRST separated
    reset_config trst_and_srst separate
    
    #delays on reset lines
    adapter_nsrst_delay 100
    jtag_ntrst_delay 100
    
    # how long SRST should be asserted
    #adapter_nsrst_assert_width 100
    
    jtag newtap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID
    target create $_TARGETNAME cortex_m3 -chain-position $_TARGETNAME
    
    # LPC1788 has 32kB of SRAM In the ARMv7-M "Code" area (at 0x10000000)
    # and 32K more on AHB, in the ARMv7-M "SRAM" area, (at 0x2007c000).
    $_TARGETNAME configure -work-area-phys 0x10000000 -work-area-size 0x4000 -work-area-backup 0
    
    # LPC1768 has 512kB of flash memory, managed by ROM code (including a
    # boot loader which verifies the flash exception table's checksum).
    # flash bank <name> lpc2000 <base> <size> 0 0 <target#> <variant> <clock> [calc checksum]
    set _FLASHNAME $_CHIPNAME.flash
    flash bank $_FLASHNAME lpc2000 0x0 0x80000 0 0 $_TARGETNAME lpc1700 $_CCLK calc_checksum
    
    #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    # Run with *real slow* clock by default since the
    # boot rom could have been playing with the PLL, so
    # we have no idea what clock the target is running at.
    jtag_khz 100
    
    echo " "
    echo "-- Initialize device..."
    init
    reset halt
    
    # use RCLK adaptive
    #jtag_rclk 1000
    
    #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    echo " "
    echo "-- Waiting for GDB..."
    
    #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    #                       WGRANIE SOFTU
    #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    proc lpc1788_load_soft { } {
        echo " "
        echo "-- Loading image..."
        flash write_image erase dist/Debug/PolarisHP.elf
    }
    
    #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    #                       KONFIGURACJA EVENTÓW
    #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    $_TARGETNAME configure -event reset-init {
    	# Do not remap 0x0000-0x0020 to anything but the flash (i.e. select
    	# "User Flash Mode" where interrupt vectors are _not_ remapped,
    	# and reside in flash instead).
    	#
    	# See Table 612. Memory Mapping Control register (MEMMAP - 0x400F C040) bit description
    	# Bit Symbol Value Description Reset
    	# value
    	# 0 MAP Memory map control. 0
    	# 0 Boot mode. A portion of the Boot ROM is mapped to address 0.
    	# 1 User mode. The on-chip Flash memory is mapped to address 0.
    	# 31:1 - Reserved. The value read from a reserved bit is not defined. NA
    	#
    	# http://ics.nxp.com/support/documents/microcontrollers/?scope=LPC1768&type=user
    
        echo "-- reset-init"
    	mww 0x400FC040 0x01
    }
    
    $_TARGETNAME configure -event reset-start {
        echo "-- reset-start"
    	jtag_khz 100
    }
    
    $_TARGETNAME configure -event gdb-attach {
        echo " "
        echo "-- GDB Connected ---------------------"
    
    	reset init
    	sleep 200
    	jtag_khz 1000
    	lpc1788_load_soft
    	echo " "
    	echo "-- Run "
    }
    
    $_TARGETNAME configure -event gdb-detach {
        echo " "
        echo "-- GDB Disconnected ---------------------"
    }
    
    
  • #10
    Freddie Chopin
    MCUs specialist
    set _CCLK 4000
    W LPC1788 wewnętrzny oscylator ma 12MHz, a nie 4.

    Zrobiłem sobie tutaj program o rozmiarze 48kB (wyłączając optymalizację) i debuggowanie działa normalnie, choć używam nowszego OpenOCD i linaro, a nie CodeSourcery.

    4\/3!!
  • #11
    dexterslab
    Level 13  
    Nie, to nie to.

    Dodam jeszcze że projekt będzie częściowo w C++.
    więc mam plik main.cpp a nie main.c, do linkowania używam g++ a nie gcc, i do tej pory jest ok.

    dołożenie takiej szybkiej klasy:
    Code: cpp
    Log in, to see the code
    i utworzenie zmiennej T_KlasaPochodna w main() to zwiększenie kodu o jakieś 80kB (głównie RTTI) i w tej chwili to już się nie daje debuggować (wspomniane komunikaty)

    Jeśli dodam przełącznik -fno-rtti to kod maleje do < 20kB i debugguje się prawidłowo z czego wnioskuję że konfiguracja toolchaina jest poprawna.
    Coś jest nie tak z openocd albo z gdb... W innym projekcie, już leciwym, używam Yagarto i tam ładuję ~300kB kodu i debuggowanie z openocd 050 działa bez problemu. Ale to inny procek, inny toolchain więc inna konfiguracja :(

    BTW dlaczego przesiadka na inne narzędzie ? Linaro ?
  • #12
    Freddie Chopin
    MCUs specialist
    Nie wiem co tu można poradzić, trzeba experymentować z innymi wersjami i okaże się co się zmieni...

    dexterslab wrote:
    BTW dlaczego przesiadka na inne narzędzie ? Linaro ?

    Bo ma wsparcie dla FPU, jest częściej aktualizowany i nie trzeba wypełniać żadnego formularza żeby to pobrać (;

    4\/3!!
  • #13
    dexterslab
    Level 13  
    Sprawdziłem na innym systemie, z oocd 040 - ten nie tyle zgłasza błędy, co wysypuje się bo "program wykonał niedozwoloną operację"
    Projekt przeniosłem na CodeBlocks bo w tym środowisku kiedyś pisałem i co jak co ale debugowanie działało bez zarzutu. W tym przypadku niestety nic z tego, oprócz komunikatów gdb że ocd wysyła jakieś nierozpoznawalne odpowiedzi nic nie udało mi się osiągnąć.
    Coś jest schrzanione w samym oocd albo brakuje jakiegoś śmiesznego parametru w konfiguracji. Jak tak dalej pójdzie to będe musiał sie pogodzić z Expresso za 512 ojro :/
    Z tym komunikatem "'Malformed response to offset query, S05" jest tak, że kończy się S05 gdy kod ma 130kB, S01 gdy ma 50kB, OK gdy ma 30 i brak gdy jest < 20kB. (wartości orientacyjne)

    Poratuje mnie ktoś konfiguracją sprawdzoną dla projektu mającego przynajmniej 100kB ?
  • #15
    dexterslab
    Level 13  
    Przetestowałem z kompilatorem/debuggerem z LPCXpresso - poza tym że kod trochę większy to wciąż ten sam komunikat. To samo przy oocd 050. Nie mogę skakać po różnych toolchainach - co jeden to inne biblioteki a więc i rozbiegówka i linker. Z Yagarto nie bedę nawet próbował. Dodatkowo komplikuje wszystko fakt że potrzebuję wsparcie dla C++, a skrypt i rozbiegówka z CSLite robią dobrze to co trzeba, czego nie moge powiedzieć o wersji CodeRed gdzie inicjalizacja tablic zawiesza program.

    Z czym jeszcze można eksperymentować w OCD?
  • #16
    Freddie Chopin
    MCUs specialist
    dexterslab wrote:
    Nie mogę skakać po różnych toolchainach - co jeden to inne biblioteki a więc i rozbiegówka i linker.

    Nie wiem o czym piszesz, ale wg mojej wiedzy w każdym z tych toolchainów biblioteki są takie same - newlib.

    dexterslab wrote:
    Dodatkowo komplikuje wszystko fakt że potrzebuję wsparcie dla C++, a skrypt i rozbiegówka z CSLite robią dobrze to co trzeba, czego nie moge powiedzieć o wersji CodeRed gdzie inicjalizacja tablic zawiesza program.

    Ponownie niezbyt wiem o czym mowa - inicjalizacja C++ w każdym z tych toolchainów jest taka sama i w każdym działa... Moje przykładowe projekty odpalisz z C++ na każdym z tych kompilatorów bezproblemowo.

    dexterslab wrote:
    Przetestowałem z kompilatorem/debuggerem z LPCXpresso - poza tym że kod trochę większy to wciąż ten sam komunikat.

    Może najpierw sprawdź, czy nie przetestowałeś z tym samym kompilatorem i debuggerem, bo nikt nie powiedział że w LPCXpresso nie użyli CodeSourcery.
    arm-none-eabi-gdb --version
    w folderze z plikiem.

    4\/3!!
  • #17
    dexterslab
    Level 13  
    Ha, dokładnie ta sama wersja, 7.2.50.20100908-cvs :]
    Dobra, jutro spróbuję Linaro (nie przenieść kod tylko sam debugger podmienić)
    Developerzy zaliczają wtopy które wychodzą u niewielu ludzi.
    Z yagarto miałem kiedyś taki problem że po aktualizacji pakietu program co prawda kompilował się identycznie, tyle że nie działał. Okazało się że coś było w linkerze skopane, podmiana ld na starszą wersję pomogło. Może tu też potrzebny będzie jakiś trik.

    Dodano po 52 [minuty]:

    A powiedz, miałeś do czynienia z innym serwerem GDB?
    Np Link ?

    Może to jest jakieś rozwiązanie, i nie narzuca wyboru środowiska czy kompilatora
  • #18
    Freddie Chopin
    MCUs specialist
    A OpenOCD narzuca? Przecież z OpenOCD możesz korzystać z GDB, z Atollic, z IAR i z każdym programem który pozwala na wykorzystanie GDB servera. Tak samo jak z softem o którym piszesz, tyle że tamten narzuca wybór debuggera w przeciwieństwie do OpenOCD (;

    4\/3!!
  • #19
    dexterslab
    Level 13  
    No nie, ale nie o to mi chodziło. Do tej pory oocd działał zadowalająco, ale trafiła kosa na kamień, a ja nie moge się bawić z tym tydzień próbując wszelkich kombinacji.
    Miałem tylko na myśli, że wybór np. Keila albo IARa to przesiadka na całkiem inny zestaw narzędzi. Problem jest z oocd (albo konfiguracją gdb) więc wymiana na profesjonalny z supportem to jest rozwiązanie, gdy czas nagli. Z tego co patrzylem to w CSP (jak kto nie wie - chip support package) od NXP są dołączone skrypty konfiguracyjne do jlinka właśnie. A skoro tego używają w połączeniu z CSourcery to i u mnie powinno zatrybić.Troche ta zabawka kosztuje, ale i tak jest to malutka sumka w porównaniu z pakietem od keila.
  • #21
    dexterslab
    Level 13  
    Proszę bardzo - przykładzik hardware-independent.
    Niestety bez makefile, ale wystarczy parametry do jakiegoś szablonu przekleić i pójdzie. Albo do eclipsa.
    patrz plik __czytaj__
  • #22
    Freddie Chopin
    MCUs specialist
    No tak średnio hardware-independent skoro korzysta z UARTu, I2C itd... Nie mam takiego procka jak Ty, więc jeśli chcesz żebym sprawdził, to niestety przykład nie może mieć ŻADNYCH spraw sprzętowych, ewentualnie SysTick, bo to w każdym Cortexie takie samo...

    4\/3!!
  • #24
    dexterslab
    Level 13  
    A może by tak zrezygnować z
    $_TARGETNAME configure -event gdb-attach 
    ? Kiedyś obywałem się bez eventów, tyle że trzeba było sesję odpalać od nowa każdorazowo

    Dodano po 2 [godziny] 40 [minuty]:

    HA - pomogło !
    po wyeliminowaniu eventów ze skryptu debug.ocd gdb nie wysypał się i mozna debuggować :D

    Teraz pytanie - gdzie przyczyna? Zła obsługa eventu gdb-attach ?