Jak to zwykle bywa są też problemy z debugerem, ale nie jest to aż takie tragiczne jak się wydaje
tak więc będziemy kontynuować to zagadnienie gdyż temat jest ciekawy, ale może wprowadzić pewnego
rodzaju frustracje że coś jest nie tak , wiesza się lub nie działa dobrze:)

Na początek parę ostrzeżeń i uwag jeśli chodzi o użytkowanie debugera w eclipse:

#RESTART

Służy do tego celu mały przycisk na pasku narzędzi, który wygląda tak
Jest ładny i poręczny , ale UWAGA !! nie działa on z avr-gdb.
Wciśnięcie go spowoduje zakończenie sesji debugera z komunikatem o błędzie.
Spowodowane jest to że w tle Eclipse wysyła "-exec-run" do avr-gdb, a w efekcie tego avrdude
"zabija" gdbserwer i pokazuje komunikat o błedzie "Don't know how to run."

oczywiście ten problem jak i większość można obejść ponieważ kolejna przewaga Eclipse nad innymi środowiskami jest jego niesamowita wręcz elastyczność. Oto jak to można zrobić:

Musimy wykonać miękki reset (Soft reset), w tym celu ustawiamy punkt przerwania (breakpoint)
w np. main() lub innej funkcji, w której chcemy zatrzymać wykonywanie operacji na rejestrach widocznych
w PC który musimy ustawić na 0. (PC= Program Counter).
Teraz wykonać musimy wznowienie programu "RESUME"
cała ta operacja spowoduje że procesor wznowi wykonywanie programu pod adresem 0x0000, jest to miejsce wektora RESETU dla wszystkich procesorów AVR bez wyjątku.
Nie jest to jednak RESET taki jak byśmy chcieli gdyż musimy pamiętać żeby wejść i wyjść z kontroli rejestrów
bo inaczej pozostaną one na poprzednim stanie.

# Breakpointy i watchpointy w Avarice

Tu trzeba pamiętać, że procesory AVR w trybie JTAG maja tylko BACZNOŚĆ !! 3 dostępne pułapki sprzetowe,
z których dwie mogą być zamieniane na "watchpointy" pamięci.
W trybie debugWIRE nie są obsługiwane sprzętowe breakpointy i watchpointy przez AVR:(

AVaRICE ma na szczęście możliwość z korzystania z tak zwanych miękkich punktów przerwania (soft breakpoints), są to specjalne instrukcje zapisane w pamięci flash pod wymaganym adresem przerwania.
Gdy program natrafi na taki punkt zostaje zapisana oryginalna zawartość strony we flash ponownie.
Czyli każdy SBP powoduje co najmniej 2 cykle zapisu pamięci flash. Co ciekawe pomimo tego że w AVR ilość
cykli zapisu do pamięci flash jest zwykle sporo większa od gwarantowanych przez producenta 1.000 cykli (dla starszych procków) należy o tym jednak pamiętać podczas pracy z debugerem i wieloma punktami SBP.

Soft watchpoints w SRAM są również obsługiwane przez AVaRICE, ale (no tak zaś mam jakieś ) znacząco spowalniają działanie debugera ponieważ nasze drogie AVaRICE musi wykonywać każdą instrukcje w
pojedynczych krokach i sprawdzić po wykonaniu pamięć SRAM. Dlatego trzeba pamiętać, że oglądanie 16-bitowych wartości np: wskaźnika, wykorzystuje 2 watchpointy, po jednym dla każdego bajta.
dlatego myślę że taki mój mały pomysł aby oglądać tylko 1 bajt 16 bitowej wartości - wykorzysta nam tylko jeden watchpoint i na tym 1 bajcie oglądać zmiany.


# Kilka słów o architekturze AVR --> na tym etapie to konieczne

Jak wiecie procesory AVR maja architekturę Harvardzką co oznacza w uproszczeniu oddzielny kod i przestrzenie adresowe.
Aby odróżnić adres danych 0(SRAM) od adresu kodu 0(FLASH) debuger dodaje 0x800000 do wszystkich adresów danych.
Miejcie to na UWADZE przy rozpatrywaniu wskaźników pamięci FLASH (np wskaźniki łańcuchów).
Na domiar tego jeszcze bardziej skomplikowana jest w AVR przestrzeń kodowa 16-bitowego słowa i przestrzeni danych 8-bitowych.
Ale na szczęście avr-gdb używa tylko 1 bajtowych adresów więc wszystkie adresy w przestrzeni kodu pokazane przez debuger należy podzielić
przez 2, aby uzyskać faktyczny adres używany przez procesor.


#PRZYKŁAD

Mamy zrzut pamięci pod adresem 0x0000 (wektor reset) , widzimy adres <0C 94 6D 00>. W składni AVR <0C 94>
jest to kod dla skoku <tjmp> i <6D 00> co zawiera zakodowany adres skoku. Jeśli zdeasemblujemy część
z avr-gdb wyjdzie nam <tjmp 0xDa> = skok do adresu 0x00da, jeśli wiec wykonamy ten skok w debugerze to w avr-gdb bajtowy adres będzie
0x00da (binarnie 11011010). Jeśli tą wartość podzielimy przez 2 otrzymamy
0x006d (binarnie 01101101) i ten właśnie adres widzi procesor

Mam nadzieje że ten opis jest dla was przejrzysty tak to widzi avr-gdb i jest to zgodne z jego adresacją.
Wiem że może to być początkowo problemem jeśli w deasemblacji będziecie robić porównanie adresów do zrzutu pamięci ,
i może być mylące , ale trzeba się tego nauczyć i przyzwyczaić inaczej praca z Debugerem
niema najmniejszego sensu.

Należy również pamiętać, że pierwsza część przestrzeni adresowej danych jest używana do przechowywania
map rejestrów CPU i I/O oraz do kontroli rejestrów. Natomiast rzeczywista pamieć SRAM zaczyna się za
rejestrami I/O i wielkość bloków rejestrów I/O zależy od modelu procesora.

--------------------------------------------------------------------------------------------------------------
Tak wprowadziłem trochę zamętu i zamieszania , wielu się przerazi zapewne
i zapomni o debugowaniu:) , ale wierzcie mi bez tej wiedzy to od razu lepiej
sprzedajcie JTAGI bo to tak jakby dać zegarek komuś , kto nie umie go nakręcić
Ale to nie koniec straszenia
---------------------------------------------------------------------------------------------------------------


