Zachowanie mikrokontrolera po resecie - zgodność z oznakowaniem CE w EMC?

Fri Feb 09, 2007 9:26 pm   

Witam ponownie,

Przygotowuję układ do badań na EMC.
W urządzeniu znajduje się mikrokontroler.
Chciałem zapytać, jak powinien zachować się
układ, gdy na skutek odziaływań zewnętrznych
program się zawiesi, bądź zgłupieje?
W chwili obecnej mam watchdog, który resetuje
mikrokontroler. Jednak, po takim resecie, system
nie będzie już działał poprawnie, bo skasowaniu
ulegną np. liczniki programowe w mikrokontrolerze.
Zatem reset taki spowoduje, że układ zacznie
wariować -- maszyna będzie w innym położeniu
mechanicznym, niż wskazywałyby liczniki w programie.
Jestem w stanie, po wykonaniu resetu przez
watchdog zatrzymać maszynę, którą steruje mikrokontroler,
ale na pewno nie jestem w stanie kontynuować pracy,
jakby nigdy nic.
Czy takie zachowanie (polegające na resecie układu
i zatrzymaniu maszyny) będzie zgodne z duchem norm i dyrektyw
stojących za oznakowaniem CE? ;)

Pozdrawiam,
Robot

Fri Feb 09, 2007 10:29 pm   

R.K.

Sat Feb 10, 2007 11:18 am   

Witajcie

Po pierwsze musisz próbować tak zaprojektować elektronikę aby zminimalizować
wnikanie zakłóceń zewnętrznych.
Proponuję Ci aby przetestować dla siebie urządzenie pod kontem reakcji na
zakłócenia. Robiliśmy to wypożyczonym pistoletem a także metodami
uproszczonymi jak zapalarką do gazu.
Pistolet profesjonalny umożliwia definiowanie między innymi energii
zakłócenia. Co ciekawe zdaża się że zakłócenie o niższej emergii może
powodować inne problemy niż mocjiejsze.

Zwróć uwagę na obszar zastosowań urządzenia. przemysł / motoryzacja / biuro.
To wpływa na sposób kontroli na EMC

Po drugie w programie powinieneś zapewnić zapamiętanie stanu istotnych
zmiennych po ich modyfikacji w pamięci niezależnej od zasilania. Logika
programu powinna mieć na celu również zamaskowanie efektów zadziałania WDT.
Projektowałem urządzenie pomiarowe wymagające zatwierdzenia typu, pracujące
z wyjątkowo podłych warunkach. Częste składowanie i odtwadzanie nie
pogorszyło właściwiści metrologicznych

Co do dyrektywy maszynowej, niedopuszczalne są niespodziewane,
niekontrolowane ruchy maszyny.

Powodzenia

RomanF



Użytkownik "Robot" <Robot_nie_mam_maila@hotmail.com> napisał w wiadomości
news:eqilfi$mee$1@atlantis.news.tpi.pl...

Sat Feb 10, 2007 11:45 am   

Robot napisał(a):

Przecież reset nie powoduje automatycznie kasowania pamięci. Sprawdzasz
stan pamięci (komórek testowych) i jeśli są prawidłowe to robisz gorący
restart i omijasz inicjalizację liczników. Jeśli zawartość pamięci jest
nieprawidłowa to robisz zimny restart i czyścisz pamięć.


--
Pozdrawiam
MD

Mon Feb 12, 2007 5:41 pm   

Dziękuję za odpowiedzi.

Urządzenie będzie w dodatkowej metalowej
szafie i zasilanie będzie przez UPS.

Piszesz, że urządzenie ma maskować działanie
watchdoga. A co, jeśli urządzenie steruje procesem
czasu rzeczywistego i zanik zasilania i tak spowoduje
przerwanie procesu, bez możliwości kontynuacji
po włączeniu zasilania?

Chodzi o to, że z tego co piszesz, wynika, że urządzenie
ma działać, po włączeniu zasilania, od takiego stanu,
jaki miało przed zanikiem zasilania. Ok, rozumiem.
Ale u mnie przerwa w zasilaniu, powoduje, że cały
proces się rozsypuje.

Robot

Mon Feb 12, 2007 9:39 pm   

Użytkownik "Robot" <Robot_nie_mam_maila@hotmail.com> napisał w wiadomości
news:eqq5hu$n4n$1@nemesis.news.tpi.pl...

