To pytanie dotyczy samego przeprogramowania AVR .
Informacje o projekcie:
Mamy produkt zasilany bateryjnie za pomocą ATMEGA644P. Aplikacja działa na stałe w trybie uśpienia i budzi się tylko raz na sekundę (RTC) lub po uruchomieniu jednej z dwóch zewnętrznych linii przerwania.
Urządzenie posiada dość prosty moduł ładujący, który komunikuje się przez UART (za pomocą interfejsu RS232 IC). Służy jedynie jako wygodna metoda aktualizacji oprogramowania układowego, dzięki czemu nie jest wymagany sprzętowy programista ISP. (Moduł ładujący oczekuje telegramów zabezpieczonych sumą kontrolną)
Urządzenia zostały zaprojektowane z wewnętrznym wyłączeniem zasilania WYŁĄCZONE, ponieważ podwaja zużycie energii, a długa żywotność baterii jest obowiązkowa (wydaje mi się, że należało zastosować zewnętrzne wykrywanie wyłączenia zasilania - trwa przeprojektowanie).
Problem:
Co kilka miesięcy urządzenie po prostu przestaje działać, na tych urządzeniach nie przeprowadzono żadnych aktualizacji oprogramowania układowego. Jednak po dalszym badaniu zawartość flash tych urządzeń wydaje się być uszkodzona. Co więcej, baterie niektórych z tych urządzeń były nadal dobre, ale nie chcę wykluczyć jakiejś sytuacji pod napięciem.
To jest porównanie oryginalnej zawartości flash (po lewej) z uszkodzoną zawartością (po prawej):
Niektóre spostrzeżenia:
- Uszkodzony blok zawsze składa się z co najmniej jednej strony flash (256 bajtów) i jest wyrównany. Innymi słowy: dotyczy to tylko całych stron, a nie pojedynczych bajtów.
- Uszkodzona treść przez większość czasu czyta 0xFF, ale może także zawierać inne wartości lub być całkowicie „losowa”.
- Mały pasek po lewej stronie obrazu pokazuje wszystkie dotknięte obszary. W przypadku tego urządzenia jest to około jednej dziesiątej całkowitej zawartości pamięci flash.
- Mieliśmy jedno urządzenie, na którym miało to wpływ tylko na jedną stronę.
Jest całkowicie prawdopodobne, że zbyt niskie napięcie podczas zapisywania pamięci flash może spowodować uszkodzenie zawartości pamięci flash. Oznaczałoby to jednak, że niektóre instrukcje wrażliwe na flash muszą zostać wykonane.
Być może kontroler uruchamia się losowo z powodu zbyt niskiego napięcia, a kod modułu ładującego działa w tym czasie całkowicie nieprzewidywalnie. Cytując faceta z innego forum dotyczącego niskiego napięcia:
„Wykonywane są nie tylko losowe instrukcje z pamięci flash, ale także okres losowych instrukcji (nie ma gwarancji, że kod z pamięci flash zostanie poprawnie odczytany i zinterpretowany). Wraz z tym inne części MCU mogą nie działać zgodnie z przeznaczeniem, w tym z ochroną mechanizmy ”.
Pytanie:
Czy uważasz, że „przypadkowe zachowanie podczas zbyt niskiego napięcia i wykonywania niektórych instrukcji zmieniających dane na stronach flash” - wyjaśnienie jest trafne? Jeśli tak, to dlaczego nie widzimy tego rodzaju błędów przez cały czas jako przyczynę problemów z oprogramowaniem (przepełnienie stosu, nieprawidłowe wskaźniki).
Czy masz jakieś inne pomysły, co może spowodować tego rodzaju korupcję? Czy może to być spowodowane przez EMI / ESD?
Odpowiedzi:
Powinieneś zauważyć, że flash nie jest zapisany, jest skasowany. Wymazana pamięć flash jest pełna 0xFF. Pierwsze 256 bajtów jest całkowicie usuwane, a trzeci 256-bajtowy region jest częściowo usuwany (masz tylko 0 do 1 bitflipów od poprawnych danych do uszkodzonego).
Zgodnie z arkuszem danych , ten flash jest kasowalny (zazwyczaj pracuję z blokami wymazywania większymi niż strony). Jak widać na stronie 282, czyszczenie strony za pomocą SPM jest dość łatwe.
Możesz być zainteresowany w punkcie 23.8.1 (Zapobieganie korupcji w trybie flash):
źródło
BLB01
i znajomych) są odpowiednio ustawione! Czy oni są? „Mylące ... nota aplikacyjna ...” - Notatki aplikacyjne są notorycznie niewiarygodne. Używaj ich wyłącznie do inspiracji; w celu uzyskania gwarancji skorzystaj z kart danych (które nie są nieomylne, ale hej).Jest to dobrze znany problem i wpływa na wiele mikrokontrolerów (nie tylko Atmel). Sprzęt sterujący pamięcią flash uszkadza lub usuwa część pamięci w warunkach niskiego napięcia. Prostym rozwiązaniem jest włączenie ochrony przed wyładowaniami.
Oczywiście zawsze należy włączyć ochronę przed mikroprocesorem na mikrokontrolerach.
źródło
Zbyt niskie napięcie jest bardzo prawdopodobną przyczyną. Na przykład kiedyś miałem projekt, w którym poziom zaciemnienia wynoszący 1,8 V często powodował uszkodzenie, a tych zepsuć nigdy nie można odtworzyć przy poziomie zaniku wynoszącym 3,5 V.
Zauważ, że im szybciej procesor działa, tym bardziej jest wrażliwy na problemy z napięciem. Jeśli obniżenie częstotliwości procesora jest dla ciebie dostępną opcją, warto spróbować.
źródło
EMC będzie twoim największym wrogiem, jeśli nie będziesz przestrzegać głównych zasad projektowania płytek drukowanych. Oto najważniejsze z mojego własnego doświadczenia: - blokowanie kondensatorów na dowolnym układzie scalonym, niezależnie od tego, co producenci mówią w swoich arkuszach danych o piekielnych schematach, umieść co najmniej jeden między 100pF - 1nF na liniach energetycznych każdego układu scalonego - przewodzenie obszarów naziemnych na jak najwięcej warstw każdej płytki drukowanej. Z obszarami tymi należy się kontaktować przez wszystkie warstwy za pomocą przelotek tak często, jak to możliwe, siatka 50 mil jest dobrą wartością. Połącz te obszary z sygnałem uziemienia. - Nigdy nie pozostawiaj niepodłączonej (pływającej, bez podłączonego sygnału) miedzi na płytce drukowanej. Działa jak antena i zdecydowanie oddaje promieniowanie elektromagnetyczne na urządzenia - czyń ślady niosące sygnały zegara tak krótkie, jak to możliwe
Znajdź więcej informacji według żądań wyszukiwarek, takich jak „przewodnik po projektowaniu PCB z certyfikatem EMC”
źródło