[AT91SAM7S64]+[openocd]+[jtag] i błędy programowania

Szanowni forumowicze,

Próbuję swoich sił z ARM, na początek chciałem zaprogramować układ gotowym programem ... Wydaje mi się, że wszystko zrobiłem zgodnie ze sztuką opisaną w instrukcjach dostępnych w internecie ale nijak nie mogę wgrać programu. Zastosowałem chyba wszystkie możliwości, które znalazłem w sieci ... bez rezultatu. Próbowałem różnych zmian w "at91sam7sx.cfg" ale z tym samym marnym wynikiem.

>Procesor AT91SAM7S64
>f=16MHz
>WIN 10
>openocd 0.10.0
>JTAG-lock-pick Tiny 2.0.0
i zrzut z procesu wygląda jak niżej - będę wdzięczny za wszelkie sugestie

Pozdrawiam,
Adaś
----------------------------
d:\openocd\bin-x64\openocd.exe -f d:/openocd/scripts/interface/ftdi/jtag-lock-pick_tiny_2.cfg -f d:/openocd/scripts/target/at91sam7sx.cfg -c "adapter_khz 2000; reset_config trst_and_srst; init; reset init; flash write_image erase d:/2941/main.elf; reset run; shutdown;"
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
srst_only srst_pulls_trst srst_gates_jtag srst_open_drain connect_deassert_srst
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
adapter speed: 2000 kHz
trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : clock speed 2000 kHz
Info : JTAG tap: at91sam7s.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787 (<unknown>), part: 0xf0f0, ver: 0x3)
Info : Embedded ICE version 1
Info : at91sam7s.cpu: hardware has 2 breakpoint/watchpoint units
Info : JTAG tap: at91sam7s.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787 (<unknown>), part: 0xf0f0, ver: 0x3)
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0xf00000d3 pc: 0x0001e164
Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
requesting target halt and executing a soft reset
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0xf00000d3 pc: 0x00000000
Warn : NOTE! DCC downloads have not been enabled, defaulting to slow memory writes. Type 'help dcc'.
Warn : NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'.
auto erase enabled
Warn : no flash bank found for address 0
Warn : no flash bank found for address 6ec4
wrote 0 bytes from file d:/2941/main.elf in 0.031250s (0.000 KiB/s)
Info : JTAG tap: at91sam7s.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787 (<unknown>), part: 0xf0f0, ver: 0x3)
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0xf00000d3 pc: 0x0001e690
Warn : NOTE! DCC downloads have not been enabled, defaulting to slow memory writes. Type 'help dcc'.
Warn : NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'.
shutdown command invoked

