Burza i kłopoty w MCU...

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Polish to

Threaded View
Chciałbym prosić kolegów o uwagi w następującym problemie;

jest otóż urządzenie (sterownik uruchamiający pewną pompę). Sterownik  
jest zrobiony w oparciu o atmegę128. Posiada graficzny LCD, klawiaturę  
sterującą, jakieś elementy wykonawcze.

Zasilanie urządzenia jest z panela słonecznego , przez specjalny układ  
ładowania (fabryczny) , ładujący 2 akumulatory 12V, czyli nominalne  
zasilanie to 24V, choć zmienia się ono i czasem sięga 30V.
Sam sterownik ma 2 przetwornice, jedna daje 12V do zasilania różności, i  
potem druga 5V do zasilania MCU itp. Działa poprawnie w zakresie 10-40V  
, powyżej tego napięcia zasilanie się odcina.

Sterownik jest w plastykowej obudowie, z aluminiowym frontem, całość z  
kolei w dużej plastykowej "skrzyni" typu szafa telekomunikacyjna, która  
stoi sobie na ulicy.

Oprogramowanie oczywiście posiada watchdog, i możliwe zabezpieczenia  
typu zapisywanie istotnych danych w pamięci nieulotnej procesora  
"nadmiarowo", czyli w 5 kopiach, i porównywanie w razie wykrycie zmian.

Tyle tytułem wprowadzenia.
I otóż ostatnio wydarzyła się następująca rzecz;

Podczas intensywnej burzy, zapewne na skutek silnego wyładowania gdzieś  
w pobliżu MCU "ocipiał", w ten sposób, że odnosił wrażenie, że  
naciśnięte są naraz 2 klawisze sterujące (są one zrealizowane normalnie  
jako zwierające do masy, podpięte bezpośrednio pod linie MCU,  
zablokowane kondensatorkami 100nf. Co ważne - z użyciem wewnętrznych  
(MCU) rezystorów podciągających do 5V).

Uderzenie nastąpiło gdzieś w pobliżu - nie bezpośrednio w jakiś element  
instalacji - ot, po prostu gdzieś blisko. Czyli coś się musiało  
"wyindukować" w układzie.

Czyli - jakiś cudem nastąpiło "odpięcie" tych wewnętrznych rezystorów  
podciągających klawiaturę, i program wykonywał w kółko polecenia, jak  
gdyby ktoś stał i cały czas trzymał naciśnięte przyciski...

Nie zadziałało żadne zabezpieczenie typu watch-dog, bo program w sumie  
działał poprawnie , tyle, że w "wirtualnej rzeczywistości".

Oczywiście, będę musiał wprowadzić dodatkowe zabezpieczenia w programie,  
ale zastanawiam się, jak zapobiec problemowi bardziej "hardwareowo".

Oczywiście zastosuję zewnętrzne rezystory podciągające. Dobrze by było  
zamienić obudowę na metalową, uziemioną. No ale to jest na razie problem  
- czy jakoś może się sprawdzić ekranowanie poprzez pomalowanie wnętrza  
obudowy preparatem w rodzaju "miedź w aerozolu" ?

Czy macie jakieś sposoby na testowanie takich zakłóceń ? jakiś iskrownik  
czy coś ?

Jak wspomniałem, zasadniczo cały system jest elektrycznie izolowany -  
nie jest w sumie nawet uziemiony chyba - zapewne lepiej jest całość  
jakoś uziemić ?

Może jakieś inne sprawdzone sposoby "ochrony" przed silnymi zakłóceniami  
EM ?

Re: Burza i kłopoty w MCU...

Quoted text here. Click to load it

Sam sobie odpowiedziałes> Metalowa puszka i uziemienie.

Re: Burza i kłopoty w MCU...
W dniu 2013-06-03 20:01, sundayman pisze:

Quoted text here. Click to load it

Znaczy strzeliły wejścia - nic szczególnego jak niezabezpieczone. Jak  
tylko przestały reagować to i tak dobrze - bo mogły się po prostu upalić.

Quoted text here. Click to load it

