Od wielu lat z powodzeniem stosujemy mikrokontrolery ATmega48 / 88/168/328 w wielu naszych produktach. Zastanawialiśmy się teraz nad przejściem z wariantów A i PA na nowy wariant PB (ponieważ będziemy potrzebować dodatkowych pinów, timerów i UART w nowych produktach, ponieważ staje się on tańszy i ponieważ wydaje się, że stare warianty zostaną wycofane), więc wymieniliśmy ATmega328A z ATmega328PB. Wydaje się, że bardzo często szaleje po przerwach w zasilaniu . Takie problemy nigdy nie występowały w przypadku starych wariantów.
Regularne przerwy w zasilaniu są normalne w przypadku użytkowania naszych produktów. Używamy zasilacza impulsowego (takiego jak ten ) ustawionego na 5 V i kondensatory w zakresie 220µF na VCC ATmega, aby utrzymać SRAM przy życiu w przypadku przerw w zasilaniu w zakresie kilku minut, do przechowywania stanów wewnętrznych, które nie są misją krytyczne, ale znacznie zwiększające wrażenia użytkownika, ponieważ są natychmiast dostępne po ponownym uruchomieniu (stany te zmieniają się wystarczająco często, aby EEPROM nie był odpowiedni). To zawsze działało.
Jednak w przypadku nowej ATmega328PB, po przerwie w zasilaniu, układ resetuje się bez warunku resetowania w MCUSR, a zegar wydaje się szaleć.
- wykrywacz braku prądu jest ustawiony dla każdego bezpiecznika. Próbowaliśmy wszystkich dostępnych poziomów, błąd występuje na wszystkich z nich.
- używamy zewnętrznego 20 MHz, również ustawionego poprawnie na bezpiecznik.
- wypróbowaliśmy 3 różne układy, więc nie była to ani jedna awaria lutowania, ani inny sprzęt.
Po wystąpieniu błędu zegar często ustawia się na 2,5x wolniejszą prędkość, co oznacza, że mcu jest taktowany przez wewnętrzny oscylator 8 MHz. Czasami jednak spowolnienie wynosi około 6 razy. Oznacza to, że nie może to być błąd oprogramowania zmieniający dzielnik zegara, ponieważ nie mogę ustawić bezpieczników z oprogramowania, a dzielnik zegara nie może podzielić zegara przez 2,5 lub 6.
Więc moim pierwszym podejrzanym był nowy bezpiecznik wykrywania awarii zegara. Jednak bez względu na to, czy jest włączone, czy nie, zachowanie pozostaje takie samo.
Aby wykluczyć specyfikę oprogramowania, napisałem prosty program testowy, który nie robi nic innego, jak tylko przełącza wyjście z częstotliwością 100 Hz z przerwania timera i wskazuje za pomocą diod LED po każdym ponownym uruchomieniu, które warunki resetowania zostały aktywowane (odczytane z MCUSR). Reszta sprzętu również została usunięta, tylko mcu i regulator są tam (i diody wskaźnika z rezystorami szeregowymi).
Wyniki
Mniej więcej w 2/3 czasu nic ciekawego się nie dzieje. Po przerwie w zasilaniu, mcu wznawia pracę, świecą się zarówno wskaźniki resetowania wyłącznika zasilania, jak i resetowania po włączeniu zasilania.
(na zdjęciu czerwony to kołek przełączany, a niebieski to VCC. Na tym zdjęciu wyraźnie widać rozjaśnienie brony 2,7 V. Wykonałem te same testy z innymi ustawieniami brązowania, wyniki są dokładnie takie same, więc pominę te zdjęcia)
Mniej więcej w 1/3 przypadków występuje wspomniany błąd, a gdy zasilanie zostanie ponownie przywrócone, nie świecą żadne wskaźniki resetowania przy wyłączonym zasilaniu i resecie po włączeniu zasilania! Wyjście jest inne, jakby mcu tykało dziwnym zegarem. Nie jest jednak chaotyczny, wciąż tyka z tą samą częstotliwością.
Co ciekawe, w tej sytuacji wykrywacz zanikania wydaje się być całkowicie nieaktywny, ponieważ po następnej przerwie w zasilaniu (gdzie czasem przywracany jest właściwy zegar, a czasem nie), wyraźnie widać, że wyjście nadal przełącza się dobrze po brązowym- nasz poziom został zaliczony. W takich sytuacjach zegar czasem przyspiesza, innym razem wolniej:
Podczas tych testów użyłem 16K CK / 14CK + 4,1 ms dla opóźnienia rozruchu (ale opóźnienie 65 ms nie omija problemów).
Oto powiększone zdjęcie, na którym wyraźnie widać, że VCC osiąga stan stabilny przy 5 V w czasie poniżej 2 ms:
Na powyższym obrazku mcu uruchomiło się poprawnie.
Co ciekawe, gdy tak nie jest, napięcie zasilające dochodzi nawet do stabilnego poziomu 5 V (wydaje się, że wiele części MCU nie włącza się, więc pobiera mniej prądu podczas uruchamiania)
Poniżej znajduje się obraz z nieudanego początku:
Należy pamiętać, że oprogramowanie zaczyna działać po upływie ponad 85 ms po ustabilizowaniu napięcia zasilania, zamiast 10,5 ms wymaganego w inny sposób. Bezpieczniki opóźnienia uruchomienia są nadal takie same, 16K CK / 14CK + 4,1 ms.
Warto również zauważyć, że po wyłączeniu zasilania VCC stabilizuje się na poziomie około 1,1 do 1,2 wolta (stary wariant ATmega328A spadł do około 0,6 - 0,7 V). Utrzymuje to przez kilka minut. Jeśli poczekam wystarczająco długo (rzędu pół godziny lub więcej), mcu zawsze zaczyna się poprawnie! Wygląda więc na to, że problem polega na tym, że wokół jest 1,1 wolta, co zgodnie z arkuszem danych nie gwarantuje, że wystarczy do resetu po włączeniu zasilania. Ale to powinno wystarczyć do resetu!
Z wyjątkiem tych sytuacji detektor zanikania działa dobrze. Jest widoczny na pierwszym obrazie (sygnał wyjściowy zatrzymuje się po osiągnięciu poziomu podstawowego, a spadek napięcia zwalnia, gdy części mcu zostają wyłączone). Zrobiłem testy, kiedy obniżyłem VCC do nieco poniżej poziomu podstawowego i pozwoliłem mu wrócić z powrotem, mcu zawsze restartowało się poprawnie w takich warunkach, z zapalonym tylko wskaźnikiem zerowania.
Czy przegapiłem coś oczywistego, czy też ATmega328PB ma poważny błąd w wykrywaczu braku zasilania?
EDYTOWAĆ:
Co ciekawe, powyższe problemy powstają tylko wtedy, gdy przerywam dostawę przed regulatorem. Jeśli przerwie to po regulatorze (lub użyję zasilacza laboratoryjnego), problemy nigdy się nie zdarzają. Jakby kształt rosnącego napięcia powodował problemy. Jednak, jak widać na ostatnim zdjęciu, wzrost napięcia jest całkiem niezły i szybko się stabilizuje.
EDYCJA 2
Wypróbowałem to z 16 MHz zamiast 20 MHz, ale zdarzają się dokładnie te same problemy.