Zawieszanie i "wysypywanie" sie programu na AVR

Skelen · Postautor: **Skelen** » 2 lut 2004, o 22:36

Czy ktos mial problemy z zawieszaniem sie i wysypywaniem poprawnie napisanego programu na AVR? Zrobilem sterownik ktory steruje dwoma silnikami w tym jeden trojfazowy. AVR lubi sie przy tym zawieszac, to jednak nie jest problem bo watchdog potrafi sobie z tym poradzic. Problem dopiero pojawia sie gdy program sie nie zawiesi ale "wysypie". Zmienne przyjmuja czasami losowe wartosci i AVR zaczyna wtedy "szalec",zachowuje sie nieobliczalnie np. wysyla na wyswietlacz "krzaki",porty przyjmuja nieokreslone wartosci ... Dzieje sie to tylko wtedy gdy wlacza silnik trojfazowy sterowany przez przekaznik z jednej fazy. Przy silnikach jedofazowych wszystko jest ok. - sprawdzilem. I co wy na to ?

gawel · Postautor: **gawel** » 3 lut 2004, o 09:43

Jestem w pełni przekonany, że przyczyn należy szukać w programie. Prawdą jest również, że procesory AVR w obiegowej opinii należą do delikatnych. W swojej praktyce zdarzało mi się narzekać na procesory i kompilatory a pożniej je "przepraszać".

Skelen · Postautor: **Skelen** » 3 lut 2004, o 22:20

Czy zmianę stanu linii portu (ustawionej jako wyjście) spowodowana włączeniem lutownicy,wiertarki czy odkurzacza do sieci można nazwać błędem programu?...

INFEL · Postautor: **INFEL** » 4 lut 2004, o 08:01

Trzeba przeprojektować płytkę
- inaczej poprowadzić cieżki masy
- dodać kondensatory ok. 100n między masš a zasilaniem najbliżej.układu
- dodac filtry na przewodach zasilajšcych (może i sterujšcych)

u mnie pomogło przy 2051 i sterowaniu rygla zamka przez przekanik

gawel · Postautor: **gawel** » 4 lut 2004, o 09:38

Już w jednym miejscu pisałem o tym, tu powtórzę jedynie rzeczy najważniejsze:

KAŻDY CYFROWY UKŁAD SCALONY MUSI MIEĆ SWÓJ KONDENSATOR (TYPOWO 100nF) JAK NAJBLIŻEJ NÓŻEK ZASILANIA, I TO BEZ WYJĄTKÓW.

WSZYSTKIE NIEUŻYWANE WEJŚCIA CYFROWE MUSZĄ MIEĆ WYMUSZONY STAŁY STAN LOGICZNY (NIEWAŻNA JAKI, BYLE BYŁ STAŁY)

NALEŻY POWAŻNIE TRAKTOWAĆ ZALECENIA PRODUCENTA DOTYCZCE GENEROWANIA SYGNAŁU RESET

GasM · Postautor: **GasM** » 4 lut 2004, o 12:14

Zgodze się z kolegami
- kondensator 100nF CERAMIK przy każdym scalaku
- ścieżki masy jak najgrubsze
- kontroler lepiej pracuje jak ściąga sygnał do masy niż do Vcc, mniejsze zakłócenia, stan stabilniejszy na Vcc, dlatego drabinka rezystorowa musi być lub jakiś rezystor jak w okolicach niema innych wyjść
- domyślam się że zastosowałeś ULN2803 miedzy prockiem a przekaźnikami, dlatego musi być rezystor podciągający na kontrolerze bo będziesz miał stany nieustalone przy włączaniu przekaźnika spowodowane dużym obciążeniem przez ULN
- przekaźnik to element indukcyjny i powinien być na innym napięciu, a przy ULN2803 masa Vcc i masa napięcia przekaźnika połączone jak najbliżej scalaka żeby impuls załączanego przekaźnika nie chodził Ci po masach cyfrowych na płytce
- do każdego przekaźnika powinna być dołączona dioda, jak najbliżej jego wyprowadzeń, bez względu na to że ULN2803 ma w sobie już diody!!!!

