ATmega8 - Problemy z resetem i programowaniem w prototypach SMD

Witam
Mam problem z uC ATmega8
Wykonałem sobie 2-3 prototypy układów i zawsze testowanie kończy się na wywaleniu płytki do kibla.

np. dziś uszkodził mi się reset tzn. układ cały czas był w trybie programowania i tylko zwarcie rst z 5V przynosiło chwilowy efekt.
Oczywiście rst podciągnięty do vcc przez 10k ohm.

zdarza się że układ zaprogramowany kilka razy nie chce programować się dalej

Ręce mi już opadają bo szkoda kasy na scalaki które wogóle nie spełniają swoich zadań.
Wywaliłem dziś w kibel PCB za 40zł bo układ po pierwszych udanych próbach przestał działać a scalaka trudno później wylutować (używam SMD)

Stabilizatorów używam zwykle TLV1117 (SPX1117) w wersji 5V
Kilka kondensatorków 100n i na we i wyjściu zasilania jakiś większy elektrolit

Czemu moge mieć takie problemy? Czy to normalne?
pozdr

Ja spaliłem tylko jeden uP (na jakieś kilkadziesiąt prototypów, zresztą uP dostał 12V na zasilaniu ). Róźnica jest taka , że robię wszystko na rodzinie '51 gdzie budowa portów jest nieco inna jak w AVR'ach i trudniej jest je przypadkowo uszkodzić podczas uruchamiania układów. Jeżeli masz problem z zaprogramowaniem (ponownym) to może problem jest z przypadkowym ustawieniu fusebitów w uP?

Zdecydowanie nie jest to normalne, jakoś inni korzystają z rodziny AVR i nie mają takich problemów, najpewniej masz jakiś błąd w programatorze, na płytce, albo używasz nieprawidłowego zasilacza.

Dziś przez noc zostawiłem włączony działający układ.
Następna ATmega8 idzie w kibel, uszkodził się reset - tzn. podłączyłem go przez 100k czyli max z noty.
I znów coś się schrzaniło...
Jak wrócę do domu prześlę schemat pozdr

na 100% nie jest to ani chłam ani norma

czy dobrze rozumiem? Wg ciebie procek zostaje uszkodzony nie w wyniku programowania tylko podczas już normalnej pracy w układzie tak???? czyli jak piszesz wyżej włączyłeś go na noc - działał ok a jak się obudziłeś to już nie "żył" ??? tak?

... właśnie pokaż schemat - bo może się zaraz okaże, że coś jednak nie tak jest jeśli chodzi o obciążenie pinów (np za duże) itp ... łatwiej będzie może coś pomóc - bo są to wbrew twoim uwagom świetne procki, i naprawdę mi się też nie zdarzyło jeszcze aby sam z siebie procek padł. Też raz tylko przy programowaniu uśmierciłem jednego przez złe zaprogramowanie fusebitów ale udało mi się go wskrzesić zewn generatokiem.

.... i wcale nie jest tak , że łatwo jest spalić AVRki czy inne procki ... jak coś takiego się dzieje, to trzeba szukać zawsze winy u siebie i co się źle zrobiło taka jest brutalna prawda .... a nie zrzucać winę na producenta procka

U mnie do tej pory jedna MEGA8 umarła zmęczona życiem (przeprogramowywaniem). Te ostatnie cieszą się lepszym zdrowiem bo zostały niektóre przeprogramowane grubo ponad 1000 razy i żyją.
Dla tego mogę napisać, że to dziwne!
Proponuję użyć miernika do sprawdzenia napięć w układzie, a jeszcze lepiej oscyloskopu i zobaczyć czy uC nie jest traktowany jakimiś impulsami o znacznym napięciu, których miernik nie zobaczy. Ja stosuję do zasilania zwykłe stabilizatory 5V (7805).

