65 (86)

Projektowanie ■

Projektowanie ■

V

DD

V

DD

MCUSR - MCU Status Register

The MCU Status Register provides information on which reset source caused an MCU reset.

Bit    7    6    5    4    3    2    1    0

0x55 (0x55)		-	-	-	WDRF	BORF	EXTRF	PORF | MCUSR
Read/Write	R	R	R	R	R/W	R/W	R/W	R/W
nitial Value	0	0	0	0		See Bit Description

•    Bit 7..4: Res: Reserved Bits

•    Bit 3 - WDRF: Watchdog System Reset Flag

•    Bit 2 - BORF: Brown-out Reset Flaa

•    Bit 1 - EXTRF: External Reset Flag

•    Bit 0 - PORF: Power-on Reset Flag

Rys. 16

sić oprócz oprogramowania szereg innych czynników, zwłaszcza sprzętowych. Zdarzyło mi się kiedyś opracowywać urządzenie, w którym mikrokontroler zawieszał się w krótkich, losowych odstępach czasu podczas pracy silnika. Po dokładnych poszukiwaniach błędu w kodzie nie udawało mi się go odnaleźć. Losowe odstępy pomiędzy kolejnymi rese-tami procesora wskazywały, że problem jest raczej natury sprzętowej niż programowej. Dopiero po dokładnej analizie dokumentacji procesora zdałem sobie sprawę, że fusebity muszą być ustawione w inny sposób, tzn. najmłodszy bit w młodszym bajcie powinien być wyzerowany. Co prawda zwiększa to zużycie prądu, ale podnosi również odporność na zakłócenia. Osobnym problemem było ustalenie, co się tak naprawdę dzieje, mianowicie czy procesor ulega częstemu zresetowaniu, czy coś innego się z nim dzieje (np. zasilacz ma za małą wydajność prądową). Odpowiedź na to pytanie przyniosła pułapka zastawiona na początku programu, bo po każdym rcsecie dioda LED migała parokrotnie, co pozwoliło jednoznacznie stwierdzić, że procesor rozpoczyna swoja pracę od początku. Samoistne resetowanie procesora, przy założeniu, że watchdog jest wyłączony, dowodzi, że istnieją problemy sprzętowe lub program jest ewidentnie źle napisany, np. nie jest przyjmowana procedura obsługi przerwania na skutek złego ustawienia wektorów przerwań. W przypadku podejrzenia, że istnieją problemy natury sprzętowej, warto monitorować napięcie zasilające, bo być może urządzenie powoduje zwarcia lub chwilami pobiera zbyt dużo prądu i układ przez kilka chwil nie jest zasilany. Inną przyczyną może być również problem z układem resetu — wisząca w powietrzu końcówka, zbyt długa ścieżka, etc. Najlepszym rozwiązaniem są sprzętowe układy resetującc, które odpowiadają za pilnowanie poprawnej pracy mikrokontrolera. Przykładowe rozwiązanie zostało pokazane na rysunku 15. Układ MCP100 utrzymuje mikrokontroler w stanie resetu do czasu ustabilizowania napięcia zasilającego i resetuje go w sytuacji, gdy napięcie to zaczyna zbyt mocno się wahać. Zapobiega to zawieszeniom programu, gdy napięcie przekracza zakres wartości dopuszczalny przez producenta. Warto firmową aplikację wzbogacić o szeregowy rezystor lk£L..10kQ, aby umożliwić sobie podłączenie programatora pracującego w trybie ISP.

Osobną kwestią jest używanie watchdoga. Układ ten odpowiada za nadzorowanie pracy mikrokontrolera. Jeżeli coś wykonuje się zbyt długo (np. oczekiwanie na nową porcję danych z portu szeregowego), to resetuje on procesor, aby zapobiec jego zawieszeniu. W większości mikrokontrolerów istnieją specjalne rejestry, umożliwiające określenie, co było źródłem resetu - rysunek 16. Warto wykorzystać tą informację na etapie pisania oprogramowania, gdyż pozwoli to od razu ustalić, co ponosi winę za reset mikrokontrolera (można zawartość rejestru przesłać np. przez port szeregowy lub wykorzystać cztery diody LED). Na tej podstawie można stwierdzić, czy nie został ustawiony np. zbyt krótki czas wyzwolenia watchdoga. Niemniej warto ten układ włączyć dopiero w końcowym etapie pracy nad oprogramowaniem, aby uniknąć niepotrzebnych problemów.

Można jeszcze dodać, że w przypadku zakłóceń losowych warto dążyć do określenia, w jakich sytuacjach one powstają. Podczas pracy nad zegarem zasilanym z sieci

t    1/    ;    ^    *

elektrycznej pojawił się podobny problem. Z jakiegoś powodu godzina samoistnie się przestawiała czasami tylko trochę, a czasami znacznie więcej. Po przeprowadzeniu różnych eksperymentów ustaliłem ostatecznie, że samoistne przestawienie zegara następuje podczas włączania lampki biurkowej i/lub wiertarki do tej samej listwy, do której włączony był zegar. Wiedząc, co KONKRETNIE wywołuje problem, można było się skupić na określeniu przyczyny i szukaniu rozwiązania. Doszedłem wtedy do wniosku, że problemy powodowane przez urządzenia elektryczne wpięte do tej samej listwy wynikają z zakłóceń przenoszonych przez sieć elektryczną. Wstawienie dławika do urządzenia pozwoliło ograniczyć to zjawisko.

Kilka słów na koniec

W przypadku urządzeń elektronicznych często możliwe jest wielokrotne testowanie urządzenia pod kątem powstawania błędu i badanie go na różne sposoby. Jest to jednak działanie zwykle wymagające sporej ilości czasu, dlatego warto uzbroić się w cierpliwość. Nie jest niczym nadzwyczajnym stwierdzenie, że czas przeznaczony na wyszukiwanie błędów często przekracza kilkakrotnie czas pisania oprogramowania czy projektowania urządzenia. Jest to jednak jeden z ważniejszych etapów pracy nad projektem, który decyduje w dużej mierze o komforcie i jakości wykonanego urządzenia. Wystarczy wspomnieć, jak irytujące potrafią być błędy w pewnym popularnym systemie operacyjnym, aby zrozumieć, jak ważne jest usunięcie ich z własnego oprogramowania.

Jakub Borzdyński

[e-mail]

Zapraszamy do sklepów na Wolumenie !

Ol - 9 1 2 W arsza w a . ul. W o I u m e r»

I.: 835 55 22

pawilon 44 RCS ELEKTRONIK rezystory, kondensatory, elementy SMD pawilon 66 FIRMA PIEKARZ półprzewodniki, przekaźniki, narzędzia, układy cyfrowe, radiatory

Elektronika dla Wszystkich Marzec2010