Na szybko obstawiam, że problemem może być zupełnie gdzie indziej. Otóż REALNY adres pamięci flash w mikrokontrolerze AT91SAM7S64 to nie 0, a 0x00100000 (http://www.keil.com/dd/docs/datashts/atmel/at91sam7s64_ds.pdf - strona 14). OpenOCD zapewne właśnie dlatego zgłasza następującą uwagę:

Warn : no flash bank found for address 0
Warn : no flash bank found for address 6ec4

Rozwiązania są zapewne co najmniej dwa:
1. Prawidłowe i uniwersalne - zmienić sposób kompilacji programu, tak aby był linkowany nie od adresu 0, tylko od adresu 0x00100000. W przypadku używania toolchaina opartego o gcc + ld wystarczy zmienić jedną liczbę w skrypcie linkera - adres początku pamięci flash.
2. Szybkie i niezbyt praktyczne na dłuższą metę - podczas programowania dodać odpowiedni offset. Wystarczy zapewne zmienić `flash write_image erase d:/2941/main.elf` na `flash write_image erase d:/2941/main.elf 0x00100000`, choć nie jestem 100% pewny czy offset zadziała z plikiem elf. Jeśli OpenOCD będzie protestował, to trzeba użyć pliku bin, ale tu oczywiście najpierw trzeba go mieć, a niekoniecznie aktualny system kompilacji projektu go generuje (; Wygenerowanie go jest proste, jeśli będzie go brakować to pisz.

Na szybko tyle. Daj znać jaki jest efekt.

Dziękuję za szybki odzew.
@ Freddie Chopin > na szybko (bo na razie bez środowiska) popełniłem wg propozycji (2) -skutki poniżej. Widzę, że jednak na szybko to tylko jak w przysłowiu ... Jutro będę próbował wg propozycji (1) ale muszę w pierwszej kolejności trochę przygotować otoczenie.

@stmx > po prostu chciałem "tylko" gotowy plik zapisać; a sam projekt jest przyrządem generatora/wobulatora na potrzeby strojenia "radyjka" na KF (Husarek).

Pozdrawiam,
Adaś

----------
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
srst_only srst_pulls_trst srst_gates_jtag srst_open_drain connect_deassert_srst
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
adapter speed: 2000 kHz
trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : clock speed 2000 kHz
Info : JTAG tap: at91sam7s.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787 (<unknown>), part: 0xf0f0, ver: 0x3)
Info : Embedded ICE version 1
Info : at91sam7s.cpu: hardware has 2 breakpoint/watchpoint units
Info : JTAG tap: at91sam7s.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787 (<unknown>), part: 0xf0f0, ver: 0x3)
Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0xf00000d3 pc: 0x0007c548
requesting target halt and executing a soft reset
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0xf00000d3 pc: 0x00000000
Warn : NOTE! DCC downloads have not been enabled, defaulting to slow memory writes. Type 'help dcc'.
Warn : NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'.
auto erase enabled
wrote 28672 bytes from file d:/2941/main.bin in 7.171856s (3.904 KiB/s)
Info : JTAG tap: at91sam7s.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787 (<unknown>), part: 0xf0f0, ver: 0x3)
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0xf00000d3 pc: 0x000a0f34
Warn : NOTE! DCC downloads have not been enabled, defaulting to slow memory writes. Type 'help dcc'.
Warn : NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'.
shutdown command invoked

damkar napisał:

@ Freddie Chopin > na szybko (bo na razie bez środowiska) popełniłem wg propozycji (2) -skutki poniżej. Widzę, że jednak na szybko to tylko jak w przysłowiu ...

No ale czekaj. Przecież się wgrało prawidłowo.

Cytat:

Przecież się wgrało prawidłowo.

Moje obawy budzą wpisy Warning oraz ten:

szczególnie w końcowej frazie (<unknown>). Nie za bardzo lubię jak dzieje się coś czego za bardzo nie rozumiem. Dlatego chcę trochę więcej dowiedzieć.

Cytat:

A to na Twój procesor?

Tak, AT91SAM7 jest sterownikiem generatora. Sam Husarek na Xmega.

Pozdrawiam,
Adaś

damkar napisał:

Moje obawy budzą wpisy Warning oraz ten:

Spokojnie (;

damkar napisał:

Info : JTAG tap: at91sam7s.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787 (<unknown>), part: 0xf0f0, ver: 0x3)

<unknown> tutaj znaczy tylko tyle, że OpenOCD nie wie jak przyporządkować 0x787 do jakiegoś producenta, co znaczy ni mniej, ni więcej tyle, że komuś się (jeszcze) nie chciało uzupełnić listy o taką wartość. Gdyby OpenOCD nie był się w stanie połączyć z układem, to nawet by nie odczytał tego identyfikatora, a gdyby identyfikator był "nieoczekiwany", to OpenOCD też dałby Ci o tym wyraźne ostrzeżenie w formie "oczekiwałem X, znalazłem Y".

damkar napisał:

Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.

W pewnych układach ARM7 wewnętrznie w układzie jest zrobione tak, że reset układu (SRST) powoduje też reset podsystemu od debuggowania (normalnie resetowanego przez TRST). Zachowanie takie jest czasem problematyczne (np. z powodu opisanego w warningu który widzisz), niemniej jednak zwykle jest jedynie drobną niedogodnością której trzeba być świadomym. Tak naprawdę tym co jest bardziej problematyczne w tej kwestii jest:

damkar napisał:

requesting target halt and executing a soft reset