Też kiedyś uwaliłem reset w sposób jak opisałeś. Przyczyną było to że układ pracował na osobnym zasilaczu co komputer a w gniazdku nie było bolca. Efekt był taki że różnica potencjałów pomiędzy masą kompa a masą układu wynosiła ponad 100 (słownie: sto) woltów! W momencie wkładania wtyczki programatora do układu upaliłem resecik. Od tej pory jestem zapobiegliwy i zawsze łącze obydwie masy i jak narazie nie udało mi się spalić żadnego procka;]

Witam
Wszystkie wyprowadzenia AVRów mają zabezpieczenia przed zbyt wysokim lub zbyt niskim napięciem (diody do masy i VCC), ale reset nie ma do VCC ponieważ dostaje +12V w programatorze równoległym. Więc to wyprowadzenie nie jest zabezpieczone przed zbyt wysokim napięciem, można dodać taką diodę to może przestanie się psuć.

filip_gd napisał:

Dziś przez noc zostawiłem włączony działający układ.
Następna ATmega8 idzie w kibel, uszkodził się reset - tzn. podłączyłem go przez 100k czyli max z noty.
I znów coś się schrzaniło...
Jak wrócę do domu prześlę schemat pozdr

Reseta możesz podpiąć i bezpośrednio do +5V. Te 100k z noty to jest maksymalna wartość wewnetrznego rezystora pull-up. Zrób porządnie zewnętrzny reset i dobrze skonfiguruj fusy BODa (BODEN i BODLEVEL) i Start-up timera (SUT1 i SUT2)

Dodano po 8 [minuty]:

filip_gd napisał:

Witam
zdarza się że układ zaprogramowany kilka razy nie chce programować się dalej

Ważne jest aby przed każdym programowaniem skasować pamięć,
wielokrotne programowanie bez wcześniejszego kasowania może
uszkodzić pamięć flash. Jeśli używasz programatora z AutoErase to
dla pewności przed każdym programowaniem wykonaj "ręczne"
kasowanie flasha.

Witam
cyt: Ważne jest aby przed każdym programowaniem skasować pamięć, wielokrotne programowanie bez wcześniejszego kasowania może
uszkodzić pamięć flash...
A ja myślałem, że pamięć flash kasuje się przed każdym zaprogramowaniem z zupełnie innego powodu.
Pozdrowienia - teedd

Cytat:

Reseta możesz podpiąć i bezpośrednio do +5V.

W takim razie w przypadku resetowania ręcznie będę powodował zwarcie 5V z GND co nie będzie zbyt zdrowe dla ścieżek na PCB
Dobrze myśle?

Układ który chodził przez nocy w magiczny sposób odżył.
Poprostu odłączyłem go od zasilania i jak wróciłem z pracy znów działał.
Chyba że mikołaj podmienił mi ATmege:)

Podejżenia padły na układ zasilania uC. Zwiększę liczbę 100n i pojemność kondensatorków elektrolitycznych.

Zrezygnuję chyba z TLV1117 na rzecz 78L05, TLV dość poważnie się grzeje przy poborze 100mA a niby jest na 800mA.
Dołączyłem radioatorek z blaszki alu może będzie lepiej.

filip_gd napisał:

Układ który chodził przez nocy w magiczny sposób odżył.
po prostu odłączyłem go od zasilania i jak wróciłem z pracy znów działał.

Skoro działał bez zasilania to tylko czekać aż zacznie gadać ludzkim głosem. Okazja wkrótce.

A tak na poważnie to może program idzie w maliny na skutek np. przepełnienia stosu, skoro po odłączeniu zasilania i podłączeniu zaczyna działać.

filip_gd napisał:

Cytat:

Reseta możesz podpiąć i bezpośrednio do +5V.

W takim razie w przypadku resetowania ręcznie będę powodował zwarcie 5V z GND co nie będzie zbyt zdrowe dla ścieżek na PCB
Dobrze myśle?

Napisałem że można podpiąć, i że wtedy procek będzie dobrze działał, logiczne jest że jeśli stosuje się zewnętrzne żródła resetowania nie można tak podłączyć.