Co do oprogramowania jeżeli używasz asemblera w przerwaniach to zwróć uwagę w jakiej kolejności odkładasz na stos i z niego ściągasz
to też jest ważne

Skelen · Postautor: **Skelen** » 4 lut 2004, o 22:56

Wszystko ładnie, pięknie wygląda na papierze.To, co napisaliście zastosowałem już na początku, wprowadziłem filtry zasilania i było jeszcze gorzej. Myślę ze to kwestia przeprojektowania układu zasilania i plytki. Dzisiaj wróciłem z pracy a tu kolejny zwis i pamięć eeprom zawalona jakimiś śmieciami. Takich problemów nie miałem jeszcze nigdy. Może ktoś ma jakiś pomysl na skuteczny filtr przeciwzakłóceniowy.

rysiojur · Postautor: **rysiojur** » 5 lut 2004, o 07:21

A może tak:
1.Odepnij driver i przekaźniki.
- zobacz czy program działa na procku bez przekaźników
2. Jaki masz układ resetu ? Jeśli RC to to zamień na Dallasa jeśli na Dallasie to sprawdź czy nie pojawiają się śmieci na resecie.

GasM · Postautor: **GasM** » 5 lut 2004, o 08:32

Wystarczy odpiąć przekaźniki. ale wcześniej sprawdź jaki masz stan na liniach procka przy włączonym przekaźniku przed ULN2803. może się okazać że dałeś za dużą rezystancję drabinki, najlepsza 4,7K.

a sygnał resetu nie sądze żeby miał taki wpływ na procka.

To jest zwykłe EMC

Pozatym podczas pierwszych uruchomień wyłącz watchdoga, da ci pewność w jakich miejscach się będzie zawieszać program. Włączysz go sobie dopiero jak progrog nie będzie sprawiał żadnych problemów.

Program musi działać bez watchdoga!!!

i nie używaj na chwile obecną EEPROM bo nie wiesz ile razy ci do niego zapisuje podczas pracy, potem będziesz musiał zmienić procka. wypłuczesz się zanim to uruchomisz

euromatic · Postautor: **euromatic** » 7 lut 2004, o 20:12

To czasami koszmar.Wszyscy po części macie rację. Ja opiszę wam z czym walczyłem w ubiegłym miesiącu i jak to zwalczyłem.
Wykonałem płytkę urządzonka, Fabrycznie , więc była idealnej jakości pod względem technicznym (fizycznie i tylko...)
na wejściach podciągnięcie do plusa drabinką 2,2 k, diody zenera 5V1
na wyjściach optotriaki MOC załączane w zerze (nie podłączone )
Zasilacz na TDA8137 z resetem, trafo 230/12V
pełno kondensatorów 100nF i innych. I co?
ANO d...pa. Układ reagował nawet na zgaszenie lampki na biurku !!!!!
Resetował się , a czasami wykonywał nieprzewidziane triki.
najgorzej było gdy wyłączane urządzenie miało charakter indukcyjny.. 100 / 100 to reset.
nie pomagało nic, obserwacje na oscyloskopie nie dawały winowajcy....
AVR 8535 resetował się od przekaźnika zbliżonego do niego na odległość 5 cm który był zasilany z oddzielnego akumulatora!!!!( podczas wyłączania)
Może walczyłbym dalej z różnego rodzaju kondensatorkami i ninnymi filtrami ale coś mnie oświeciło......
przypomniałem sobie, że mam zrobione inne urządzonko z takim samym zasilaczem i na takiej samej pod względem wielkości płytce ,z takim samym prockiem i układem wejść.
Druga płytka była nie do zawieszenia, trafo o mocy 300W ze zwartym uzwojeniem wtórnym podłączane do tego samego gniazda zasilania( iskrzenie) nie resetowało układu. nawet zakłócacz z przekaźnika nie był go w stanie powiesić czy zresetować.