Pod magicznym kryptonimem "soft reset" może się kryć wiele rzeczy, niemniej jednak zwykle kryje się bardzo ambitne przestawienie licznika PC na początek reset handlera, BEZ RESETU UKŁADÓW PERYFERYJNYCH. Sprawia to czasem (często?) całkiem sporo problemów, jeśli kod który wykonuje się na początku działania układu (np. ustawienie zegara systemowego itd.) jest napisany z bardzo wieloma założeniami dotyczącymi tego, że wykonywany jest tylko raz, zaraz po prawdziwym resecie. Jeśli np. dany układ zabrania przestawiania rejestrów związanych z PLL gdy owy PLL jest włączony i używany, problematyczna sekwencja może wyglądać tak:
1. OpenOCD resetuje układ;
2. Układ od razu po resecie od razu zaczyna działać;
3. Układ sobie ustawia PLL i przestawia rdzeń na ten zegar;
4. OpenOCD zatrzymuje rdzeń;
5. OpenOCD wykonuje "soft reset";
6. Układ - pracujący z PLL - ponownie ustawia PLL, co powoduje np. zatrzymanie tego zegara, układ się wysypuje, rzuca setką błędów, nic nie działa a user na ustach ma tylko WTF;

Zwykle jednak nie jest tak źle (w końcu - jak widzisz - u Ciebie nie ma tego problemu i wydaje się działać), jednak trzeba być tego świadomym. Generalnie na dzień dzisiejszy rdzeń ARM7 (np. układ którym dysponujesz) to taka trochę ciekawostka historyczna, Cortex-M zdominował rynek mikrokontrolerów całkowicie, a tam tego typu problem występuje niezmiennie rzadko (choć też się trafia).

damkar napisał:

Warn : NOTE! DCC downloads have not been enabled, defaulting to slow memory writes. Type 'help dcc'.
Warn : NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'.

Mało istotna sprawa. "DCC downloads" to trochę inny algorytm ładowania softu do zaprogramowania, który generalnie jest znacząco szybszy. Domyślnie nie jest włączony, ale czemu dokładnie to nawet nie wiem - możliwe że nie każdy układ to obsługuje lub ma jakieś dodatkowe wymagania (np. pewne obszary RAMu trzeba wyłączyć z użycia przez aplikację), nie wiem. W każdym razie jeśli tylko Twoje programowanie nie trwa tak długo że zaczyna Cię irytować (powiedzmy krócej niż jakieś 10-15 sekund), to naprawdę nie ma się czym przejmować. OpenOCD używane jest też do procesorów aplikacyjnych, a nie tylko dla mikrokontrolerów. W przypadku MCU firmware w większości przypadków nie ma nawet 100 kB, takie większe niż megabajt to zapewne ułamek procenta, jednak dla procesora aplikacyjnego spokojnie może to być kilka, kilkadziesiąt albo i kilkaset megabajtów i wtedy już ma znaczenie czy całość ładuje się minutę czy pół godziny. Jak poszperasz w manualu do OpenOCD to znajdzesz info o tym jak włączyć DCC i co jest do niego wymagane, ale osobiście zignorowałbym to do momentu aż czas ładowania aplikacji nie zacznie Ci faktycznie przeszkadzać.

Wg mnie całość działa OK i załadowała się prawidłowo. Dla 100% pewności możesz jeszcze dorzucić na koniec komendę powodującą weryfikacje tego co zostało zapisane. Najprościej dokonać tego zmieniając komendę `flash write_image ...` na nowe `program filename [verify] [reset] [exit] [offset]`.

http://openocd.org/doc-release/html/Flash-Commands.html#flashprogrammingcommands

Dziękuję za wyczerpujące odpowiedzi i podpowiedzi -jestem pod wrażeniem wyczerpujących wyjaśnień.

Freddie Chopin napisał:

"DCC downloads" to trochę inny algorytm ładowania softu do zaprogramowania, który generalnie jest znacząco szybszy.

Na tę chwilę to kilka a nawet kilkanaście sekund nie jest dla mnie żadnym problemem. Pewnie z czasem i to bardziej z ciekawości niż potrzeby spróbuję tej opcji.

Pozdrawiam,
Adaś