[AT91SAM7S256]+[openocd]+[oocdlink] problem z jtag

Question

Witam.Próbuję nawiązać kontakt między mikrokontrolerem, a jtgagiem. Mój system: Windows 7 x64. Openocd odpalam z poziomu linii poleceń:openocd -f i...

Freddie Chopin · Accepted Answer

W sprawie Eclipse'a możesz zerknąć też tutaj https://www.elektroda.pl/rtvforum/viewtopic.php?p=8653959#86539594\/3!!

Freddie Chopin · Answer

Jestem na 99% pewny, że w pierwszym (niedziałającym) przypadku odpalasz OpenOCD inaczej niż w tym drugim, bo za pierwszym razem nie ustawia Ci prędkości JTAGa (Info : clock speed 6000 kHz), a za drugim razem już to robi (Info : clock speed 5 kHz). Pozatym w pierwszym przypadku nazwy używane przez OpenOCD (at91sam7s) nie zgadzają się z tymi w pliku który pokazałeś (sam7s256).

4\/3!!

See also:
07.03.2015 [C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++
10.02.2013 bleeding-edge-toolchain - kolejny toolchain dla ARM

klyman · Answer

No tak... to oczywiście moja pomyłka - w między czasie sprawdzałem inne pliki konfiguracyjne i wkleiłem odpowiedź przy innych parametrach.

C:\Windows\system32>openocd -f interface/oocdlink.cfg -f target/sam7s256.cfg
Open On-Chip Debugger 0.4.0 (2010-02-22-19:05)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
5 kHz
srst_only srst_pulls_trst srst_gates_jtag srst_open_drain
Info : clock speed 5 kHz
Info : JTAG tap: sam7s256.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
Info : Embedded ICE version 1
Info : sam7s256.cpu: hardware has 2 breakpoint/watchpoint units
Info : accepting 'telnet' connection from 0

Łącze się przez telnet i daje polecenia:
Open On-Chip Debugger
> init
> reset halt
JTAG tap: sam7s256.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
srst pulls trst - can not reset into halted mode. Issuing halt after reset.
Halt timed out, wake up GDB.
timed out while waiting for target halted
TARGET: sam7s256.cpu - Not halted
Command handler execution failed
in procedure 'reset' called at file "command.c", line 650
called at file "command.c", line 361
>

Kiedy odhashowałem linijkę w sam7s256.cfg:
flash bank at91sam7 0 0 0 0 0
otrzymuję błąd:
C:\Windows\system32>openocd -f interface/oocdlink.cfg -f target/sam7s256.cfg
Open On-Chip Debugger 0.4.0 (2010-02-22-19:05)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
5 kHz
srst_only srst_pulls_trst srst_gates_jtag srst_open_drain
Error: usage: flash bank <name> <driver> <base> <size> <chip_width> <bus_width>
Command handler execution failed

Przy czym dzieje się tak tylko na wersji windowsowej openocd (u znajomego na linuxie nie pokazywało błędu).

Dodam jeszcze, że teraz podłączam inną płytkę z procesorem niż wcześniej, (aczkolwiek teoretycznie jest taka sama).

Freddie Chopin · Answer

Ten plik którego używasz jest "niezbyt" (na niewiele Ci się przyda). Proponuję abyś spróbował odpalić (na razie bez żadnych zmian) OpenOCD na jednym z tych dwóch plików:

c:\Program Files\OpenOCD\0.4.0\target\at91sam7sx.cfg
c:\Program Files\OpenOCD\0.4.0\target\sam7x256.cfg

Do wywołania dodatkowo dostaw:
openocd -f interface/oocdlink.cfg -f target/....cfg -c "jtag_khz 1000"

(w razie problemów poexperymentuj z wartością - powinna być 8x mniejsza niż prędkość rdzenia PO RESECIE).

4\/3!!

See also:
07.03.2015 [C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++
10.02.2013 bleeding-edge-toolchain - kolejny toolchain dla ARM

klyman · Answer

Po dość długiej przerwie mam właśnie okazję znowu coś porobić.

C:\Windows\system32>openocd -f interface/oocdlink.cfg -f target/at91sam7sx.cfg -c "jtag_khz 1000"
Open On-Chip Debugger 0.4.0 (2010-02-22-19:05)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
srst_only srst_pulls_trst srst_gates_jtag srst_open_drain
Warn : use 'at91sam7s.cpu' as target identifier, not '0'
1000 kHz
Info : clock speed 1000 kHz
Info : TAP at91sam7s.cpu does not have IDCODE
Warn : JTAG tap: at91sam7s.cpu UNEXPECTED: 0x00000000 (mfg: 0x000, part: 0x0000, ver: 0x0)
Error: JTAG tap: at91sam7s.cpu expected 1 of 1: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
Warn : Unexpected idcode after end of chain: 1 0x07fd047d
Warn : Unexpected idcode after end of chain: 33 0x00000000
Warn : Unexpected idcode after end of chain: 65 0x00000000
Warn : Unexpected idcode after end of chain: 97 0x00000000
Warn : Unexpected idcode after end of chain: 129 0x00000000
Warn : Unexpected idcode after end of chain: 161 0x00000000
Warn : Unexpected idcode after end of chain: 193 0x00000000
Warn : Unexpected idcode after end of chain: 225 0x00000000
Warn : Unexpected idcode after end of chain: 257 0x00000000
Warn : Unexpected idcode after end of chain: 289 0x00000000
Warn : Unexpected idcode after end of chain: 321 0x00000000
Warn : Unexpected idcode after end of chain: 353 0x00000000
Warn : Unexpected idcode after end of chain: 385 0x00000000
Warn : Unexpected idcode after end of chain: 417 0x00000000
Warn : Unexpected idcode after end of chain: 449 0x00000000
Warn : Unexpected idcode after end of chain: 481 0x00000000
Warn : Unexpected idcode after end of chain: 513 0x00000000
Warn : Unexpected idcode after end of chain: 545 0x00000000
Warn : Unexpected idcode after end of chain: 577 0x00000000
Error: double-check your JTAG setup (interface, speed, missing TAPs, ...)
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Command handler execution failed
Warn : jtag initialization failed; try 'jtag init' again.

Taki wynik dla at91sam7sx.cfg, natomiast dla sam7x256.cfg:
C:\Windows\system32>openocd -f interface/oocdlink.cfg -f target/sam7x256.cfg -c"jtag_khz 1000"
Open On-Chip Debugger 0.4.0 (2010-02-22-19:05)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
srst_only srst_pulls_trst srst_gates_jtag srst_open_drain
1000 kHz
Info : clock speed 1000 kHz
Info : JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
Info : Embedded ICE version 1
Info : sam7x256.cpu: hardware has 2 breakpoint/watchpoint units
Info : accepting 'telnet' connection from 0
Info : JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
Info : Halt timed out, wake up GDB.
Error: timed out while waiting for target halted
TARGET: sam7x256.cpu - Not halted
Command handler execution failed

a to zwrócił telnet:
Open On-Chip Debugger
> init
> reset halt
JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
srst pulls trst - can not reset into halted mode. Issuing halt after reset.
Halt timed out, wake up GDB.
timed out while waiting for target halted
TARGET: sam7x256.cpu - Not halted
Command handler execution failed
in procedure 'reset' called at file "command.c", line 650
called at file "command.c", line 361
>

I teraz rzecz, która zauważyłem - jeżeli zrobię reset halt, to dostaje takie właśnie komunikaty.
Jeżeli po podłączeniu procesora dam samo halt, to otrzymuje:
Open On-Chip Debugger
> halt
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x80000013 pc: 0x00100148
>

czyli w sumie dobrze. Jeżeli teraz dam resume, to powraca do pracy, natomiast jeżeli teraz dam reset i poźniej halt to otrzymuje:
> reset
JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
NOTE! DCC downloads have not been enabled, defaulting to slow memory writes. Type 'help dcc'.
NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'.
> halt
Halt timed out, wake up GDB.
timed out while waiting for target halted
Command handler execution failed
in procedure 'halt' called at file "command.c", line 650
called at file "command.c", line 361

Wgrałem na uC program migający diodami i widzę, że po komendzie reset nie zaczyna migać na nowo - przycisk reset na płytce też nie działa. W takiej sytuacji jak odłączę uC i podłączę na nowo, wszystko wraca do normy. Jednak po każdej próbie wykonania komendy reset, na nowo muszę odłączać i podłączać uC.

Freddie Chopin · Answer

Ok, coś się dzieje [;1. W skrypcie targeta dodaj/zmień:reset_config trst_and_srstMożesz poexperymentować z tą opcją i różnymi ustawieniami:reset_config trst_and_srstreset_config trst_and_srst srst_pulls_trstreset_config srst_only2. W skrypcie zedytuj to:Code: text Expand Select all Copy to clipboard$_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
}Wywal wszystko co dotyczy przestawiania częstotliwości - zakomentuj / wykasuj wszystko poniżej "# CKGR_MOR : enable the main oscillator". Jeśli czujesz się na siłach, to możesz oczywiście wprowadzić tam wartości które będą odpowiadały Twojej płytce.Zamiast "reset halt" spróbuj używać "reset init".3. Na samym końcu skryptu w linijce:flash bank $_FLASHNAME at91sam7 0 0 0 0 $_TARGETNAME 0 0 0 0 0 0 0 18432ostatnia cyfra to częstotliwość zewnętrznego kwarcu (w kHz) - ustaw odpowiednią dla Twojej płytki.4. Możesz też poexperymentować z prędkością JTAGa jtag_khz (szczególnie z baaardzo niskimi wartościami (1 - 10)P.S. łącząc się przez telnet nie musisz wydawać ręcznie komendy "init" - jest ona wykonywana automatycznie gdy OpenOCD skończy mielić pliki konfiguracyjne podane w wywołaniu. Używa się jej tylko wtedy, gdy chcesz w wywołaniu zawrzeć jakieś komendy "akcji", np.:openocd -f ... -f ... -c "init; reset halt; flash write_image erase c:/firmware.hex"4\/3!!

klyman · Answer

Dziwna sprawa...
Zrobiłem jak kazałeś - niestety nie pomogło na problem z resetem. W między czasie spod eclipse odpaliłem gdb (wg opisu z Twojej strony, z tą różnicą, że napisałem:
monitor halt
monitor mww 0xE01FC040 0x0002
load
) i teraz to w ogóle się nie mogę połapać... Zasadniczo pokazało jakiś błąd (a później zawiesił się eclipse). Później odpaliłem plik bez komendy load. W tym momencie, robię wszystko tak jak wcześniej. Włączam openocd i na razie wszystko jest tak jak było.Łącze się przez telnet i nie jestem w stanie nic zrobić, ponieważ jestem "zasypywany" powtarzającymi się linijkami:
Error: ftdi_write_data: usb bulk write failed
Error: couldn't write MPSSE commands to FT2232

EDIT: pospieszyłem się z tym postem - zrestartowałem system i teraz wróciłem do punktu wyjścia:) niestety problem z komendą reset w dalszym ciągu nie rozwiązany...

flapo213 · Answer

Witaj,

Jeśli chcesz aby działał Ci reset hardwarowy na płytyce to niestety musisz go włączyć programowo najpierw inaczej nie będzie śmigało. Spójrz w dokumentację układu odnośnie sekcji hardware reset. Po wykonaniu tych operacji wszystko powinno Ci śmigać jak trzeba

klyman · Answer

Zdaje sobie z tego sprawę. Chodziło mi o coś innego - miałem załadowany program, w którym reset był włączony i wszystko śmigało, tylko po wykonaniu resetu spod openocd, ten hardwarowy przestawał działać.

klyman · Answer

Jeżeli chodzi o sprawę resetu. Częściowo chyba się wyjaśniło. uC, z którym miałem problem AT91SAM7S256. Ostatnio podłączyłem jakąś płytkę testową z uC AT91SAM7S64 i na tych samych plikach konfiguracyjnych (sam7x256.cfg) wydanie komendy reset halt wykonywane było poprawnie. Wnioskuję, że jest jakiś problem z tym uC (S256) - może uszkodzony, albo coś źle podlutowane ?