To są tzw. "siły wyższe" . Ten fragment może cię nie interesować. Maszyna ma
się po powrocie zasilania nie popsuć, ani niczego nie uszkodzić.
Najbardziej prawdopodobne jest zgłupienie mikroprocesora od czegokolwiek,
choćby od załączenia jakiegoś "zakłócacza" (lutownica transformatorowa,
spawarka TIG, potężny silnik, stycznik , nadajnik radiowy itp.), czy błędów
w programie. Lepiej, żeby maszyna stanęła, zamiast wykonywać
nieskoordynowane ruchy "powrotu do zera".

Mon Feb 12, 2007 9:46 pm   

Mariusz Dybiec napisał(a):

zmiennych, lub przeczytac zawartosc ich komorek w ram przed inicjalizacja?

Pozatym pomysl co prawda moze i wyglada dobrze, ale nie ryzykowalbym
wznawiac procesu wg danych w ramie/rejestrach procesora, ktory poszedl w
maliny (bo przeciez cos ten reset spowodowalo). Jesli program sie
zawiesil, i to spowodowalo zadzialanie watchdoga - to znaczy ze jakas
komorka pamieci miala zla wartosc (np okreslajaca adres skoku), lub
nastapil blad odczytu kolejnego rozkazu z pamieci programu (i tez
niewiadomo co ten rozkaz zrobil z ramem). Tak czy inaczej dane w ramie
sa conajmniej niepewne a rejestry procesora chyba sa zawsze czyszczone
harwarowo. Moze gdyby zastosowac 'backup' komorek ramu co jakis czas i
trzymanie ich kopii wraz z crc rowniez w ramie (lub dataflash, jak
miejsce i czas pozwala), to by sie dalo przywrocic stan sprzed resetu.

--
| Bartlomiej Kuzniewski
| sibi@drut.org GG:23319 tel +48 696455098 http://drut.org/
| http://www.allegro.pl/show_user_auctions.php?uid=338173

Mon Feb 12, 2007 10:13 pm   

BartekK napisał(a):

Przyznam, że nie wiem bo dopiero zaczynam w C ale może jakaś wstawka
asemblerowa w boot.s czy startup.c?


Nie chodzi ci o cały ram tylko o kilka liczników, które możesz
przechowywać w wydzielonej części ramu. Możesz zawartość zabezpieczać
checksumą. Jeśli przy restarcie checksuma będzie zła to znaczy, że dane
nie zachowały integralności.

Moze gdyby zastosowac 'backup' komorek ramu co jakis czas i

Musiałbyś pisać do flasha przy każdym ruchu a flash wytrzymuje chyba
1Mcykli zapisu. Najlepiej dać enkodery absolutne i zawsze przy restarcie
sprawdzać położenie.



--
Pozdrawiam
MD

Tue Feb 13, 2007 8:59 am   

Mon, 12 Feb 2007 22:13:43 +0100, na pl.misc.elektronika, Mariusz Dybiec
napisał(a):


Jest do tego gotowa sekcja noinit - zmienne oznaczone tym atrybutem nie są
automatycznie zerowane . Do tego flagi rodzaju restartu, zeby wiedzieć
kiedy nadać początkowe wartości - np.
.....
if (MCUSR & _BV(PORF))
{
// włączenie zasilania
// tutaj zerujemy wszystkie indeksy rejestracji i wskaźniki stanu
urządzenia,
// które przy resecie watchdoga są utrzymywane jako zmienne NOINIT
MCUSR &= ~_BV(PORF);
// skasowanie flagi poziomem niskim
WatchdogCounter=0;
LiveTime=0;
PendingFlags.Byte=0; // wyzerowanie flag trwania procesów
EepromPendingFlags.Byte=0; // wyzerowanie flag zapisu do
pamięci
SysFlags.Byte=0; // wyzerowanie flag systemowych
IdleFlags.Byte=0; // wyzerowanie flag trybu uśpienia
PrevMeaState=btnReleased;
PrevRecState=btnReleased;
PENDING_PWR_ON=true;
SysState=stIdle;
PrevSysState=stIdle;
wdt_enable(WDTO_120MS);
BeginTime.year=0;
BeginTime.month=0;
BeginTime.day=0;
BeginTime.SecInDay=0;
RecTimeCounter=0;
ResetRec();
READY_TO_IDLE=true;
}


--
Pozdrowienia
Jurek Szczesiul

Wed Feb 14, 2007 12:12 am   

Jurek Szczesiul napisał(a):

