Rejestry MCUCSR , MCUSR w procesorach Atmel, jego funkcje i wykorzystanie.
Z doświadczenia wiem że każdy z procesorów nawet najlepszego producenta popełnia błędy i
nie zależnie od tego czy nasz algorytm jest napisany dobrze czy źle. Szukanie takich błędów jest czasochłonne i frustrujące. Uruchomienie watchdoga i sprawdzenie rejestru MCU Status Register może znacznie przyśpieszyć lokalizację błędu. Pamięć programu flash podczas programowania procesor jest zapisywane po czym weryfikowana ale to nie daje nam 100% pewności że pamięć w czasie pracy nie będzie popełniała błędów. Niejednokrotnie spotykam się z taką sytuacją że wgrany program do procesora w 0.01% przypadków nie działa poprawnie, co wskazuje że 100 procesów na 1’000’000 jest uszkodzonych fabrycznie. Takie błędy zauważyłem w procesorach Atmel i STM. Przypuszczam że w procesorach innych producentów sytuacja wygląda podobnie.
W tym artykule skupiÄ™ siÄ™ na procesorach firmy Atmel.
Rejestr w Atmega328
Rejestr w Atmega8
Rejestr w Atmega32
Rejestr w Atmega128
Rejestr w Atmega1284
Bit 3 – WDRF : Flaga resetowania od watchdog
Bit 2 – BORF : Flaga resetowania od spadku zasilania
Bit 1 – EXTRF : Flaga resetowania , reset zewnątrzy
Bit 0 – PORF : Flaga resetu po włączeniu zasilania
Do czego możemy wykorzystać tą informację i na ile będzie nam potrzebna w dalszym pisaniu programu.
Uruchomienie watchdoga w procesorze jest wskazane a nawet można powiedzieć wymagane. Zabezpiecza nasz algorytm przed zawieszeniem się lub nie prawidłowym działanie. Układ nadzoru jak stwierdzi że procesor działa nie prawidłowo to go zresetuje. Oczywiście w takim przypadku należy pamiętać że procesor wszystkie nasze zmienne ustawi do wartości domyślnych tak jak to zawarliśmy w swoim algorytmie.
Przed utratą danych możemy się zabezpieczyć wpisując je do pamięci eeprom procesora lub deklarując zmienne w sekcji .noinit. Umieszczenie danych w tej sekcji sprawia że kompilator ich nie inicjuje ( inicjacja zmiennych jest przeprowadzona przez kompilator i polega na wpisaniu wartości zero do każdej zmiennej, operacja ta jest przeprowadzona przed main-em ).
Zmienne zadeklarowane w sekcji noinit przechowują swoje dane do chwili całkowitej utraty zasilania.
W powyższej tabelce widać końcowy efekt działania drugiego przykładu.
Widać wyraźnie że procesor był 14 razy zresetowany prze watchdoga i 4 razy przez reset zewnętrzy. Powyższy przykład jest oparty na pamięci ram procesora która jest ulotna. Zapisywanie tych danych do pamięci eeprom procesora przy diagnostyce dlaczego urządzenie przestało działać, wskaże nam kierunek poszukiwania przyczyn awarii.
Kilka słów o bibliotece WDT
#include <avr/wdt.h>
wdt_reset(); // zerowanie licznika w watchdogu
wdt_enable( value ); // włączenie watchdoga z wartością
wdt_disable(); // wyłączenie watchdoga
Watchdog po włączeniu działa stale poza naszym programem ( do momentu wyłączenia )
musimy tak pisać program by polecenie wdt_reset(); zdążyło wyzerować zawartość watchdoga w przeciwny razie watchdog zresetuje nam procesor.
Przy starcie procesor powinniśmy rozpoznawać rodzaj startu, czy jest to normalny start czy spowodowany watchdogiem. Przy resecie od watchdoga raczej nie powinniśmy tracić zgromadzonych danych i po określeniu w którym momencie zadania nastąpił reset powinniśmy wznowić pracę procesora.
Wersja końcowa z użyciem pamięci EEPROM procesora.