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

[Attiny2313V/C] Stabilność kodu na Attiny2313V/C - skoki do początku programu bez resetu

maciej_333 10 Sty 2015 16:39 1227 7
  • #1 14314659
    maciej_333
    Poziom 38  
    Moim problemem jest brak stabilności kodu dla tego mikrokontrolera. Kod skompilowałem w AVR Studio 4 z WinAVR w aktualnej wersji (2010).

    Kłopoty objawiają się poprzez skok do początku programu. Nie jest to reset - np. zakłócenia na linii RESET. Analizowałem rejestr statusu MCUSR. Początkowo przyjmuje on wartość 0x01, co znaczyłoby reset od POR. Jest to zrozumiałe. Potem jednak ma on wartość 0x00, co świadczy o braku resetu. Musi to być zatem skok do początku. Oczywiście rejestr MCUSR jest zerowany po odczycie. Myślałem, że to problem nieuchwyconego ISR, ale tylko raz, lub dwa przydarzył się ten problem. W dodatku było to po wcześniejszym dziwacznym skoku do początku, więc siłą rzeczy coś takiego mogło wywołać problemy. Próbowałem też zmniejszyć poziom optymalizacji, ale nawet na O1 jest identycznie. Wyłączyć optymalizacji nie mogę, bo nie zmieszczę kodu.

    Jeszcze zabawniejsze jest to, że na innym egzemplarzu mikrokontrolera o identycznym oznaczeniu program zachowuje się inaczej. Tutaj początkowo w MCUSR jest 0x81, co świadczy o resecie z POR i Watch Doga. Potem już tylko 0x80, zatem wynikałoby, że to właśnie Watch Dog wykonuje reset. Co ciekawe FUSE BIT WDTON jest niezaprogramowany w obu układach. Rejestry samego Watch Doga też nie były zmieniane. W tym mikrokontrolerze częstotliwość tych resetów wydaje się być niższa.

    Niekiedy też zwyczajnie kod się wiesza nie wiadomo gdzie. Jeszcze nie ustaliłem, gdzie to następuje.

    Napięcie zasilania to 3,3 V, częstotliwość taktowania 4 MHz na wewnętrznym oscylatorze RC. Nie ma problemów z zakłóceniami. Nieużywane linie są ustawione jako wyjścia.
    Załączam cały kod źródłowy. Mogę przekazać sporo punktów osobie, która rozwiąże ten problem.
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
  • #3 14315455
    maciej_333
    Poziom 38  
    Bez modułu radiowego ten program nawet by się nie uruchomił. To nie zakłócenia. Sprawdzałem oscyloskopem. Szum na poziomie kilkudziesięciu mV nie może zakłócić pracy urządzenia cyfrowego. Wszystko wskazuje na problem w kodzie. Wygląda na to, że w szumie tworzonym przez jakieś nieznane urządzenie w kanale na jakim pracuje CC1101 czasem udaje się mu znaleźć słowo synchronizacji i nawet dobrą preambułę. Tego nie przewidziałem przy wstępnych testach. Wynikałoby z tego, że przy odczycie kolejki RXFIFO z CC1101 niszczyłem nawet całą pamięć, łącznie ze stosem. Wynikałoby to z kolei z niekiedy znaczącej liczby bajtów w kolejce. Muszę to jeszcze jednak dokładniej przetestować.

    To jednak i tak nie tłumaczy różnicy w zachowaniu się urządzenia dla innego egzemplarza Attiny2313.
  • #4 14316940
    djfarad02
    Poziom 19  
    Ilu bajtowa jest preambuła?
    Robiłem kiedyś transmisje radiową przy niskiej prędkości 2400 i brak fałszywych ramek był osiągalny przy 3 bajtach preambuły i sumie kontrolnej dla danych.

    Apropo zakłóceń to oscyloskop niekoniecznie pomoże w tym by wszystko zobaczyć. Miałem kiedyś chyba jeszcze bardziej kuriozalny przypadek:
    Była sobie mała płytka z ATTiny2313 i kilkoma przyciskami (zwierającymi piny uC do masy). Przy przyciskach, w odległości 4...6mm od nich były podłączone równolegle C=100nF. Proszę sobie wyobrazić, że przy wciskaniu przycisków mikrokontroler szedł czasami w krzaki. Usunięcie kondensatorów 100n rozwiązało problem definitywnie.
  • #5 14317972
    maciej_333
    Poziom 38  
    Preambuła to w moim przypadku 4 bajty (MDMCFG2 = 0x13). Oczywiście CRC jest sprawdzane. Przy fałszywych ramkach jest ono naturalnie błędne. Aktualnie pracuję przy modulacji GFSK, przepływność bitowa 100 kb/s. Docelowo znacznie jednak to ograniczę. Wychodzi na to, że odbierany szum pochodzi z jakiegoś urządzenia, ponieważ ma on wpływ na RSSI i LQI.

    Działała koledze funkcja automatycznego unieważniania kolejki RX (CRC_AUTOFLUSH) przy błędzie CRC ? Chodzi o rejestr PKTCTRL1 = 0x08. Jakoś nie widzę by dochodziło do unieważnienia kolejki. Właściwie kiedy ona będzie kasowana ? Myślałem, że w przypadku błędu otrzymam wartość w rejestrze statusu RXBYTES = 0. Jednak jakoś nie zawsze tak jest.
  • #6 14318174
    el2010tmp
    Poziom 25  
    Gdzie i jak masz zadeklarowaną tablicę dane[] ?
  • #7 14318277
    djfarad02
    Poziom 19  
    Z tego co ja widzę, to jest to tablica tab_pakiet[14] przekazywana przez wskaźnik. Nie ma jednak zabezpieczenia przed przekroczeniem maksymalnego indeksu tablicy. Jeśli to to, to zwycięstwo oczywiście należy się Koledze el2010tmp.
  • #8 14318669
    maciej_333
    Poziom 38  
    djfarad02 napisał:
    Jeśli to to, to zwycięstwo oczywiście należy się Koledze el2010tmp.

    Tak, właśnie to jest problemem. Tylko, że sam to zauważyłem już wczoraj. Pytanie odnośnie CRC_AUTOFLUSH jest nadal aktualne.
REKLAMA