Żadne cuda - pieprznęło dobrze, jak było blisko i masz dużą powierzchnię  
pętli kondensator - procesor to popłynął spory prąd. Nie wiem jaką masz  
topologię układu, ale łatwo tu zrobić błąd. Jak masz taki problem, to  
rozważ zewnętrzny rezystor podciągający.

Quoted text here. Click to load it

Przed takim problemem programowo się nie zabezpieczysz (przynajmniej  
porządnie - zapewniając funkcjonowanie urządzenia).

Quoted text here. Click to load it

Pewnie, że może pomóc. Ale lepiej sprawdzi się dobrze zaprojektowany  
schemat i PCB.

Quoted text here. Click to load it

No, laboratorium na CE. Aż żal się robi, co oni z urządzeniami  
wyprawiają. Jak strzelali w wejścia sygnałowe, to na stojącym na tym  
stole notebooku (na drugim końcu) ekran pokazywał różne rzeczy, ale nie  
to, co miało tam być.
Podają 1kV przez 1uF i 40 omów (to ładnych parę amperów jest), plus i  
minus, przy założeniu, że kable mogą mieć więcej niż 30m. Ale to i tak  
bardzo dobry test, nawet jak kable będą krótsze. Do tego taki fajny  
pistolet strzelający chyba 4kV czy coś koło tego, ale małym prądem, i  
facet dotyka tym wszystkich dostępnych metalowych elementów - to z  
każdym urządzeniem.

Quoted text here. Click to load it

Lepiej dobrze przemyśleć co i gdzie popłynie - czasem lepiej samemu  
"przygotować drogę" prądowi. Prąd i tak sobie drogę znajdzie.

Quoted text here. Click to load it

Zabezpieczenie wejść, i jeszcze na dodatek wolnych, to nie problem.  
Transil, dobrze policzone oporniki i przemyślany rozpływ prądów (w  
scalakach generalnie masz podany maksymalny prąd wejścia). I jeszcze  
trzeba uwzględnić przepływ prądu przez rezystory podciągające, może  
lepiej dodać je na zewnątrz. Można też inaczej - szybkie diody do  
zasilania i masy, o ile kondensator na zasilaniu jest w stanie taki  
impuls przyjąć na siebie. Można też dodać transil, ale to przy wyższych  
napięciach. No i dobrze poprowadzić masę i ścieżki przewodzące prąd  
udarowy.
A tak poza wszystkim - mogło też pójść po zasilaniu.

Pozdrawiam

DD

Re: Burza i kłopoty w MCU...
Hmmm...
Czyli na razie (w urządzeniach , które już są) zastosuję ekranowanie  
obudowy z tworzywa preparatem EMI 35, dołożę zewnętrzne rezystory  
podciągające, i dodam zabezpieczenie w software, nie pozwalające na  
korzystanie z klawiatury "z palca", a z użyciem podania najpierw hasła.

Dodam też wymuszone sprzętowo resetowanie co - powiedzmy - godzina.
W ogóle, na zasilaniu i wejściach czujników (są one w tej samej  
skrzynce, więc niedaleko) są warystory oraz transile. No ale to  
rzeczywiście na wypadek jakiegoś poważnego przepięcia, jak dotąd się to  
nie zdarzyło...

Zastanawiam się, jak by sobie sprokurować jakieś "działko"  
elektromagnetyczne, czyli coś, co by generowało silny impuls EM (bez  
elektrycznego kontaktu) ?

Re: Burza i kłopoty w MCU...

Quoted text here. Click to load it

Przetwornica do CCFL dobrze się sprawdza (tyle że nie ma nic wspólnego  
z normami). Możesz też kupić paralizator.

--  
"zanim nastala era internetu, kazdy wiejski glupek siedzial w swojej wiosce"
http://www.chmurka.net/

Re: Burza i kłopoty w MCU...

Quoted text here. Click to load it

Wiele lat temu widziałem taką listę wytycznych (chyba ST) jak powinien być  
napisany program pracujący w środowisku zakłóconym. Było chyba ponad 20  
punktów. OIDP jedną z wytycznych było, aby w pętli głównej w koło odświeżać  
konfigurację portów (np. wejście zamienione przez zakłócenie na wyjście nie  
zobaczy już sygnału), no bo w końcu co tu robić jak się nic nie dzieje.

