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

Nowy JTAG do ARMa na USB - wstęp do projektu

Freddie Chopin 17 Mar 2012 10:15 92829 353
Computer Controls
  • #331
    Freddie Chopin
    MCUs specialist
    To ostatnie akurat może być możliwe - zauważyłem teraz, że używasz dosyć starego OpenOCD (wcześniej komenda nazywała się jtag_khz) - spróbuj z najnowszym, czyli 0.5.0, albo nawet z jakąś wersją deweloperską - do ściągnięcia z mojej strony.

    4\/3!!
  • Computer Controls
  • #332
    dominikrr
    Level 10  
    Hmm... racja mój błąd sprawdzałem komendę ale nie zwróciłem uwagi na wersje
    Na aktualnej nic nie pomogło. Sprawdzę wyższe później i dam znać. A co do Keila ma ktoś jakiś pomysł? Instalowałem tego z płytki od Freddiego, ze strony, jakiegoś archiwalnego. Z pluginem tak samo. Z adminem, bez. I nic z tego. Keil jest ślepy na wtyczkę.
  • Computer Controls
  • #334
    dominikrr
    Level 10  
    Ehhh.... openocd 0.5
    C:\Users\Dominik>openocd -f interface\jtagkey.cfg -f target\at91sam7sx.cfg -c "a
    dapter_khz 500"
    Open On-Chip Debugger 0.5.0 (2011-08-09-23:26)
    Licensed under GNU GPL v2
    For bug reports, read
    http://openocd.berlios.de/doc/doxygen/bugs.html
    Info : only one transport option; autoselect 'jtag'
    srst_only srst_pulls_trst srst_gates_jtag srst_open_drain
    Warn : use 'at91sam7s.cpu' as target identifier, not '0'
    500 kHz
    Info : clock speed 500 kHz
    Error: JTAG scan chain interrogation failed: all ones
    Error: Check JTAG interface, timings, target power, etc.
    Error: Trying to use configured scan chain anyway...
    Error: at91sam7s.cpu: IR capture error; saw 0x0f not 0x01
    Warn : Bypassing JTAG setup events due to errors
    Info : Embedded ICE version 15
    Error: unknown EmbeddedICE version (comms ctrl: 0xffffffff)
    Info : at91sam7s.cpu: hardware has 2 breakpoint/watchpoint units
    Warn : ThumbEE -- incomplete support


    Edit:Wygrałem z jtagiem. Jak? Zainstalowałem jakąś prechistoryczną wersję openocd. Potem dopiero sterowniki, a na koniec podmieniłem pliki na te z ocd 0.5 z płytki Freddiego. Że bez sensu i nie logiczne? Wiem :P Ale działa. Zapewne sterowniki po prostu załapały przy podejściu zbliżonemu numerowi do liczby odcinków Mody na sukces ale... Ważne że śmiga. Dzięki Freddie za pomoc. Ave :P

    Ps:
    Ten błąd dostałem po odpaleniu open ocd wypakowanego i wrzuconego do PATH'a systemowego.
  • #335
    dexterslab
    Level 13  
    Jako że to jest główny wątek dotyczący adapterów JTAG oraz OpenOCD, chciałbym się podzielić rozwiązanym problemem z programowaniem Flash w prockach LPC17XX, który przewija się przez wiele forów i jakoś nikt nic sensownego nie może w tej sprawie doradzić.
    Konfiguracja:
    - CPU LPC1788, płytka EmbeddedArtists OEM PLC1788
    - Jtag KT-Link
    - OpenOCD 0.5.0, wersja od sprawdzonego dostawcy (Freddiego)

    Skrypt (samodzielny, nie trzeba nic dołączać):
    
    #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    # OpenOCD Configuration File for KT-LINK and LPC1788
    # dexlab(at)o2.pl
    #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    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
    
    # 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
    
    $_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
    
    	mww 0x400FC040 0x01
    }
    
    #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    # 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 10
    
    echo " "
    echo "-- Initialize device..."
    init
    reset halt
    
    # Set fast JTAG speed
    jtag_khz 1000
    
    # use RCLK adaptive
    #jtag_rclk 1000
    
    #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    echo " "
    echo "-- Loading image..."
    load_image s_ob_pca9532.hex 0 ihex
    
    
    # verification cannot be done because load_image add checksum to vector table
    
    #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    echo " "
    echo "-- Reset processor"
    reset run
    echo " "
    # stop OpenOCD:
    shutdown
    


    Powyższy skrypt poprawnie wykrywa procesor, ale programowanie flash daje taki efekt:

    
    -- Initialize ports
    debug_level: 0
    
    -- Initialize JTAG interface
    
    -- Create target
    trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
    adapter_nsrst_delay: 100
    jtag_ntrst_delay: 100
    10 kHz
    
    -- Initialize device...
    target state: halted
    target halted due to debug-request, current mode: Thread
    xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
    1000 kHz
    
    -- Loading image...
    Error: JTAG-DP STICKY ERROR
    Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0x4
    Error: JTAG-DP STICKY ERROR
    Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0x4
    Runtime Error: lpc1788-ocd_050-program.ocd:100:
    in procedure 'script'
    at file "embedded:startup.tcl", line 58
    in procedure 'load_image' called at file "lpc1788-ocd_050-program.ocd", line 100
    


    Nie pomaga tu żadna zmiana konfiguracji ani prędkości.

    Rozwiązanie

    Należy zmienić
    
    load_image s_ob_pca9532.hex 0 ihex
    


    na:
    
    flash write_image erase s_ob_pca9532.hex 0 ihex
    


    I teraz programowanie wygląda tak:

    
    -- Initialize ports
    debug_level: 0
    
    -- Initialize JTAG interface
    
    -- Create target
    trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
    adapter_nsrst_delay: 100
    jtag_ntrst_delay: 100
    10 kHz
    
    -- Initialize device...
    target state: halted
    target halted due to debug-request, current mode: Thread
    xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
    1000 kHz
    
    -- Loading image...
    auto erase enabled
    wrote 4096 bytes from file s_ob_pca9532.hex in 0.734375s (5.447 KiB/s)
    
    -- Reset processor
    
    shutdown command invoked
    


    Problem zdaje się występować przede wszystkim w procesorach STM, ale jak widać z mojego przypadku - nie tylko. Coś jest chyba pokrzaczone w OCD :?: albo część skryptu wymaga zmiany.

    Enjoy :D
  • #336
    Freddie Chopin
    MCUs specialist
    Przecież to jest problem z gatunku wydumanych... Komenda której używałeś wcześniej (load_image) _NIE_ służy do programowania pamięci flash tylko do wrzucania danych do pamięci zapisywalnej "normalnie" (czyli RAM), więc czemu się dziwić, że nie działa?

    Pozatym prędkość JTAGa powinna być przynajmniej 6x, a w praktyce ~8x, mniejsza niż prędkość rdzenia, 1MHz na liniach JTAGa przy 4MHz na rdzeniu niezbyt pasuje do tego równania.

    Tak więc wystarczy zastosować istniejące w OpenOCD skrypty (kt-link.cfg oraz lpc1768.cfg), odpowiednią prędkość i właściwe komendy - wtedy wszystko zadziała...

    4\/3!!
  • #337
    dexterslab
    Level 13  
    Chmm, no tak zakręciłem się.
    Sklonowałem skrypt dla LH79xxx który działa z SDRAM zamiast wziąć sprawdzony dla AT91SAM7X512.
    Ustawiona prędkość wiem że nie pasuje, zaczynałem na 100k i chodziło, dałem 1M i też działa. Tyle w temacie.
    Thx
  • #338
    dexterslab
    Level 13  
    Kolejna dziwnostka, mam nadzieję że też 'wydumana' i łatwa do wyeliminowania.
    Sprawa wygląda tak, że program skompilowany i załadowany, break ustawiony powiedzmy na 'main', odpalam debugger i działa.
    I teraz używam w kodzie funkcji z jakiegoś pliku, którego wcześniej nie używałem, kod rośnie o 2kB, data/bss o jakieś 1kB. Tylko że teraz w momencie odpalenia debuggera, po wgraniu obrazu do flash, debugger zgłasza
    Malformed response to offset query, 1, a OpenOCD zgłasza rozłączenie (gdb-detach)

    To jest dziwne dlatego, że w ogóle nie można uruchomić sesji, a więc nie żaden problem z błędnie działającą funkcją. Myślałem że może coś z zajętością pamięci, ale dodałem tablicę statyczna, BSS urósł o 8kB i debugowanie działa. Użycie funkcji uniemożliwia debugowanie. Dodam jeszcze że program używający tej funkcji wgrany normalnie działa poprawnie.

    Pomyślałem o tym czy konfiguracja '-work-area-phys/size' ma znaczenie podczas debugowania? Chyba raczej tylko przy programowaniu flash, bo przecież nie można pakować danych OCD tam gdzie program ich używa...

    Dodano po 37 [minuty]:

    Chm, powodem jest chyba użycie bardziej złożonych funkcji bibliotecznych. Jak użyję w programie fopen() to efekt jest identyczny. Czyli chyba trzeba celować w plik linkera (?)
  • #340
    gaskoin
    Level 38  
    Niby to jtag dla ARM ale i tak zapytam :D

    Czy jest jakaś szansa na wspieranie PICów/dsPICów, programowalnych i np MSP ? Jakieś fresscale avr i inne cuda tam są, więc czemy by nie te ?
  • #342
    gaskoin
    Level 38  
    ach ta komercha.

    Nie ogarniam tych list i nie rozumiem jak można z tego korzystać :P
  • #343
    Jado_one
    Level 22  
    Mnie się udało odpalić OpenOCD i PIC'a32 - w trybie debuggowania, tyle że działa koszmarnie wolno - jeden step trwa 20-30s.
    Jedynie łapanie breakpointów i analiza stanu "po" breakpoincie jest możliwa - to działało jeszcze miarę sensownie.
    Z tego co widziałem na forach, to inni też mieli podobne doświadczenia - tj. koszmarnie wolna praca.
    Nie wiem czy to wina OOCD czy też samego PIC'a....

    Tak przy okazji - jak się wejdzie na stronę OOCD, to wrażenie jest takie, jakby projekt nie był dalej rozwijany....
  • #345
    Jado_one
    Level 22  
    Mam nadzieję :-)
    W sumie, to i tak cud, że znalazło się tylu entuzjastów chętnych do rozwijania tego programu przez tak długi czas.
    No, ale jest to wynik wielkiej potrzeby.

    Tak przy okazji - jak rozumiem, to nadal jest produkt społecznościowy tylko? Tzn. żadna firma produkująca procki/oprogramowanie/etc nie włączyła się do jego rozwoju?
  • #346
    gaskoin
    Level 38  
    Jado_one wrote:
    żadna firma produkująca procki/oprogramowanie/etc nie włączyła się do jego rozwoju?


    W ich interesie bardziej chyba leży to, żeby jak najmniej osób z tego korzystało :)

    Freddie tworzysz coś dla OOCD ? Jak to mniej więcej wygląda ? Dostaje się jakieś zadania od kogoś czy to jest raczej na zasadzie: "aaa dorobię sobie debug po ethernecie" i ciach.
  • #347
    Freddie Chopin
    MCUs specialist
    Jado_one wrote:
    Tak przy okazji - jak rozumiem, to nadal jest produkt społecznościowy tylko? Tzn. żadna firma produkująca procki/oprogramowanie/etc nie włączyła się do jego rozwoju?

    Z tego co widziałem, to pracownicy niektórych firm czasem (rzadko) coś dokładają - obsługę jakichś nowych układów, nowych pamięci flash itd. Poza tym niby ludzie z Amonteca współpracują, ale teraz w sumie już prawie nic.

    gaskoin wrote:
    Freddie tworzysz coś dla OOCD ?

    Ja jestem w stanie ogarnąć prostsze błędy kompilacji i może jakieś skrypty konfiguracyjne [;

    Quote:
    Jak to mniej więcej wygląda ? Dostaje się jakieś zadania od kogoś czy to jest raczej na zasadzie: "aaa dorobię sobie debug po ethernecie" i ciach.

    Raczej to drugie, choć jak coś zrobisz, to jeszcze ktoś to musi zaakceptować. Na liście na pewno jednak znajdziesz info o tym co by się przydało zrobić, jednak nikt nie będzie raczej specjalnie zarządzał ludźmi.

    4\/3!!
  • #348
    ziajek00
    Level 12  
    Jak wygląda sprawa użytkowania Pick-Locka przez SWD? Nigdzie nie ma jakichś sensownych informacji na ten temat, czy są jakieś sprzętowe ograniczenia ew sterowniki ew openOCD?

    Pozdrawiam,
    Tomasz
  • #349
    Freddie Chopin
    MCUs specialist
    JTAG-lock-pick 1.x.x do pracy z SWD wymagałby specjalnej przystawki. JTAG-lock-pick Tiny 2 działa z SWD bez dodatkowych "sprzętów".

    Inną sprawą jest oprogramowanie - w OpenOCD generalnie nie ma możliwości używania SWD, znanym mi programem w którym SWD działa całkiem dobrze jest CrossWorks.

    4\/3!!
  • #350
    Bruum
    Level 23  
    Witam!
    Po latach odkopałem "bohatera wątku" i próbuję go odpalić. Niestety nie chce zbytnio współpracować a openocd wypisuje co następuje:

    
    C:\Documents and Settings\dell>openocd -f interface/jtagkey.cfg -f target/stm32f
    1x.cfg
    Open On-Chip Debugger 0.8.0-dev-00277-g871b34c (2013-12-15-11:29)
    Licensed under GNU GPL v2
    For bug reports, read
            http://openocd.sourceforge.net/doc/doxygen/bugs.html
    Info : only one transport option; autoselect 'jtag'
    adapter speed: 500 kHz
    adapter_nsrst_delay: 100
    jtag_ntrst_delay: 100
    cortex_m reset_config sysresetreq
    Info : clock speed 500 kHz
    Error: JTAG scan chain interrogation failed: all zeroes
    Error: Check JTAG interface, timings, target power, etc.
    Error: Trying to use configured scan chain anyway...
    Error: stm32f1x.cpu: IR capture error; saw 0x00 not 0x01
    Warn : Bypassing JTAG setup events due to errors
    Warn : Invalid ACK 0 in JTAG-DP transaction
    Polling target stm32f1x.cpu failed, GDB will be halted. Polling again in 100ms
    


    Komendy reset, reset halt wywołują reakcje ( impulsy) na liniach sygnałowych natomiast cisza jest na liniach reset-brak reakcji. Jakieś sugestie miałby ktoś może?

    Procek sprawdzony-hjtag na lpt go wykrywa.
    Sprawdziłem z openocd 0.5.0 i niestety to samo-brak sygnałów reset z jtaga.
  • #351
    Freddie Chopin
    MCUs specialist
    Bruum wrote:
    Komendy reset, reset halt wywołują reakcje ( impulsy) na liniach sygnałowych natomiast cisza jest na liniach reset-brak reakcji. Jakieś sugestie miałby ktoś może?

    Tak - do wywołania dopisać:
    -c "reset_config trst_and_srst"

    4\/3!!
  • #352
    Bruum
    Level 23  
    Dzięki!
    Czy nie da się tego dopisać do np. jtagkey.cfg żeby za każdym razem nie pisać i czy ew. taki dopisek w pracy z eclipse nie będzie bruździł?
    Resety są, na liniach wszystkich impusy też a rdzenia nie wykrywa dalej. Znowu muszę spytać o sugestie...
  • #353
    Freddie Chopin
    MCUs specialist
    Bruum wrote:
    Czy nie da się tego dopisać do np. jtagkey.cfg żeby za każdym razem nie pisać i czy ew. taki dopisek w pracy z eclipse nie będzie bruździł?

    Jeśli dopiszesz to do pliku konfiguracyjnego, to zawsze będziesz miał resety sprzętowe, a one nie zawsze są potrzebne i nie zawsze są dostępne.

    Bruum wrote:
    Znowu muszę spytać o sugestie...

    Do JTAGa na pewno dochodzi prawidłowe zasilanie (czy diodka koło złącza JTAG się świeci)? Czy kiedyś już działał? Bo może to jakiś zimny lut lub zwarcie? Albo problem z przewodem? Tego typu błąd zwykle wskazuje na problem sprzętowo-połączeniowy - np niezasilony układ, niezasilone bufory w JTAGu, zwracia, brak połączenia, ...

    4\/3!!
  • #354
    Bruum
    Level 23  
    Zasilany jest, diodka D_JVCC świeci-zasilanie z płytki z targetem, świeci D_USB, i D_UART. Po dopisaniu "linijki" od Ciebie zaczęła się w momencie resetu pokazywać D_SRST. Czy kiedyś działał? Nie-odkopałem go po latach od zmontowania i próbuję odpalić "łańcuszek" cały-eclipse i Twój "nowy" toolchain skompilowły przykład z diodką, warto by to wrzucić do procka.
    Co charakterystycznego można zmierzyć, podejżeć, żeby poszukać uszkodzenia? Które sygnały na ftdi np. byś sprawdzał?

    Hurra! Poszło-zwróciłeś uwagę na kwestie sprzętowe-oscyloskop i dwa sygnały z u6 do ftdi-brak jednego, poprawka i hula.
    Teraz zgrywanie z resztą łańcuszka, ale to chyba inna bajka/wątek.
    Dzięki.