[ARM] Debugging przerywa działanie programu przy pauzie między przerwaniami?

napisalem sobie prosciutki programik... standard, czyli miganie LEDami, super efekt swietlny typu Knight Rider [; mniejsza o to. do zabawy wykorzystuje 2 timery - jeden odpowiada za rzeczy typu inkrementowanie / dekrementowanie pozycji lub lekka przerwa miedzy cyklami (zeby wygladalo realistycznie do bolu [; ). drugi robi za PWM softwareowy. i teraz puszczam sobie debuggowanie... dziala. zapauzuje w momencie gdy diodki leca w gore/w dol - dziala (znaczy sie po odpauzowaniu dziala nadal jak nalezy). natomiast problem pojawia sie, gdy zapauzuje go w momencie oczekiwania. ostatnie przerwanie od dekrementacji przelacza VIC na inne przerwanie i lekko zmienia konfig timera. kolejne przerwanie powinno wiec (i robi to normalnie!) przestawic timer spowrotem na standard i zmienic funkcje w VIC. problem jest tego rodzaju, ze jesli zapauzuje program DOKLADNIE w momencie miedzy tymi dwoma przerwaniami to po uruchomieniu ponownym przerwania juz nie dzialaja. podgladajac pamiec widze ze:
- przerwania sa aktywowane w VIC
- przerwania sa zgloszone do VIC
- VIC posiada stosowne adresy, zeby przerwania obsluzyc
- timery dzialaja i sa skonfigurowane jak nalezy
w momencie tego wlasnie oczekiwania program nie robi nic ciekawego: while(1);

co moze byc powodem tego zachowania? dodam, ze program sam sobie dziala jaknajbardziej poprawnie - bez pauzowania w tym konkretnym momencie wszystko smiga jak nalezy - zapauzowany w dowolnym innym momencie rowniez dziala po wznowieniu, natomiast w tym jednym akurat - nie. czy to kwestia ograniczen debuggera?

moge wrzucic kod, ale jak juz mowilem - bez pauzowania w tym momencie dziala wysmienicie i dowolnie dlugo.

0x41 0x56 0x45!!

Jeśli uzywasz OpenOCD to nie wiem czy coś na to poradzisz. Jest to błąd z którym nie jeden amator ARMów już się spotkał.
Debugowanie nie działa do końca poprawnie przy wykorzystaniu przerwan.

Poza tym jeśli się wie co się pisze to debuger jest zbędny. Czasami lepiej wykorzystać UART DBGU i wysyłać sobie interesujące nas zmienne na terminal.

no juz nie forujmy takich twierdzen [; po prostu co kto lubi - jedni lubia debuggery, inni nie [;. ja lubie <:

w kazdym razie wlasnie o to mi chodzilo - o info, ze 'tak czasem bywa' <:

0x41 0x56 0x45!!

adamusx napisał:

Poza tym jeśli się wie co się pisze to debuger jest zbędny. Czasami lepiej wykorzystać UART DBGU i wysyłać sobie interesujące nas zmienne na terminal.

Co to za podejscie ? Debugger to NIEZBEDNE narzedzie przy profesjonalnych produktach i nie raz uratowal mi tylek przy poprawkach bledow w nieswoim kodzie.

Spotkalem sie z tym ze rozne debuggery roznie obchodza sie z przerwaniami np jedne je wylaczaja na czas break-a, inne nie. Byc moze OpenOCD wylacza normalnie przerwania i w pewnych warunkach nie przywraca ich z powrotem. Nie uzywalem jeszcze OpenOCD wiec nie wiem jak to wyglada w praktyce ale moze warto zglosic do nich taki problem. Przyjrzyj sie rejestrowi statusowemu i zobacz jak to jest z ta flaga przerwania w break-u.

ja np nabylem JTAGa do AVRow i ani razu go nie uzylem, do ARMOw posiadac JTAGA pewnie niedlugo bede ale do tej pory debugowalem przez uarta i jakos szlo wiec nie jest to "NIEZBEDNE" narzedzie. i tez sadze, co kto lubi lub co sie komu chce w danym momencie

w niektorych prockach jak np LPC2368 linie JTAGa sa wyprowadzone osobno wiec spoko mozna sie podpinac ale np w tym, ktorego uzywa w tej chwili Freddie (LPC2148) sa wspoldzielone z kilkom,a nozkami portu a to czasem przeszkadza wiec nie zawsze wykorzystanie JTAGa jest wskazane/mozliwe choc nie przecze, ze daje duze mozliwosci.