Dodano po 1 [minuty]:

teedd napisał:

Witam
cyt: Ważne jest aby przed każdym programowaniem skasować pamięć, wielokrotne programowanie bez wcześniejszego kasowania może
uszkodzić pamięć flash...
A ja myślałem, że pamięć flash kasuje się przed każdym zaprogramowaniem z zupełnie innego powodu.
Pozdrowienia - teedd

Nawet jeśli procesor ma wbudowana funkcję AutoErase nie zaszkodzi ręczne skasowanie zawartości flasha.

Zawsze trzeba kasować aFlash bo on się niekasuje i po zaprogramowaniu bez kasowania program się niewgrywa (przynajmniej tak jest u mnie)

... ja używam akurat PonyProga na domyślnych ustawieniach, procki programuję zawsze przez ISP w układzie, nigdy się nie zastanawiałem nawet czy kasować ręcznie Flash'a czy nie ... a programuję nieraz w przypadku gdy tworzę program setki razy (albo i więcej) i jeszcze nigdy nie spotkałem się z jakimiś problemami przy programowaniu z tego powodu

Ja też pierwsze słyszę, o tym że niekasowanie flasha może mieć jakieś skutki uboczne. I z reguły też tego nie robię (a programuje avry naprawdę często).

Dziwi mnie to również z tego powodu, iż podejmowałem próby napisania własnego programatora. Aby się tego podjąć musiałem dość dogłębnie przestudiować temat i nie widzę technicznych przeszkód w tym, aby tej pamięci nie kasować.

pozdrawiam, JnS

P.S. Kolego Filip_gd - umieść w końcu jakiś schemat bo inaczej będziemy tak sobie gdybać w nieskończoność.

Oto schemacik
Proszę nie sugerowac się opisem wyporwadzeń TLV1117 - są w rzeczywistości ok.

Witam
Podziele się swoimi spostrzeżeniami odnośnie ATmega8 w wersji SMD i DIP
Zrobiłem prosty układ zczytujący napięcia z przetworników i generujący PWM. Wszystko ganiało jak trzeba na ATmedze 32 ale nie było mi potrzebne tyle 1/0 więc postanowiłem zminimalizować projekt. Przesiadłem sie na ATmega8 i zaczęły sie problemy. Zmontowałem chyba z 8 układów identycznych, różnie płytki rozplanowane, różne kondensatory na AVCC i AREF i za każdym razem to samo. Układ działa niestabilnie zawieszając się a w końcu dzieje się coś takiego: wzrasta jego zapotrzebowanie na prąd, wzrasta temperatura stabilizatora i po jakimś czasie (kilkanaście sekund) przestaje opowiadać lub coś innego z nim się dzieje (np. nie daje sie zaprogramować). Przeprogramowanie takiego układu jest możliwe ale tylko przez pierwszych kilka sekund zanim się układ nie nagrzeje. Dodam, że wszystkie układy były kupywane w AVT w chyba 3 seriach. (5 PDIP, 10SMD, 2 SMD) i wszystkie kończyły tak samo.
Nie wiem jak to określić ale chyba coś z nimi jest nie tak, wadliwa seria produkcyjna lub konstrukcja.
Przesiadłem się na ATtiny26 i nie występują poprzednie problemy!!
Dziwne

P.S. 1 Jeśli możesz to zmień na ATmega16/32 lub jakis ATtiny. Moje podejrzenia co do ATmega8 nie są nieuzasadnione, mimo że usłyszysz iż zwalam wine na producenta. Program i połączenia sa w zasadzie identyczne (z potrzebnymi modyfikacjami) więc powinny działać tak samo, jednak tak nie jest

P.S. 2 Jesli chodzi o ręczne kasowanie pamięci przed zapisem, to w PonyProg następuje to automatycznie, a w ISP prog trzeba to zrobić ręcznie inaczej tak jak koledzy zauważyli wogóle nie da się go wgrać.