Interesujące. Byłbym wdzięczny gdybyś napisał jeszcze jak coś takiego
wygląda dla ARMa np LPC2148.

--
Pozdrawiam
MD

Wed Feb 14, 2007 12:52 pm   

Panowie,

Wszystko ładnie... możemy kontynuować proces
po resecie spowodowanym przez watchdog.
Ale, jak sami zauważyliście, istnieje możliwość,
że "liczniki", na skutek zakłóceń, uległy zamazaniu
i wtedy lipa. Możemy trzymać ważne dane poza
kontrolerem, ale co się stanie, jeśli zakłócenia
dosięgną i tamte dane.
Chodzi mi o to, co w zgodzie z duchem CE
powinien zrobić układ, jeśli po prostu nie da się
kontynuować po ustaniu zakłócenia.
A co jeśli mamy np. proces czasu rzeczywistego
i zakłócenia paraliżują układ na jedną krytyczną
sekundę i cały proces się rozsypuje... wznowienie
działania po ustaniu zakłóceń nie ma już sensu
-- z czymś takim ja mam do czynienia.
Wydaje mi się, że dobrym rozwiązaniem byłoby
wtedy zatrzymanie procesu, a nie nieudolna
próba kontynuacji. Jak uważacie?
Oczywiście należy starać się, aby zakłócenia
określone normami nie wpływały na działanie
urządzenia, ale jeśli już, to co robić?

Pozdrawiam
Robot

Wed Feb 14, 2007 5:25 pm   

Robot napisał(a):

Zapisuj z checksumami.


Dlatego rozróżnia się restart z utratą kontekstu (zimny) od restartu z
zachowaniem kontekstu (gorący). Tak masz np w sterownikach PLC.
Wystarczy w obsłudze zimnego dać np postój, włączenie syreny i
oczekiwanie na wciśnięcie klawisza parkowania. Jak robisz na własnym
układzie z mikrokontrolerem to musisz sam zdecydować co oznacza utrata
kontekstu. Dlatego musisz wydzielić dane programu istotne dla pracy
maszyny i sprawdzać ich integralność (zachowanie kontekstu) i chronić
przed wyczyszczeniem gdy nie są uszkodzone. A pozostała pamięć w tym
rejestry procesor ulegają wyczyszczeniu przy resecie.

Jeszcze na temat: jak ma się zachować urządzenie w trakcie badań,
chociaż zaraz pewnie poprawią mnie ci, którzy się na tym znają
W zależności od tego jaką normę zastosujesz, urządzenie elektroniczne ma
kontynuować pracę w trakcie zakłóceń albo jedynie odzyskać sprawność po
ustaniu zakłóceń. Pewnie to jaką normę EMC zastosujesz zależy od tego
jakie normy maszynowe musisz spełnić.

Jeśli masz obawy że nie będziesz w stanie zrobić tego dobrze na
mikrokontrolerze to zastanów się nad zastosowaniem sterownika PLC.

--
Pozdrawiam
MD

Thu Feb 15, 2007 3:19 pm   

Dzięki za odpowiedź.


czy dane w mikrokontrolerze i dodatkowej pamięci
uległy zniekształceniu. Powiedzmy, że okazało się,
że wszystkie moje zabezpieczenia (dodatkowa pamięć
niezależna od zasilania) poległy pod wypływem zakłóceń
i nie mam szans kontynuować normalnej pracy
maszyny. Rozumiem, że wtedy powinienem nie dopuścić
do tego, aby maszyna zaczęła wykonywać niekontrolowane
ruchy -- to jestem w stanie zapewnić, ale raczej nie można
oczekiwać, że będę kontynuował pracę, po tak dotkliwych
zakłóceniach, jakby nigdy nic.

Pozdrawiam
Robot

Thu Feb 15, 2007 6:11 pm   

On Thu, 15 Feb 2007 15:19:25 +0100, Robot wrote:

Otoz to. Jesli robisz termostat do pieca, to od biedy mozna zalozyc
ze jesli suma kontrolna sie zgadza, to nastawa jest poprawna.
Odczytujemy i termostatujemy.

Jak juz piszesz "maszyna" .. to najrozsadniejsze sie chyba wydaje
zapalenie alarmu, wylaczenie i wlaczenie hamulcow.

A i tak trzeba uwazac zeby jakas zapalniczka i komorka nie spowodowala
obciecia palcow mechanika .. lub poparzenia :-)

J.