Quoted text here. Click to load it

Do ESD używam: "Piezo zapalarka do gazu EWA". Kosztowała około 10zł (był rok  
2002).
Środkowy przewód przedłużyłem poza metalową osłonę i zaizolowałem tak kilka  
mm przed nią (jak nie skoczy na zewnątrz to skoczy do osłony).
Osłonę kablem wyprowadziłem do tyłu.
Generowana iskra oczywiście nie tak powtarzalna jak w pistolecie ESD, ale  
efekt bardzo zbliżony.

Słyszałem, że do Burst dobrze się sprawdza przekaźnik/stycznik podłączony na  
ciągłe iskrzenie, ale nie mam takiego przyrządu.

Do Surge używam szarych komórek - to są z punktu widzenia elektroniki  
powolne sygnały - czasy narastania liczone w us więc przewidywalne. Nie  
znalazłem nigdzie informacji, czy taki mały 0603 ferryte bead wytrzyma Surge  
(tę wersję przez 40om). W ramach eksperymentu przepuściłem przez niego  
impulsy 100us 25A (MOSEM z elektrolita) - wytrzymał.
P.G.  


Re: Burza i kłopoty w MCU...
Quoted text here. Click to load it

Może u sundaymana wyłączyły się te rezystory podciągające i dodając  
odświeżanie ich konfiguracji uniknie się dolutowywania zewnętrznych.

--  
Grzegorz Niemirowski
http://www.grzegorz.net/
We've slightly trimmed the long signature. Click to see the full one.
Re: Burza i kłopoty w MCU...
W dniu 04.06.2013 09:42, Grzegorz Niemirowski pisze:
Quoted text here. Click to load it

Jakoś nie chce mi się wierzyć, żeby zakłócenie przestawiło konfigurację  
portów i nie wykrzaczyło rdzenia procesora.


Re: Burza i kłopoty w MCU...

Quoted text here. Click to load it
Nie mam pojęcia co się faktycznie dzieje.
Mój model zakłócenia (nie mam argumentów aby go bronić) to przekłamanie od 1  
do n bitów w rejestrach.
Jak 1 to dlaczego nie akurat w porcie i rdzenia nie wykrzaczy.
P.G.  


Re: Burza i kłopoty w MCU...
W dniu 2013-06-04 10:26, Piotr Gałka pisze:
Quoted text here. Click to load it

I działa to na sferycznych krowach zawieszonych w próżni? :-)

Ja wolę spojrzeć na zdjęcia krzemu.

http://www.extremetech.com/wp-content/uploads/2012/11/atmel-ATmega8-8-bit-controller-die-shot.jpg

Komórki IO są zazwyczaj na krawędzi, ale już rejestry nimi sterujące są  
bliżej rdzenia. I całość ma pewnie 5..10mm2.



Re: Burza i kłopoty w MCU...

Quoted text here. Click to load it
http://www.extremetech.com/wp-content/uploads/2012/11/atmel-ATmega8-8-bit-controller-die-shot.jpg
Quoted text here. Click to load it
Nie wiem co chcesz powiedzieć.
P.G.  


Re: Burza i kłopoty w MCU...
W dniu 2013-06-04 11:34, Piotr Gałka pisze:
Quoted text here. Click to load it
http://www.extremetech.com/wp-content/uploads/2012/11/atmel-ATmega8-8-bit-controller-die-shot.jpg
Quoted text here. Click to load it

To, że przy takich rozmiarach ciężko jest selektywnie zakłócić wybraną  
część procesora. Do tego rdzeń, który non stop mieli dane jest dużo  
bardziej wrażliwy na zakłócenia, niż rejestr sterujący IO, do którego  
magistrala jest aktywowana raz na jakiś czas.





Re: Burza i kłopoty w MCU...

