Kłopoty z MCU przy burzy: jak zabezpieczyć sterownik na ATmega128 przed indukcją?

Tue Jun 04, 2013 12:14 pm   

Najdziwniejsza była malutka dziurka jaka


Ta obudowa była wykonana z blachy stalowej o grubości 1 mm. Ta dziurka
została wypalona przez przeskakującą iskrę z wnętrza urządzenia do
metalowego parapetu. Tak więc w czasie burzy mogą wystąpić zakłócenia
najróżniejszego rodzaju. Również takie jak ESD.

Tue Jun 04, 2013 3:08 pm   

No cóż, też uważam to za dość dziwny przypadek. Raczej spodziewałbym się
wysypania programu (i dobrze by się stało, bo pewnie watchdog by
zadziałał).
No ale jednak było jak pisałem - urządzenie działało po prostu tak, jak
gdyby ktoś by stał przy nim przyciskał dwa przyciski na raz.
Po wyłączeniu i włączeniu ponownie wszystko wróciło do normy.

Tak naprawdę było jeszcze dziwniej trochę
Najpierw burza nacisnęła przyciski kursora, przestawiając pewien
parametr. To wiadomo, bo gdyby była to przypadkowa zmiana w ERAM, to
zostałaby zarejestrowana w pamięci zdarzeń próba naprawy (dane są
przechowywane 5-cio krotnie powielone, i sprawdzane jest, czy dane są
takie same, jeśli nie, to są korygowane w oparciu o pozostałe kopie.
Potem, po jakimś czasie, burza puściła te przyciski, i zostały
naciśnięte 2 inne przyciski - wejście w menu, i uruchomienie pewnego
silnika.

Wiem to wszystko, bo program rejestruje ważniejsze zdarzenia, wygląda to
tak (czyta się od dołu listy / numer zdarzenia, czas (hh:mm:ss), data
(day/month) > zdarzenie, dodatkowy parametr);


2979> 23:52:55 01/06 > Motor Started OK Amp=1.4 A
2980> 23:52:54 01/06 > Manual MotorStart
2981> 23:52:54 01/06 > Code incorrect! Uzas=24.6 V
2982> 23:52:51 01/06 > Motor Stop Amp=0.9 A
2983> 23:51:38 01/06 > Motor Started OK Amp=1.2 A
2984> 23:51:37 01/06 > Manual MotorStart
2985> 23:51:36 01/06 > Code incorrect! Uzas=24.6 V
2986> 23:51:34 01/06 > Motor Stop Amp=0.9 A
2987> 23:50:21 01/06 > Motor Started OK Amp=1.5 A
2988> 23:50:20 01/06 > Manual MotorStart

Czyli - ręczne (z klawiatury) uruchomienie silnika, po jego zatrzymaniu
próba wejścia w menu, i tak w kółko
Sprawdziłem to później empirycznie - naciśnięcie i przytrzymanie
odpowiednich przycisków daje dokładnie taki efekt, łącznie z nietypowym
(niepoprawnym zresztą) efektem na wyświetlaczu, zaobserwowanym na miejscu.

Więc - choć to faktycznie dziwne, tak właśnie musiało się wydarzyć. Tych
urządzeń jest kilka, pracują niektóre od ponad roku, takie zdarzenie
było pierwszy raz.

Prawdę mówiąc, wystarczyło dodać inny sposób obsługi klawiatury -
zamiast pozwolić na wykonywanie poleceń przy wciśniętym na stałe
przycisku, zmusić do puszczenia po naciśnięciu. Czyli jedno naciśnięcie
- jedno wykonanie. Ale przenieść wszystkie działania "za hasło" (tak
teraz właśnie zrobię) - bo teraz tylko najważniejsze ustawienia są za
hasłem.

Zamówiłem już EMI-35, ciekawe na ile toto rzeczywiście zaekranuje
obudowę z tworzywa...

Tue Jun 04, 2013 7:50 pm   

Pokaż lepiej fragment pętli, gdzie odczytujesz stan klawiszy i gdzie masz
kasowanie tej zmiennej od klawiszy.
Raczej wydaje mi się, że przeskoczył rejestr i ma taką wartość,
na którą program nie jest przygotowany i ciągle reaguje.
Np.
1) odczyt klawiszy BIT1 i BIT2
2) sprawdzasz czy są naciśnięte po kolei BIT1=0, BIT2=0 itp.
3) Jeśli jest różne od FF zakładamy, że są 2 wciśnięte równocześnie.
4) Tak>włączasz silnik
5) kasujesz BITY1 i 2
6) zapętlasz do 1, a program ciągle uznaje, że ma wciśnięte klawisze.