Pozdrawiam i odracam ATMega8

Ciekawe jest to że co jakiś czas pojawia się na forum osoba która odkrywa że przykładowo Atmega8 nie działa tak jak powinna, producent popełnił poważny błąd i to najpewniej jego wina. Jeszcze ciekawsze jest to że ATmega8 jeden z najpopularniejszych uC działa w poważnych zastosowaniach tak jak trzeba...

Tak jak przewidywałem kwestionuje już ktoś moje spostrzeżenia. A nie wpadł kolega, że problem się pojawiać może tylko przy np wykorzystaniu określonych pinów i trybów pracy liczników etc. ? Poważne zastosowania są poważnie testowane i jeśli wynika jakiś problem to są zapewne zmieniane ukontrolery i nikt nie wnika czemu nie działało. Moje uwagi są takie, że ten sam program działa na 2 innych prockach o różnych obudowach, a na ATmedze8 działa źle i powoduje zawieszanie układu. Po zawieszeniu układ zaczyna sie grzać (nadmierny pobór prądu) i kończy uwaleniem części wyprowadzeń/funkcji.

Napisz do producenta w tej sprawie, podejrzewam że producent jeszcze przed wprowadzeniem układu na rynek sprawdził go. W dokumentacji pod koniec jest kategoria Erratas gdzie opisane są znane błędy.

Same procesory na pewno dzialaja ok. Kiedys mialem podobny problem ale wina lezala po stronie programatora tzn, byly jakies problemy z masa komputera i ukladu. Przy probie programowania wyskakiwaly bledy a czasmi procek wysiadal.
Problem rozwiazal programatorek z calkowita izolacja galwaniczna portu LPT i uC. Problem ten wystepowal tylko przy jednym komputerze.

kolego Ch.M. .... z całym szacunkiem, ale niestety tak jak powiedział McRancor jesteś właśnie jedną z takich osób która narzeka na swoje niepowodzenia w ten sposób .... i to nie tylko tu na tym forum sa takie osoby... jak sobie przejrzysz net to spotkasz się z takimi, którzy twierdzą, że poważnie niedopracowane są (jak dla nich) inne AVRy albo PICe .... sorry ale takie rozwiązanie problemu typu, "układ się zawiesza i zwiększa zapotrzebowanie na prąd" ... trzeba być troszkę malkontentem, żeby bez dogłębnego zbadania przyczyny zawieszania twierdzić, że wszystkie układy danego typu są do d.... Nie masz debuggera jakiegoś? nie możesz sprawdzić w którym momencie następuje zawieszanie uC? hmmm zapewne zaraz powiesz, że zawiesza ci się w najróżniejszych miejscach i odrazu chce duużo prądu .... nie no to troszkę wygląda na żarty. Firmy, które używają w swoich rozwiązaniach akurat ATmega8 wcale nie podchodzą do tematu jak ty.... tzn , że jak im coś nie działa to nie analizują zbytnio o co chodzi tylko biorą pierwszy lepszy podobny model i może coś wyjdzie? a jak nie? to co? ... biorą kolejny model, i kolejny ...... itd .... przecież to jest śmieszne.... Ja pozwoliłbym sobie na takie wypowiedzi jak twoja ale po tym np gdybym zgłosił jak mówił McRancor problem do producenta i uzyskał jakąś odpowiedź .... być może zwróciliby ci uwagę gdzie roibisz błąd ... albo dodaliby w sekcji erratas nowy znany problem... wtedy można byłoby się szczycić tym, że przyczyniłes się do znalezienia takiego błędu .... a tak to troszkę niepoważnie - takie jest moje zdanie (trzeba wiedzieć co do czego użyć i poznać to dokładnie)