Quoted text here. Click to load it
http://www.extremetech.com/wp-content/uploads/2012/11/atmel-ATmega8-8-bit-controller-die-shot.jpg
Quoted text here. Click to load it
Zgadzam się w sensie, że jak się chce celowo, selektywnie zakłócić to trudno  
to zrobić.
Ale efekt prawdziwego zakłócenia może być bardzo różny i żadnego według mnie  
nie można wykluczać.
Jeśli zakłócenie przewodzone to najpierw trafia w porty.
Jeśli zakłócenie radiowe to porty mają najlepsze anteny do jego odbioru.
Ja jedynie bronię tezy, że każdy efekt zakłócenia jest możliwy i chyba nic  
nie broni zakłóceniu zakłócić akurat tych elementów, które nie mają wpływu  
na rdzeń.
Zgadzam się z tym, że rejestr zmieniający akurat stan jest bardziej podatny  
na zakłócenie, ale przez to, że moim zdaniem port jest narażony w pierwszej  
kolejności to nie wykluczam możliwości, ze port zostanie zakłócony bez  
zakłócenia rdzenia.

W czasach gdy jeszcze nic nie wiedziałem o EMC, ESD, Surge (połowa lat  
90-tych) zdarzyła się instalacja naszego systemu w centrum rozległego  
wzniesienia. Co przychodziła pora burz to w tej jednej instalacji zdarzały  
się problemy - wystarczyło off/on zasilania i już działało. Poprosiłem, aby  
po awarii nie resetowali tylko wezwali.
Rozebrałem urządzenie nie wyłączając prądu i udało mi się ustalić co jest  
źle - robił się latch-up w jednym scalaku (doszedłem po spadkach napięć na  
ścieżkach GND). Nie potrafię teraz dokładnie odtworzyć wszystkich  
szczegółów. Latch-up jest chyba problemem portów IO a nie czegoś głębiej. To  
tylko przykład.

Tematem wątku jest burza. Burza to Surge, a nie ESD. Surge jest powolny -  
raczej nie zakłóca poprzez di/dt tylko przez przepływ za dużych prądów  
(akurat latch-up może być typowym efektem). Czy może wyłączyć podwieszenia  
pinów - nie mam pojęcia.
P.G.


Re: Burza i kłopoty w MCU...

Quoted text here. Click to load it
Oglądałem kiedyś uszkodzenie jakie wywołało pobliskie wyładowanie  
atmosferyczne. Urządzenie stało na metalowym uziemionym parapecie. Do  
niego podłączone było kilkadziesiąt metrów kabla do głośników. Od  
gniazdka gdzie był podłączony ten kabel przez środek urządzenia  
przeskoczyła iskra (na odległość 8 cm !). Małe elementy jakie znalazły  
się na jej drodze wyparowały. Najdziwniejsza była malutka dziurka jaka  
została wypalona w obudowie. Była ona wykonana z balchy s


Re: Burza i kłopoty w MCU...
  Najdziwniejsza była malutka dziurka jaka
Quoted text here. Click to load it
Przez przypadek wysłałem zbyt szybko wiadomość...

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.

Re: Burza i kłopoty w MCU...
Quoted text here. Click to load it
konfigurację
Quoted text here. Click to load it


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.


Odp: Burza i kłopoty w MCU...
Quoted text here. Click to load it
Wróżenie z fusów.
Jeśli to wyładowanie spowodowało, to niczym się nie da zabezpieczyć.
Poziom energii jest tak wielki, że w przypadku wyładowania w pobliżu,
coś musi się zepsuć. Jeśli się tylko powiesił, to
można zrobić silnik, którego oś załącza krańcówkę i  resetuje co obrót wału
mikrokontroler.
Żartuję :-)
Ja bym sprawdził:
a) Czy nie ma błędu w programie,
Zbieg okoliczności mógł nastąpić, że wyszło to podczas burzy
b) Czy czynnik ludzki zadziałał,
c) niedolutowany pin resetu, zasilania, przycisku itp. na płytce.

Miałem taki przypadek, że podejrzewałem (niesłusznie) o zakłócanie
urządzenia RCP.
Okazało się, że był zimny lut na układzie RESETU.

Po przylutowaniu - wszystko działało o.k.
S.


Re: Burza i kłopoty w MCU...

Quoted text here. Click to load it

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!        Uzas24%.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!        Uzas24%.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...




Odp: Burza i kłopoty w MCU...
Quoted text here. Click to load it
To nie pomoże.
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.


Re: Burza i kłopoty w MCU...

Quoted text here. Click to load it


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


Site Timeline