OpenOCD i programowanie flasha w AT91SAM7X256

Question

Witam,Od dwoch dni walcze z moja nowa zabawka - ARM'em Atmela. Chcialbym sie dowiedziec czy komus udalo sie wgrac program do flasha przy pomocy OpenO...

upanie · Answer

Witam.

Mam AT91SAM7S256 programuję zwyczajnie przez USB.
U mnie debugownie pod OOCD też działa. Programować FLASHa tym chciałem ale nigdzie nie idzie znaleźć opisu jak tego dokonać (może za słabo szukałem kilk miechów temu). Chciałem obczaić z kodu źródłowego ale odpuściłem bo czasu nie miałem. Jest natomiast program na Windows i Linux, który pozwala programować prze JTAG, nie pamiętam nazwy. Wieczorem Ci podrzucę. Jednak mi nie udało się zaprogramować swoich scalaków. Inni ludzie twierdzą, że działa. Fakt, że programowanie przez USB jest niewygodne, ale za to szybkie (t+10s

).
A co do debugowania, to jak uruchamiasz program ponownie?
Zwykła komenda "run" owocuje komunikatem "don't know how tu run", ja niestety ustawiałem PC na 0

Moje informacje na temat OOCD są sprzed 3 miesięcy, może więcej, zatem jak coś z tego co mówię może być nieaktualne.

_Matik_ · Answer

Witam,
Umiem juz programowac flasha przez OpenOCD. Twoje informacje sa dosyc nieaktualne gdyz, z tego co sie zorientowalem, przez 3 miesiace wiele sie zmienilo w tym projekcie. Obecnie mozliwe jest programowanie flasha i bitow NVM koniecznych do odpalenia programu z flasha. Musisz tylko sciagnac najnowsza wersje zrodel z SVN, bo mi wersja kompilowana ze strony USBDIP (openocd-2006re76-setup-rc01.exe) nie dzialala prawidlowo (doszedlem do tego ze tamta wersja programowala flasha ale niestety wgrywala tylko czesc programu, dalej lecialy FF).
Zeby programowac bity NVM nalezy spaczowac zrodla latka z http://developer.berlios.de/patch/?group_id=4148.

Jesli chodzi o debugowanie to narazie moje doswiadczenie jest prawie zerowe, mam rozne problemy z insightem i wogole nie wiem czy to sie bedzie nadawalo do pracy "komercyjnej". Tez mialem problemy z resetem programu, generalnie to debugowanie mi "dziala" przy kazdym wlaczeniu inaczej i czesto idzie w maliny.

Narazie wyjezdzam na wakacje na 2 tygodnie (dzisiaj ostatni dzien mam dostep do ARMa w pracy) wiec sobie odpoczne a moze i OpenOCD wyjdzie przez ten czas bardziej rozbudowany i stabilny

.

upanie · Answer

Jako że za tydzień ruszam z nowym projektem na ARMie to sobie odświerzę OpenOCD.
A tu masz link do programu, o którym wspomniałem w poprzednim poście
http://kjell.e.andersen.googlepages.com/
Kilka osób twierdzi, że im działa. Mi udało się tylko odczytywać to co się nim da ale nie jestem w stanie nic zapisać ani skasować pamięci. Klikam i wg programu wszystko się udało, ale w rzeczywistości nie tknięty jest ani jeden bicik FLASHa.

Powodzenia na wakacjach

upanie · Answer

No i udało się. Zassałem OpenOCD z SVNa skompilowałem i programowanie FLASHa w procku działa. Działa też program, do którego link dałem w powyższym poście. Trzeba było skasować lockbity :oops:

Program ów zapisuje FLAShA 3 !!! razy szybciej niż OpenOCD. Dla binarki 83 KB zapisuje się w 7 sekund a OOCD to samo robi w 22 sekundy. Niestety tego programu nie można (chyba) odpalić w linii poleceń (przydatne dla makefile) ale napisałem autorowi, że przydałoby się. Może kiedyś to wprowadzi w życie.

upanie

_Matik_ · Answer

Witam po przerwie ;].
Ja od poniedzialku znowu walcze z tym opornym srodowiskiem. I mam naprawde dosyc :>.
Opanowalem juz wykorzystanie OpenOCD do zapisu flasha w procku. Narazie pracuje na programach zajmujacych troche ponad 2 kilo kodu (heh

wiec trudno mi okreslic szybkosc zapisu, ale powiedzmy ze to dziala w miare dobrze i nie narzekam.

Trudno mi jednak wyobrazic sobie pisanie powaznego programu bez debugowania w systemie i pracy krokowej.
Uruchomilem wiec srodowisko zlozone z OpenOCD+eclipse, ale tu zaczynaja sie schody. Generalnie dziala to na 3 roznych komputerach i na kazdym inaczej, ale nigdzie nie jest do konca ok (to samo oprogramowanie, troche inny hardware).

No ale spoko, powiedzmy ze prymitywny program migajacy diodami moge zdebugowac i brejkpointy oraz praca krokowa dzialaja dobrze. Niestety programu z prostym przerwaniem od timera zdebugowac juz nie jestem w stanie:
- gdy puszcze program zeby chodzil bez zadnego breakpointa to diody sobie ladnie migaja
- gdy zaloze brejkpointa w programie glownym to widac ze program wchodzi w przerwanie i tez dziala, a potem wraca i zatrzymuje sie na brejkpoincie tak jak powinien
- gdy puszczam program krok po kroku to ladnie debuguje tylko ze nie wchodzi w zadne przerwanie i siedzi w petli glownej udajac ze przerwania nie wystapily
- gdy zaloze brejkpointa w funkcji obslugi przerwania to program wchodzi sypiac kilkoma bledami w konsoli debugera, po kilku krokach idzie w maliny.

W tej sytuacji szukam kogokolwiek kto odpalil debugowanie w eclipse i ma jakies pozytywne wyniki. Caly czas walcze w celu uzyskania darmowego srodowiska nadajacego sie do sensownej pracy.
Chetnie wymienie sie spostrzezeniami, a doswiadczenie juz mam niemale

(trudno nie miec po tylko dupogodzinach;).

upanie · Answer

Nigdy nie używałem Eclips-a to nie wiem, ale co do kosztów środowiska pracy to nie ma to znaczenia dla jego jakości. Na gcc+gdb zawsze i wszyscy narzekają i narzekali (łącznie ze mną) a mimo wszystko i tak większość tego używa. Bo darmowe ktoś zaraz doda. Może i tak ale w mojej firmie przerobiliśmy kilka środowisk, łącznie ze wspominanym, również takich co kosztują po 2k ojro (np. ASHLING+PathFinder). I efekt jest taki, że żadne środowisko nie jest dobre. Każde ma jakiś feler, bądź kilka, które zniechęcają skutecznie do używania go. Np. taki wspaniały Keil, udało nam się zainstalować driver do ULINKa na JEDNYM komputerze z 7 i był nim mój prywatny laptop

Większość środowisk zwracaliśmy bo za taką kasę możnaby chcieć coś działającego. Najczęściej występują jakieś problemy z programowaniem pamięci. Co do debugowania z przerwaniami to PathFinder też chyba nie wchodził w przerwanie w trakcie debugowania. Jak będę miał chwilę czasu to popatrzę sobie na to u mnie.

upanie