Ch.M.:
mylisz sie że poważni ludzie zmieniają kontrolery i sie nie zastanawiają. Ja programowałem sporo 8051 i pochodnych oraz avr. Też zdarzało mi sie zmieniać typ, zarówno z typu 89c2051 na 2313, jak i atmega8 na atmega32. I nie zawsze wszystko będzie działać.

Jednak po rozgryzieniu problemu i przekopaniu sie przez dokumentacje, sprawa sie wyjaśniała.

Faktem też jest że czasem zdarza sie chwilowe dziwne działanie procka typu odebranie znaków na pierwszy port szeregowy, zamiast z drugiego.
Ale to zawsze działo sie podczas dopracowania programu, trudno powiedzieć czemu, zwykle po dopracowaniu nie widziałem żeby coś było nie tak. Wiec albo debugger, albo przegląd kodu. A problem polaga na tym że błąd czasem dotyczy nie tej częsci kodu co daje błędny wynik. Ale gdzieś tam coś nadpisuje ci zmienną i po ptokach.

Ważne też czy piszesz w C czy asemblerze. Przy C kompilator robi różne rzeczy. Czasem przy optymalizacjach można z nim sie sprzeczać, czy aby dobrze traktuje jakieś tam zmienne. Bo moim zdaniem czasem przesadza. to znaczy, czasem działa a czasem nie. Dlatego odpowiednie deklaracje są bardzo ważne, bo kompilator nie ma zwyczaju myśleć przy optymalizacjach. Inaczej zamiast wyników będą jakieś tam śmieci.

Witam ponownie
Oczywiście macie sporo racji, troll i mirek, w tym co piszecie, ale wyobrazcie sobie ze musicie zrobic jakis projekt w określonym czasie. Kombinujecie tydzien dwa trzy i nadal problem się powtarza mimo przebudownaia programu a czas ucieka... Degugować, jak? Niestety nie wbudowano JTAGa w ten kontroler, a innych mozliwosci nie mam.
Programy piszę w ASM. Ma ktoś ochotę przetestować? Bardzo proszę, dodam program
Dodam, że nie jest to wina programatora, mam ich kilka i zawsze ten sam problem.


Opis programu:
Program "siedzi" w urządzeniu do ładowania akumulatorów (dwóch), sprawdza napięcie i prąd i na podstawie tych parametrów określa stan naładowania akumulatora Li-poly.
Wynik jest pokazywany na 6-ciu diodach LED.

Jeśli ktoś ma ochotę i czas to dziękuje z góry za zainteresowanie.
Dodam, że debuger w AVR Studio nie wykazuje błędów w programie, aczkolwiek zdaje sobie sprawę, że nie jest AVR Studio nie jest sam wolny od bugów.

Dzieki za zainteresowanie, postaram się śledzić wątek.

Daniel

Witam
Nie ma inicjalizacji stosu ani wektorów przerwań, może z nich nie korzystasz ale zastosuj się do tego co producent proponuje.

Witam,

kolego Ch.M. też obejrzałem twój program tak jak Dar.El. Ja również pierwsze co powiem to potwierdzę to co mówi przedmówca - GDZIE MASZ INICJALIZACJĘ STOSU???? .... GDZIE WEKTORY PRZERWAŃ???

...ok nawet jeśli w twoim programie nie ma ani jednej instrukcji "rcall" która potrzebowałaby użyć stosu to jednak rozpoczęcie programu w każdym normalnym programie powinno wyglądać tak:


.org 0
rjmp START
...
tu wektory przerwań
...

START:
cli
ldi R16, HIGH(RAMEND)
out SPH, R16
ldi R16, LOW(RAMEND)
out SPL, R16

... tu dalsza część twojego programu

Oczywiście na upartego przy takiej konstrukcji programu możesz pominąć pozostałe wektory przerwań poza tym pod adresem ZERO, jeśli ich nie używasz ale wtedy PAMIĘTAJ że poza inicjalizacją stosu pierwszą komendą jaką podajesz w asemblerze jest "cli" wyłączenie przerwań

