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.
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ę.
Zbyt wiele osób jeszcze nie próbowało pewnie walczyć z tą wtyczką, to jest swego rodzaju "nowość", a u mnie właśnie poszło bez najmniejszych problemów /;
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 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
Ps:
Ten błąd dostałem po odpaleniu open ocd wypakowanego i wrzuconego do PATH'a systemowego.
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)
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# 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...
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.
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...
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
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 (?)
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....
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?
ż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.
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.
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?
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.
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.
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"
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...
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, ...
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.