Uszkodzenie pamięci flash AVR

11

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):

Porównanie Flash

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?

Rev1.0
źródło
Czy w drugim bloku w twoim przykładzie jakieś bity przeszły od 1> 0 lub wszystkie one 0-> 1 przejścia? Mam skrypt, który to oblicza, ale nie zamierzam wpisywać wszystkich liczb z twojego zrzutu ekranu.
markrages
@markrages: Patrząc na to, tylko 0-> 1. Jedna z odpowiedzi wskazała również, że wygląda to na częściowe wymazanie, w którym nie wszystkie bity zostały zmienione na 1. Dzięki za obserwację.
Rev 1.0

Odpowiedzi:

11

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):

Uszkodzenie programu Flash może być spowodowane dwiema sytuacjami, gdy napięcie jest zbyt niskie. Po pierwsze, regularna sekwencja zapisu do Flash wymaga minimalnego napięcia do poprawnego działania. Po drugie, sam procesor może nieprawidłowo wykonywać instrukcje, jeśli napięcie zasilania do wykonywania instrukcji jest zbyt niskie. Korupcji Flash można łatwo uniknąć, postępując zgodnie z tymi zaleceniami projektowymi (jedno jest wystarczające):

  1. Jeśli w systemie nie ma potrzeby aktualizacji programu ładującego, zaprogramuj bity blokady programu ładującego, aby zapobiec aktualizacjom oprogramowania programu ładującego.
  2. Utrzymuj AVR RESET aktywny (niski) w okresach niewystarczającego napięcia zasilania.
    Można to zrobić, włączając wewnętrzny detektor zaniku zasilania (BZT), jeśli napięcie robocze odpowiada poziomowi wykrywalności. Jeśli nie, można zastosować zewnętrzny obwód zabezpieczający przed zresetowaniem niskiego VCC. Jeśli reset nastąpi w trakcie operacji zapisu, operacja zapisu zostanie zakończona, pod warunkiem, że napięcie zasilania jest wystarczające.
  3. Utrzymuj rdzeń AVR w trybie uśpienia po wyłączeniu zasilania w okresach niskiego VCC. Zapobiegnie to próbowaniu dekodowania i wykonywania instrukcji przez procesor, skutecznie chroniąc rejestr SPMCSR, a tym samym Flash przed niezamierzonym zapisem.
Jacen
źródło
Twoja obserwacja na temat częściowego usunięcia na trzeciej stronie wydaje się wiarygodna. Odnośnie tekstu Atmel: Wszyscy zgadzamy się, że BZT wydaje się obowiązkowy. Ale nadal nie jestem pewien, DOKŁADNEGO powodu korupcji. Czy nie jest mało prawdopodobne, że kontroler po prostu wykonuje (z powodu niskiego napięcia) tę konkretną instrukcję, aby usunąć stronę flashową? To znaczy, musiałoby się to nawet zdarzyć podczas wykonywania kodu modułu ładującego, ponieważ flash można zapisywać tylko stamtąd. I wymaga określonej sekwencji.
Rev 1.0
3
Nie można wyjaśnić dokładnego źródła uszkodzenia: gdy spada Vcc, staje się on zbyt niski, aby całkowicie nasycić jeden tranzystor drugim. MCU to w gruncie rzeczy bardzo duże równanie logiczne. Jeśli tranzystory przestaną zachowywać się jak przełączniki logiczne, zmienisz to równanie. Ponieważ pierwszy tranzystor, który źle zachowuje się, zależy od domieszkowania płytki ASIC i zewnętrznych zakłóceń elektromagnetycznych, nie można przewidzieć, co się stanie. Aby rozwiązać ten problem, podczas projektowania ASIC możesz dodać część analogową, która wyłącza część cyfrową przed niewłaściwym zachowaniem. Ale zwiększa cały koszt ASIC.
Jacen
Mylące jest to, że nota aplikacyjna AVR180 Zewnętrzna ochrona przed brązowym wyłączeniem brzmi: „Uwaga: niewystarczające napięcie zasilania nigdy nie wpływa na zawartość wewnętrznej pamięci programu Flash AVR®. Ponadto: „Ponieważ procesor AVR nie jest w stanie zapisać do własnej pamięci programu, awaria zasilania nie ma wpływu na wewnętrzną pamięć programu Flash”. - IMO Atmel po prostu ignoruje to, że istnieje coś takiego jak programy ładujące, które MUSZĄ zmienić pamięć flash.
Rev 1.0
@ Rev1.0 Tak, to raczej mało prawdopodobne ... dlatego widzisz to tylko na jednym urządzeniu co kilka miesięcy, a nie na wszystkich urządzeniach przez cały czas.
user253751,
„To znaczy, musiałoby się to zdarzyć nawet podczas wykonywania kodu modułu ładującego, ponieważ flash można zapisywać tylko stamtąd”. - To prawda, tylko jeśli bity blokady rozruchu ( BLB01i 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).
marcelm
4

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.

użytkownik
źródło
3
Czy masz jakieś solidne referencje na temat JAK i DLACZEGO „sprzęt kontroli pamięci psuje lub usuwa część pamięci w warunkach niskiego napięcia”? Na forum jest wiele dyskusji na temat korupcji flash, ale prawie nigdy nie sprowadza się to do czegoś solidnego, dlatego o to zapytałem.
Rev 1.0
Czy jest to problem niedostatecznego napięcia w układzie, czy jest związany z niewłaściwym / losowym uruchomieniem programu w sekcji bootloadera, który AFAIK może modyfikować tylko FLASH. Jeśli drugim problemem jest wyłączenie wykonywania programu ładującego przez FUSE, powinno rozwiązać problem.
TMa
Pamiętam, że czytałem o tym w erracie co najmniej jednego mikro MEGA.
użytkownik
3

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ć.

vsz
źródło
1
Dziękuję za odpowiedź. Skończyło się na użyciu zewnętrznego detektora o bardzo niskim poborze mocy i od tego czasu nie mieliśmy żadnych problemów z korupcją.
Rev1.0
0

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”

woodz
źródło