#Rozwiązywanie problemów z debugerem

Jeśli masz problemy z debugerem w Eclipse to tu zamieszczę kilka porad jak sobie z tym poradzić
i uruchomić aplikacje debugera.

Pierwszy przełacznik w konsoli "verbose" na na stronie z konfiguracji debugera można równie dobrze sobie włączyć debugowanie na
wyjściu serwera GDB. Wystarczy dodać kilka odpowiednich argumentów do wiersza poleceń :

--- dla AVaRICE: "-D" lub "-debug"
--- dla simulAVR: "G" lub "-gdb-debug"

I następnie można rozpocząć debugowanie.
poniżej przykładowa lista wejść avr-gdb dla prawidłowej sesji debugera:

Krótka instrukcja jak to czytać

Wszystko co zaczyna się nowym numerem sekwencji jest komenda wysyłaną przez Debuger Eclipse
do avr-gdb.

Wszystko co sie zaczyna od litery lub '^', '&', '~' i '*' jest odpowiedzią generowana przez avr-gdb.

Wszystko inne to śmieci (non-verbose) z wyjścia avr-gdb , który jest dosyć gadatliwy



Od początku sesji do momentu trafienia na przerwanie (breakpoint) w funkcji main ()



Pojedynczy krok "Step over 'w źródle C



Otwarcie widoku Deasemblacji



Ustawienie nowego Breakpointa



Uruchomienie programu do następnego Breakpointa



>>> Analiza wyjścia debugera avr-gdb.

Należy o tym pamiętać bo jest to bardzo ważne !!!

-->> wszystkie 3 zaangażowane części (eclipse, avr-gdb i gdbserver) należy zawsze uruchamiać asynchronicznie, a
-->> avr-gdb będzie chętnie nadal działał nawet jeśli gdbserwer się zawiesił

ważne zatem jest, aby przewinąć sobie wyjście avr-gdb trochę do góry, aby znaleźć prawdziwą przyczynę
awarii. Koniec dziennika zwykle NIE jest przyczyną problemu:)

Jeśli nie jesteście zaznajomieni z poleceniami gdb to warto poszukać instrukcji do GDB zwłaszcza rozdziału o interfejsie GDB/Mi.

O to kilka fragmentów wyjścia z avr-gdb z typowymi problemami:

--->>Could not connect...



Ten komunikat jest wyświetlany, gdy avr-gdb nie może połączyć się z gdbserver. Sprawdź, gdbserver (AVarice lub simulavr)
czy jest uruchomiony i że numery portów są takie same. Zauważ, że nawet z tym błedem Eclipse i avr-gdb będzie
kontynuować sesję debugowania. ale otrzymasz wiadomość że "program nie jest uruchomiony":)