.... u ciebie np przerwania mogą być przypadkowo włączone i nagle chce się wykonać przerwanie od przetwornika AC ... i co wtedy??? MEGA MALINY i na podstawie tego nie można wszędzie się wypowiadać, "że ...." - sam wiesz co dalej

.... taką odpowiedź też dostałbyś na początku od producenta po wysłaniu im takich objawów i maila ze swoim kodem.


... w ten sposób kod powinieneś zaczynać pisząc program na każdym z AVRków to jest żelazna zasada. Co najwyżej jeśli dalej używasz przerwań to po inicjalizacji portów itp - podajesz komendę "sei"

... życzę powodzenia po poprawieniu kodu, myślę, że co najmniej 80-90% problemów zniknie - nie piszę, że 100% bo aż na tyle ciężko przeanalizować program nie widząc schematu ale to wydaje się nie konieczne bo chyba tu leży pies pogrzebany

... to że piszesz w asemblerze ten program to ogromny plus - bo sam widzisz co się dzieje - a po co zaraz do debugowania jakiś debuger sprzętowy JTAG albo podobny. Podłącz do kilku wolnych pinów kilka LEDów i za ich pomocą ustawiaj sobie miejsca w programie tak abyś widział optycznie co się dziejew danym momencie. Ale fakt bez ustawionego stosu - ciężko trafić na błąd w jednym miejscu - mogą one wyskakiwać w najmniej oczekiwanych przypadkach

pozdrawiam

dziękuję za rady, postaram się zastosować do wskazówek, aczkolwiek nie bardzo wierzę by to była wina inicjalizacji stosu i porzadkowania odwołań z przerwań których nie używam, ale nigdy nic nie wiadomo. Nie przetestuje raczej tego w tym roku bo zmodyfikowałem PCB dla ATiny26 i znikły problemy, ale postaram się za 2-3tyg sprawdzić Wasze rady.
Jeszcze raz dzięki i odezwę się jeszcze czy coś dają modyfikacje.
A tak przy okazji to podziele sie jeszcze jednym spostrzezeniem, przy obsłudze ADC często mi się zdarza, ze przy rozdzieleniu nastaw ADMUX czy ADCSRA wyniki pomiarów są stabilniejsze (mniejszy rozrzut). Rozdzielenie nastaw rozumiem przez wpisanie nop między ldi R16, 0b01010101 a out ADCSRA, R16. Wygląda to mniejwiecej tak, jakby kontroler nie zawsze zdążył przepisać prawidłowo wartość z rejestru R0-R31 do powyższych.
Pozdrawiam

Ch.M. napisał:

A tak przy okazji to podziele sie jeszcze jednym spostrzezeniem, przy obsłudze ADC często mi się zdarza, ze przy rozdzieleniu nastaw ADMUX czy ADCSRA wyniki pomiarów są stabilniejsze (mniejszy rozrzut). Rozdzielenie nastaw rozumiem przez wpisanie nop między ldi R16, 0b01010101 a out ADCSRA, R16. Wygląda to mniejwiecej tak, jakby kontroler nie zawsze zdążył przepisać prawidłowo wartość z rejestru R0-R31 do powyższych.

To raczej nie zdążył dokładnie wpisać danych do rejestru R16 tym pierwszym rozkazem . To się nazywa mistyka. Może trzeba odczynić

Przy przełączaniu przetwornika miedzy kanałami dobrze jest odczekać chwilke czasu po zmianie kanału.
Wynika to z zaklocen wystepujacych podczas przelaczania multipleksera: jesli przy nowym pomiarze biezacy kanal zostal zmieniony, to przez pewien czas na wejsciu przetwornika wystepuja stany nieustalone. Mozna zrezygnowac z tego opoznienia, jesli pomiary odbywaja sie ciagle na tym samym kanale, lub ma miejsce usrednianie, w przypadku pomiarow jednorazowych - nalezy dodwac takie opoznienie.