Burza i kłopoty w MCU...

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 ?

Reply to
sundayman
Loading thread data ...

Sam sobie odpowiedziałes> Metalowa puszka i uziemienie.

Reply to
LeonKame

W dniu 2013-06-03 20:01, sundayman pisze:

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

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

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

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

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.

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

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

Reply to
Dariusz Dorochowicz

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

Reply to
sundayman

Użytkownik "sundayman" snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news:koilv9$p9s$ snipped-for-privacy@news.task.gda.pl...

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.

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.

Reply to
Piotr Gałka

Piotr Gałka snipped-for-privacy@cutthismicromade.pl napisał(a):

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.

Reply to
Grzegorz Niemirowski

W dniu 04.06.2013 09:42, Grzegorz Niemirowski pisze:

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

Reply to
Zbych

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.

Reply to
Sylwester Łazar

Użytkownik "Zbych" snipped-for-privacy@onet.pl napisał w wiadomości news:51ad9d43$0$1261$ snipped-for-privacy@news.neostrada.pl...

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.

Reply to
Piotr Gałka

W dniu 2013-06-04 10:26, Piotr Gałka pisze:

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

Ja wolę spojrzeć na zdjęcia krzemu.

formatting link
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.

Reply to
Zbych

Użytkownik "Zbych" snipped-for-privacy@onet.pl napisał w wiadomości news:51adafa3$0$1262$ snipped-for-privacy@news.neostrada.pl...

Nie wiem co chcesz powiedzieć. P.G.

Reply to
Piotr Gałka

W dniu 2013-06-04 11:34, Piotr Gałka pisze:

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.

Reply to
Zbych

Użytkownik "Zbych" snipped-for-privacy@onet.pl napisał w wiadomości news:51adb6a8$0$1260$ snipped-for-privacy@news.neostrada.pl...

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.

Reply to
Piotr Gałka

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

Reply to
pawel2420

Najdziwniejsza była malutka dziurka jaka

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.

Reply to
pawel2420

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

Reply to
sundayman

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.

Reply to
Sylwester Łazar

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

Reply to
sundayman

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?

Reply to
jg

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

Reply to
Sylwester Łazar

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.