--->>Don't know how to run



No przecież pisałem żeby nie naciskać tego przycisku:

No błędów różnych może się nam pojawić wiele , a ja nie jestem w stanie wszystkich opisać
jak będą jakieś nie wymienione piszcie , postaram się pomóc ich pozbyć jak też im zaradzić i wyjaśnić czego dotyczą.

miłej lektury

_________________
[b]San Escobar! Patria mia! Tu eres como la salud.[/b]

U mnie dzieje się tak że pomimo ustawienia breakpointa to nie zatrzymuje się tylko wywala mi błąd że w danym pliku niema lini z breakpointem.

Oto log:



a po zapauzowaniu programu wszystko ładnie się zatrzymuje i pokazuje gdzie itd. Ale z tym breakpointem się nadal pluje

log:


To wygląda jakby coś się pogubiło ze ścieżkami...
taki błąd: No line 35 in file \"../main.c\"." ... a tam jest właśnie breakpoint.

hmmm...

jaki masz debuger ??

_________________
[b]San Escobar! Patria mia! Tu eres como la salud.[/b]

Jeśli chodzi hardware to jest to AVR JTAGICE Compatible, zgodny z mkI.

Problem coś jest z kompilacją bo tak jakby gdzieś brakowało tego odniesienia i samej pułapki w skompilowanym kodzie.

Podam screeny z konfiguracją:

AvaRice



Debug Configuration




Programator działa, bo jak uruchomię w trybie debugera program, to wszystko ładnie działa, można pauze zrobić podejrzeć rejestry i wznowić działanie. Pokazuje normalnie w której procedurze zatrzymałem itd. no i mogę krokowo wykonać program tzn po jednej lini.
Tylko coś z tymi pułapkami nieten teges.



ps. tak na marginesie, pytanie do Sunduino czy Eclipse już masz gotowy skonfigurowany? bo wspominałeś że kiedyś to masz zamiar sklecić.

config widzę masz ok , oczywiście kompilacje robisz w trybie debug ??
przeczytaj jeszcze raz o ograniczeniach w breakpointach.

Jest gotowe clipse dla sunduino , dałem do testów , także wejdz w temat i przetestuj , bo mogą jeszcze być jakieś problemy

_________________
[b]San Escobar! Patria mia! Tu eres como la salud.[/b]

Ojj coś Eclipse u mnie nie działa jak chcę jeśli chodzi o debugera. Próbowałem instalować Te wersje z dropboxa, ale pojawiały się jakieś błędy kosmosy. Kombinowałem całą niedzielę.

A co najlepsze wziąłem AVR Studio i sprawdziłem czy niema czasem problemu z tymi breakpointami tam, okazało się że bez żadnych problemów debugował - reagował na breakpointy itd.

Łapki opadają.

Xbary: nikt nie mówił że będzie łatwo ... konfig dla Dragona działa bez problemów podobnie dla JTAGICE II ATMELA
na temat klonów się nie wypowiadam ... bo jedne lepsze inne gorsze , miałem 2 klony różne JTAG ICE i poza
programowaniem żaden nie działał prawidłowo w trybie debug na AS4 - kupiłem oryginał i skończyły się problemy

Nie wiem co zaś jest z tym u was. Paczki na dropie są te same których używam na co dzień, po prostu spakowałem i dałem na dropa - może czas zrobić format i system od bablolić ??

_________________
[b]San Escobar! Patria mia! Tu eres como la salud.[/b]

hmm... dziś tak na świeżo pomyślałem że prawdopodobnie te narzędzia od debugowania GDB itd mogą działać na nakładce cygwin a część programów w normalnie pod windows i to się kłóci. Tak jak wczesniej wspominałem o tym numerze portu że inaczej po unixowemu trzeba wpisać to może dalej coś nie tak jest ze ścieżkami i się gubi i nie wstawia breakpointów.
Zaznaczam że mój programator klon itd współpracuje z AS 4.18 reaguje na breakpointy - czyli to nie wina samego programatora, tylko na etapie kompilacji w eclipse czegoś nie kompiluje jak powinien itd... przerosło mnie to dosłownie:) kilka dobrych dni nad tym siedzę.
Dziś znowu coś sprawdzę, odinstaluje wszystkie programy które u mnie mam na kompie które na cygwin działają, albo mingwin i na czysto eclipse rozpakuje i zobaczę jak działa. Bo na jednym eclipse Jungo udało mi sie doprowadzić że program się zatrzymał podczas debugowania na początku funkcji main tak jak miałem zaznaczone w konfiguracji, ale to już była prawie noc 12 godzin przed kompem i coś podusiłem sam nie wiem co, i w ogóle przestał się kompilować program wyrzucał błędy.

