logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Czy AVR Dragon umożliwia podgląd pamięci i śledzenie zmian zmiennych?

Sh44dow 27 Wrz 2012 11:53 2013 9
  • #1 11352981
    Sh44dow
    Poziom 16  
    Witam.
    Planuję kupić jakiś sprzętowy debugger do AVRów i mam kilka pytań odnośnie ich funkcjonalności - nigdy z takowego nie korzystałm.

    Czy debuggery typu JTAG ICE mkII lub tańszy AVR Dragon (to chyba będzie mój wybór) to jedynie symulator dowolnie wskazanego mikrokontrolera, czy może jest możliwość podłączenia go do "żywego" układu i np. podejrzenie aktualnego stanu pamięci? Potrzebuję skorzystać z debuggera w aplikacji, w której jest jeszcze kilka innych układów, więc symulacja samego AVRa niewiele pomoże.

    Drugie pytanie - chodzi mi o konkretne dwie funkcjonalności - chcę podejrzeć wartość wskazanej przeze mnie zmiennej podczas działania programu (jak w środowiskach na PC) oraz chcę, żeby IDE pokazało mi "skąd" ta zmienna (1-4 bajtowy obszar w pamięci) została zmieniona (konkretna linia w kodzie). Czy np. AVR Studio ma taką funkcjonalność?
  • #2 11355969
    ZbeeGin
    Poziom 39  
    Sh44dow napisał:
    Czy debuggery typu JTAG ICE mkII lub tańszy AVR Dragon (to chyba będzie mój wybór) to jedynie symulator dowolnie wskazanego mikrokontrolera, czy może jest możliwość podłączenia go do "żywego" układu i np. podejrzenie aktualnego stanu pamięci?

    One pracują tylko z realnym układem który posiada JTAG, dW.
    Jeśli chodzi o PDI to moje ostatnie boje z AVR Dragon + AVR Xmega wykazały, że ten typ połączenia jest obecnie niemożliwy, i trzeba do jakichkolwiek prac wybrać jednak układ Xmega z JTAGiem. Zatem jeśli masz w planach układy Xmega to AVR Dragon-a stanowczo odradzam.

    Sh44dow napisał:
    chcę podejrzeć wartość wskazanej przeze mnie zmiennej podczas działania programu

    Chodzi Ci o zmienną znajdującą się w aktualnie wykonywanym bloku, czy poza nim?
  • #3 11356009
    Sh44dow
    Poziom 16  
    Dzięki za odpowiedź.

    Chodzi o jedną ze zmiennych (struktur) globalnych. Gdzieś mam wycisk i się nadpisuje.


    Jeszcze jedno pytanie - czy użycie debuggera wpłynie na działanie programu (np. spowolni) ?
  • #4 11356276
    JarekC
    Poziom 32  
    ZbeeGin napisał:

    Jeśli chodzi o PDI to moje ostatnie boje z AVR Dragon + AVR Xmega wykazały, że ten typ połączenia jest obecnie niemożliwy, i trzeba do jakichkolwiek prac wybrać jednak układ Xmega z JTAGiem. Zatem jeśli masz w planach układy Xmega to AVR Dragon-a stanowczo odradzam.


    Jedna z not aplikacyjnych Atmela "AVR1005: Getting started with XMEGA" podaje że AVR-Dragon pozawala zarówno na programowanie jak i debugowanie XMEGA poprzez PDI.

    Właśnie zamówiłem Dragona i Twoja informację trochę mnie skonsternowała.
    Czy na linii RESET masz jakieś elementy typu rezystor do zasilania, lub kondensator do masy? Atmel podaje że na czas debugowania powinny być usunięte.
    Cytat:
    Therefore, during development you should remove any pull-up and decoupling capacitors.


    Pozdrawiam
    JarekC
  • #5 11357895
    ZbeeGin
    Poziom 39  
    JarekC napisał:
    Jedna z not aplikacyjnych Atmela "AVR1005: Getting started with XMEGA" podaje że AVR-Dragon pozawala zarówno na programowanie jak i debugowanie XMEGA poprzez PDI.

    Powiem tak: buchaj-arkusz. Jakieś dwa tygodnie temu usiłowałem się połączyć za pomocą Dragona, z najnowszym oprogramowaniem systemowym, z kilkoma układami Xmega przez PDI. Nawet sygnatury nie potrafił odczytać. Niestety, zawsze otrzymywałem informację, że Atmel Studio 6 nie potrafi się połączyć i sprawdź połączenia, itp. Oczywiście połączenia są poprawne bo oryginalny AVR ISP mkII bez problemu się łączy, a na moim prototypie nawet mam zworkę odłączającą cały zewnętrzny reset. Powiem więcej, nawet klon AVR ISP mkII (od Sibita, z najnowszym FW) miał problemy z połączeniem, gdyż albo zatrzymywał się po odebraniu sygnatury, albo w ogóle wieszał całe Atmel Studio 6, tu akurat jestem skłonny ku tezie o niekompatybilności jego firmware-u z AS6. Z AVRDUDE nie próbowałem bo już nie miałem ochoty dalej bawić się półśrodkami.

    AVR Dragon jedynie połączył się z układem ATxmega128A3, ale tylko przez JTAG - tylko ten układ z całej dostępnej mi puli miał taką możliwość - i zarówno programowanie, jak i debugowanie działało w miarę sprawnie.

    Moje krótkie śledztwo ujawniło dziwny przebieg podczas rozpoczęcia programowania przez Dragona. Kanał 1 to PDI_CLK, kanał 2 to PDI_DAT:
    Czy AVR Dragon umożliwia podgląd pamięci i śledzenie zmian zmiennych? Czy AVR Dragon umożliwia podgląd pamięci i śledzenie zmian zmiennych?
    Niezgodny z tym co można zobaczyć m.in. w "XMEGA A Manual":
    Czy AVR Dragon umożliwia podgląd pamięci i śledzenie zmian zmiennych?
    Tak jakby AVR Dragon miał zanegowaną linię PDI_DATa i jeszcze do tego próbował podawać aż 8V!.

    Żadne próby z podciąganiem i wymuszaniem stanu nie przyniosły pozytywnego rezultatu. Może kiedyś do tego wrócę, ale obecnie chce skończyć mój projekt.
  • #6 11358404
    alagner
    Poziom 26  
    ale ktoś już na forum pisał że część XMega ma błędy w krzemie i Dragonem ich nie zaprogramować nie można.
  • #7 11359039
    qazpylades
    Poziom 13  
    Zacznijmy od początku.
    Czy jest potrzebny sprzętowy JTAG?
    nie.
    jest potrzebny programator.
    Zalety JTAG-a:
    śledzenie w układzie.
    Wady JTAG-a w wykonaniu Atmel-a.... :
    gubi program w trakcie śledzenia.
    nie potrafi śledzić działania WDT.
    okłamuje użytkownika - jeśli kompuilator nie włączy kawałka kodu a debuger Atmala z Jtag-iem widzi ten kod i go wykonuje w pracy krokowej zaś nie widać działania przy uruchomieniu bez kontroli. Dopiero śledzenie wygenerowanego w pliku lss ciągu instrukcji asm pokazuje nagą prawdę.

    dużo lepiej niestety zachowuje się softwerowy emulator-debuger od JTAG-a z kontrolerem.
    Już lepiej sobie osobiście napisać kawałek kodu do debugowania i używać na przemian z programowym emulatorem. Osobiście uźywam taki ze śledzeniem step by step + breakpointy programowe.
    Jednak osobiście proponuję LPC1111 lub STM32.
    czas zrobić skok technologiczny i zapomnieć o przedrogich i o słabych parametrach AVR-kach.
  • #8 11370788
    tmf
    VIP Zasłużony dla elektroda
    Kolego qazpylades, możesz podać przykład gubienia programu w trakcie śledzenia i wyjaśnić o co konkretnie ci chodzi?
    Co do okłamywania użytkownika - radzę się przyjrzeć kompilatorowi i generowanym przez niego informacjom dla debuggera. JTAG w żaden magiczny sposób nie śledzi kodu programu, Atmel Studio przy wyświetlaniu informacji korzysta z danych generowanych przez gcc. Absolutnie nie ma możliwości aby w trybie śledzenia z JRAG wykonywał się jakiś inny kod niż bez JTAG. Ba, JTAG w ogóle nie widzi "programu", widzi tylko stan MCU.
  • #9 11440631
    qazpylades
    Poziom 13  
    Atmel się nie popisał. problem ze śledzeniem polega w ich przypadku na tym, iż z jednej strony soft emuluje a z drugiej sprzęt wykonuje. jeśli soft pomyli się to kontroler "ucieka" i w momencie gdy spodziewamy się , iż wykonamy "krok" programu okazuje się iż tracimy kontrolę. Wynika to z tego, że pułapkę soft ustawił w przewidzianym miejscu a kontroler poszedł w zupełnie innym kierunku.
    Najlepszym przykładem będzie odpalenie WDT. soft nie potrafi przewidzieć co zrobi podłączony sprzęt i gdy następuje reset od WDT podczas wykonania kolejnego kroku to nie zatrzymujemy się na początku programu tylko tracimy kontrolę nad podpiętym kontrolerem i trzeba ponownie załadować soft i rozpocząć śledzenie od zera. to byłoby pół biedy ale oprogramowanie nie sygnalizuje tego. A najgorsze jest, iż z niewiadomych przyczyn traci też kontrolę. czasem okazuje się, iż jest to błąd oprogramowania a czasem zignorowanie niepoważnie wyglądającego ostrzeżenia (nie błędu).
    w wyniku jednej z tych dwóch możliwości zawartość programu w C różni się od wygenerowanego kodu w ASM. emulator pokazuje że wykonuje kod i w pracy krokowej widać jego działanie na sprzęcie!!! Mimo to po uruchomieniu kodu "wolno" program nie działą poprawnie.
    Ostatnio nawet na AVR-GCC zgłaszałem buga związanego z opcją powyżej -o0. Pisałem soft gdzie gcc zgłupło całkowicie. w okolicy pełnej pamięci dla mega644p.
    dopiero dokłądne badanie .lss wykazało dlaczego dobrze działający program w pracy krokowej z JTAG-iem nie działał po wolnobieżnym odpaleniu softu na kontrolerze.
  • #10 11441043
    tmf
    VIP Zasłużony dla elektroda
    To co piszesz to nie wada JTAGa Atmela, tylko przykro mi to mówić, twój brak umiejętności debuggowania. JTAG pracuje na poziomie stanu procesora, ustawiając pułapkę sprzętową w kodzie C, który po działaniu optymalizatora nie da się przenieść w prosty sposób na assembler powstaje problem. Gdzie tą pułapkę ustawić, skoro instrukcja języka C jest tłumaczona na kilka instrukcji assemblera, a w dodatku czasami optymalizator ją całkowicie usunął? W wielu przypadkach takie błędnie ustawione breakpointy Atmel Studio sygnalizuje innym kolorem. Ale nie zawsze to jest możliwe, gdyż ustawiając breakpointa AS bazuje na informacji dla debugerra wygenerowanej przez kompilator. Oczywiście błędnie ustawiony breakpoint nie zadziała. Stąd też debugując program często używa się jednocześnie podglądu w C i okna podglądu w assemblerze - breakpoint ustawiony w listingu assemblerowym zadziała zawsze.
    Co do WDT - jak soft ma przewidzieć zadziałanie WDT? Mylisz symulację sprzętową, w której AS jest tylko frontendem umożliwiającym wgląd w bieżący stan procesora z symulacją programową (w której nota bene przewidzenie zdarzeń asynchronicznych też często jest niemożliwe). Ba, JTAG w ogóle nie interpretuje zdarzenia, skoro wystąpiło to MCU po prostu wykonuje kod, a że nie masz w nim breakpointa to po prostu jedzie. Niby dlaczego miałby się zatrzymać?
    Nigdy nie spotkałem się z jakąkolwiek inną przyczyną dziwnego działania JTAGa, mimo, że bawię się tym już od chyba 10 lat, a przez moje ręce przeszły chyba wszystkie narzędzia Atmela.
    Podaj swój nr zgłoszenia błędu gcc, z ciekawości go przejrzę. BTW, nawet jeśli istotnie jest błąd, to trudno za niego winić JTAGa, skoro to błąd gcc (domniemany).
REKLAMA