kolega zrobił inną płytkę o takim samym schemacie ale inaczej rozmieścił elementy ( zrobił to po swojemu...- amator) i okazało się ,że nowa płytka jest odporna na zakłócenia i pracuje dobrze.
Morał z tego taki,że wina była po stronie płytki drukowanej. Mam za małe doświadczenie w projektowaniu płytek pod Atmela , żeby określić co było przyczyną ale napewno jest zalecany sposób prowadzenia ścieżek w AVR i należałoby to gdzieś odnaleźć.
Zresztą nie tylko w ATMELU ma to zastosowanie , są pewne reguły których trzeba się trzymać.
Zrób więc nową płytkę inaczej rozmieść elementy, nie ciągnij ścieżek równolegle do siebie, rób je najkrótsze. nie rób pętli masy, pociągnij z jednego punktu kilka mas do układów, reset najbliżej procka, wszystkie wolne porty daj na masę i wystaw na nich zero bo jak wystawisz 1 to wzrośnie ci pobór prądu i będzie ci się grzał AVRrek, 10 k na podciągniecie resetu.

Ostatnio kolega Dainius miał taki sam problem, zrobił to co mu poradziłem i rozwiązał problem.
Zmienił płytkę( zrobił ją od nowa i działa...więc to nie program ani kompilator tylko błedy w rozmieszczeniu elementów...)
Pozdrawiam i nie zanudzam Was dalej.

Wojtek · Postautor: **Wojtek** » 8 lut 2004, o 08:07

(...)Mam za małe doświadczenie w projektowaniu płytek pod Atmela , żeby określić co było przyczyną ale napewno jest zalecany sposób prowadzenia ścieżek w AVR i należałoby to gdzieś odnaleźć. (...)

Faktycznie bardzo dużą rolę w odporności układów (nie tylko AVR) na zakłócenia spełnia właściwie zaprojektowany druk. Z mojego doświadczenia wynika że najlepszym rozwiązaniem jest druk 4 warstwowy ale to ma zastosowanie do rozwiązań profesjonalnych, a nie amatorskich. zaprojektowane druki na 4 warstwach przy spełnieniu właściwego rozdziału mas i zasilań i zastosowaniu filtrów są odporne na wszystkie narażenia zawarte w wymaganiach jakie nakładają normy związane z EMC sprawdzałem to porównując badania układu z 8535 na drukach 2 warstwowych i 4 warstwowych. Co nie oznacza że nie można układu zrobić dobrze nawet na 1 warstwie ale to wymaga prób i doświadczenia lub zupełnego przypadku

Na stronie Atmela można zanaleźć trochę wskazówek np tu http://www.atmel.com/dyn/resources/prod ... oc1619.pdf ale autorzy sami piszą że nic nie zastąpi metody prob i błędów.

Również cenne wskazówki są tu http://www.atmel.com/dyn/resources/prod ... oc2521.pdf Polecam również lekturę artykułów Piotra Góreckiego w EDW dotyczących zakłóceń (trwa to od 7 numerów).

GasM · Postautor: **GasM** » 9 lut 2004, o 09:59

odnośnie postu Wojtka - napisał byś jakie konkretne numery EDW, z EMC trzeba żyć w zgodzie

Wojtek · Postautor: **Wojtek** » 9 lut 2004, o 18:07

odnośnie postu Wojtka - napisał byś jakie konkretne numery EDW, z EMC trzeba żyć w zgodzie

Są to numery 6,7,8,9,12/2003 oraz 1,2/2004 i jeszcze będzie temat kontynuowany.

Zawieszanie i "wysypywanie" sie programu na AVR

Zawieszanie i "wysypywanie" sie programu na AVR

Były już porady na ten temat.

to nie żaden problem...

Re: to nie żaden problem...

Kto jest online