Jeszcze raz przeczytaj wyżej o problemach z gdb-serwerem , pobierz nowsze avariace bo ten z winavr trochę stary
i zobacz w pierwszej części na ustawienia linkera

nie mam żadnego klona żeby to sprawdzić , ale ze starym moim klonem na RS232 działa prawidłowo

_________________
[b]San Escobar! Patria mia! Tu eres como la salud.[/b]

No i zmusiłem Eclipse do breakpointowania pewnie się uśmiacie, ale zbyt dużo ustawień jak na jedno podejście chyba.

Teraz tak, powodem że niby debugował a nie chciał reagować na breakpointy było to że do mikrokontrolera nie został uploadowany (chyba powinien automatycznie) skompilowany kod .hex w ustawieniach z ustawieniami debugerowymi. Co musiałem kliknąć:

- Z menu w perspektywie debug lub po wybraniu konfiguracji debug w project/properties następnie C/C++ Build/Settings w zakładce ToolSettings i pierwsza pozycja Aditional Tools in Toolchain należało zaznaczyć opcje generate Hex flash i eeprom. Chodzi o to żeby skompilować projekt do pliku Hex w konfiguracji debug.
- Następnie tak skompilowany hex z katalogu Debug trzeba uploadować avrdudem do mikrokontrolera
- Kolejnym krokiem jest już przejście w perspektywe Debug i uruchomienie AVarice i następnie debugera, dopiero reaguje na breakpoint ehh.

Oczywiście przed tym zabiegiem tzn kolejnymi próbami zrobiłem wylot z systemu wszystkich programów opartych na cygwin oraz czyszczenie ccleanerem pozostałości po konfiguracji i martwe Path, dopiero zainstalowałem po tym zabiegu WinAVR-20100110 tak jak sugerował instaler.
Eclipse mam z chomika wersja Genymade spakowane częściowo uszykowane pod AVR ale z pomocą tego forum (tzn Was) doklikałem ustawienia tu i tam i jak narazie na próbach śmiga.

Odnośnie Avarice nowego ściągniętego ze oficjalnej strony projektowej, ściągłem i chyc skopiowałem do odpowiedniego katalogu gdzie stary był. I jest zonk bo niechce działać, potrzebuje jakiejś nowszej wersji biblioteki cygwin1.dll i sztopa. Nawet ściągnięcie najnowszego Cygwin nic nie dał, bo kopiowałem kolejno biblioteki które wołał aż zatrzymałem się na cygusb*.* i za chiny niemogłem znaleźć tej biblioteki.
Pozostałem przy starym/oryginalnym z WinAvr.

Czyli jednak twój klon nie działa , prawidłowo bo wymaga uploadu via avrdude , ale to zaden problem , a pytałem czy komplacje robisz dla DEBUG

------------------------ [ Dodano po: kilkunastu sekundach ]

Po powrocie zapodam na dropa działajace nowe avriace

_________________
[b]San Escobar! Patria mia! Tu eres como la salud.[/b]

Z tą kompilacją to coś kompilował bo na dole widziałem że było podsumowanie wielkości flash itd, ale nie uploadował go.

Co jak co, to Avrdude programuje tym programatorem jako mkI i działa. Problem jest coś z jakimś ustawieniem które nie działa jak jestem w trybie widoku debug które odpoweidzialne jest za upload do uC. Tak jakby plik .elf miał być kompletnym flash do uploadowania ale żadne z ustawień nie chce nim zaproramować uC, tylko .hex nadaje się do programowania. Dlatego muszę kompilować i uploadować z dodatkami debugera a nastepnie w widoku Debug uruchomić debugowanie.


To wracaj spokojnie Sunduino, ciekawe czy ten nowy od ciebie avarice zadziała u mnie na (prawie) Wartą:)

No właśnie bo twój klon nie pozwala na symulację szprzętowa tylko programową i dlatego chcąc debugowac na sprzecie musisz zadbac o wgranie wsadu w postaci hex bo elfa nie załaduje jako ICE

Tu ci powiem TAK:
Diała u mnie na 4 debugerach:

AVR DRAGON
AVR ONE
AVR ICE MKII
i na moim starym klonie AVRICE mki RS232

_________________
[b]San Escobar! Patria mia! Tu eres como la salud.[/b]