Nie wiem, czy czujesz co mam na myśli, ale jakoś tak mi to wygląda.
Burza ustała, a program uważa, że ma ciągle wciśnięte klawisze, bo może
wpływ na warunek mają inne, nieużywane bity.
Sprawdź warunki.
Być może brakuje czegoś w inicjacji zmiennych i po restarcie dzieją się
różne rzeczy.
Może spróbuj zerować wszystkie rejestry po starcie.
S.

Tue Jun 04, 2013 8:30 pm   

Rozumiem oczywiście, ale jest jak piszę.
W pętli głównej , gdzie są sprawdzane klawisze, po prostu kolejno
testowane są linie wejściowe. I zależnie od ich stanu wykonywany jest
wskok w określoną procedurę.
Więc naciśnięcie więcej niż jednego klawisza powoduje wejście kolejno
w procedurą X(klawisz x), potem Y(klawisz y) itp.

Nie były stosowane żadne pośrednie zmienne. Po prostu reakcja na
fizyczny stan linii. Poza tym, jak wspomniałem program działa na kilku
urządzeniach przez dłuższy już czas, i nie było z tym problemu.

Tak, że na pewno nie było to problem od strony programu. Dlatego też
, zanim o 6 rano w łóżku wpadłem na rozwiązanie, to przez ileś godzin
gapiłem się w monitor i myślałem "to niemożliwe, to niemożliwe..." :)

Wiem, że to bardzo chyba rzadki przypadek. No, ale skoro taki jest fakt,
to trzeba się z nim pogodzić :)

Teraz wprowadzam modyfikacje w programie, polegające na tym, że
1) klawisz musi być puszczony przez ponowną aktywacją
2) normalnie klawiatura jest "zablokowana", jedynie jeden przycisk
uaktywnia możliwość wpisania hasła , które odblokowuje klawiaturę.
3) wykrycie naciśnięcia więcej niż 1 przycisku wywołuje błąd (zapis w
pamięci zdarzeń, potem autoreset, po 3 takich autoresetach trwałe
wyłączenie).
4) oczywiście zewnętrzne rezystory podciągające.
5) powłoka z EMI-35 połączona z masą zasilania

I myślę, że powinno być ok. Dopóki nie wydarzy się coś innego

Tue Jun 04, 2013 11:05 pm   

Dnia Tue, 04 Jun 2013 17:08:18 +0200, sundayman napisał(a):


a czy mozliwe, ze to nie wina burzy tylko samych stykow przyciskow,
mechaniczna sprawa?

--
jg

Tue Jun 04, 2013 11:25 pm   

Zdaje się, że piny mają wewnętrzne podwieszenie jako weak pull-up.
Wtedy kilkadziesiąt kiloohmów może przeciągnąć do masy.
S.

Tue Jun 04, 2013 11:53 pm   

W dniu 2013-06-04 04:52, sundayman pisze:

Poszukaj w sieci:
EMC Testing Part 3

Wed Jun 05, 2013 12:06 am   

W dniu 2013-06-04 09:19, Piotr Gałka pisze:

