W dniu 2013-06-04 10:26, Piotr Gałka pisze:
>
> Użytkownik "Zbych" <a...@o...pl> napisał w wiadomości
> news:51ad9d43$0$1261$65785112@news.neostrada.pl...
>>>
>>> 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.
>>
>> Jakoś nie chce mi się wierzyć, żeby zakłócenie przestawiło
>> konfigurację portów i nie wykrzaczyło rdzenia procesora.
>>
> 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.

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

do góry

Użytkownik "Zbych" <a...@o...pl> napisał w wiadomości
news:51adafa3$0$1262$65785112@news.neostrada.pl...
>>>
>>> Jakoś nie chce mi się wierzyć, żeby zakłócenie przestawiło
>>> konfigurację portów i nie wykrzaczyło rdzenia procesora.
>>>
>> 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.
>
> 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/1
1/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.
>
Nie wiem co chcesz powiedzieć.
P.G.

do góry

W dniu 2013-06-04 11:34, Piotr Gałka pisze:
>
> Użytkownik "Zbych" <a...@o...pl> napisał w wiadomości
> news:51adafa3$0$1262$65785112@news.neostrada.pl...
>>>>
>>>> Jakoś nie chce mi się wierzyć, żeby zakłócenie przestawiło
>>>> konfigurację portów i nie wykrzaczyło rdzenia procesora.
>>>>
>>> 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.
>>
>> 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/1
1/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.
>>
> Nie wiem co chcesz powiedzieć.

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.

do góry

Użytkownik "Zbych" <a...@o...pl> napisał w wiadomości
news:51adb6a8$0$1260$65785112@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.
>>>
>>> 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/1
1/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.
>>>
>> Nie wiem co chcesz powiedzieć.
>
> 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.
>
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.

do góry

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

do góry

Najdziwniejsza była malutka dziurka jaka
> została wypalona w obudowie. Była ona wykonana z balchy s
>
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.

do góry

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

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

do góry

> Zamówiłem już EMI-35, ciekawe na ile toto rzeczywiście zaekranuje
> obudowę z tworzywa...
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.

do góry

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

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

do góry

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

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

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

--
jg

do góry