Odświeżać powinno się wszystkie rejestry do których piszesz, lub mógłbyś
pisać przy starcie.
Szczególnie dotyczy to układów dołączonych do procka np. konwerterów.
Ale nie zawsze to pomaga. Zrobiłem kiedyś projekt na AD7730 (przetwornik
do mostka tensometrycznego). Układ porażka - strasznie emitował. Dało
się złapać silny sygnał zegara sondą magnetyczną podpiętą do oscyloskopu.
Tak samo mało odporny na zakłócenia. Nadpisywałem jego rejestry po
każdym odczycie. Nie wziąłem jednak pod uwagę, że w jednym rejestrze
kontrolnym jest bit, którego ustawienie wstrzymuje zegar taktujący
logikę. Czasami jak się ten bit zmienił od zakłóceń, to już układ nie
był w stanie przyjąć żadnych komend. Trzeba było przerobić układ tak aby
móc odłączać jego zasilanie.




--
pozdrawiam
MD

Wed Jun 05, 2013 10:51 am   

Kiedys przez przypadek rozladowalem jakies 47-100uF na 400V w TV,
kilka centymetrow dalej byl eeprom, po odczycie programatorem i
porownaniu do oryginalnej binarki, okazalo sie ze wyladowanie moze
wykrzaczyc komorki. Procki sa robione w innej technologii, komorki
pamieci sa jeszcze mniejsze niz w ukladach eeprom za 30groszy.

Wed Jun 05, 2013 2:33 pm   

W dniu 2013-06-05 01:25, Sylwester Łazar pisze:

Mechanicznie - teoretycznie oczywiście możliwe, ale praktycznie nie -
bo, po pierwsze "naciśnięte" było kilka przycisków (a to są porządne
dość switche, nie najtańszy badziew), ale przede wszystkim - problem
ustąpił po wyłączeniu i włączeniu głównym włącznikiem - bez dotykania
innych przycisków.

Co do wilgoci, to znowu - teoretycznie tak, praktycznie nie - po
pierwsze z tego samego powodu co powyżej, po drugie - PCB są
zabezpieczone (lakierem), po drugie obudowa sterownika jest
szczelna (ma IP65 na pewno, albo lepiej) - temperatura jest w środku
mocno dodatnia, więc nic się nie kondensuje (jest rejestracja
temperatury), zresztą brak śladów takiej kondensacji. Sterownik jest jak
napisałem w większej, też dość szczelnej skrzynce.

Tak, że oczywiście - obie możliwości wziąłem pod uwagę - ale w tym
przypadku musiało to być to niezwykłe "odpięcie" podciągających
rezystorów. Zwłaszcza, że o godzinie wystąpienia problemu była tam silna
burza z dużą ilością wyładowań.

Wed Jun 05, 2013 2:48 pm   

[quote]Poszukaj w sieci:
EMC Testing Part 3

Wed Jun 05, 2013 4:33 pm   

Znalazłem taką fajną procedurę odpluskwiania :

(NA http://www.testowanie.net/);

"Metoda gumowej kaczuszki
August 24th, 2012
O metodzie dowiedziałem się za pośrednictwem testerzy.pl Zaznaczam, że
jest ona skierowana do programistów, jednak nic nie stoi na
przeszkodzie, aby zastosować ją przy pisaniu skryptów automatycznych czy
przypadków testowych

Metoda gumowej kaczuszki

Wed Jun 05, 2013 5:28 pm   

sundayman znalazł taką fajną procedurę odpluskwiania :


Wtedy należy użyć metody zmodyfikowanej -- programista tłumaczy linia po
linii panu doktorowi, co każdy segment powinien robić. A w zależności od
tego tłumaczenia, dostaje odpowiednie pigułki.

Jarek

--
Dostal jsem papíry na hlavu
žiju v ústavu
kde se léčí rozum
dělám si co se mi zalíbí
mám pevné alibi
lékařskou diagnózu

Wed Jun 05, 2013 9:41 pm   

W dniu 2013-06-05 19:28, Jarosław Sokołowski pisze:

Obawiam się, że po pigułkach od lekarza koder byłby mało produktywny.
Już lepiej byłoby po pigułach od dilera.


--
pozdrawiam
MD

Thu Jun 06, 2013 9:39 am   

Pan Mario napisał:


Jest czas łowienia ryb i czas suszenia sieci. Do tworzenia kodu są inne
pigułki, do szukania błędów -- inne.

--
Jarek