Dziwne zachowanie ATMEGA 128 dlaczego program mruga diodą zamiast zapętlać?

Wed Mar 12, 2008 7:43 pm   

Witam wszystkich
Mam taki problem z ATMEGĄ 128. Za którymś razem przy programowaniu procesora
zawiesił mi się ponyprog. Programowanie nie powiodło się. Po odpaleniu
jeszcze raz programatora procesor zaprogramował się ok, weryfikacje też
przeszedł pomyślnie. Niestety program nie ruszył tak jak powinien. Wróciłem
do korzeni i poprzez jeden port chciałem sprawdzić czy procesor się nie
upalił. Dałem prosty program zapalający diodę:

SET_LED;
for(;
{
for (cc=0; cc<100; cc++){};
CLR_LED;
}

SET_LED i CRL_LED działa na 100%. Efekt programu jest dość dziwny. Dioda
mruga, czyli wykonywany jest program od zera, a nie zapętla się w FOR.
Wygląda to jak by co chwile wykonywał program od początku. Jak usunę SET_LCD
który jest poza pętlą dioda nie zapala się w ogóle. Co mogło się stać? W
FUSE BITACH nie grzebałem i mam wyłączony WATCHDOG.
Takie mam ustawienia FUSEBITS:
BODLEWEL=1, BODEN=1, SUT10=10, CKSEL3210=0100,
OCDEN=1, JTAGEN=1, CKOPT=1, EESAVE=1, BOOTSZ10=00,
BOOTRST=1, M103C=1, WDTON=0.

Co może być przyczyną? Czy tak mógł się uszkodzić procesor? Wymieniałem
oscylator i to samo. Teraz chodzi na wewnętrznym ale bez zmian. Wiem że to
raczej wróżenie z fusów, ale może ktoś miał podobny przypadek. Wymiana
procesora jest w ostateczności bo boje się o uszkodzenie złożonej dość
płytki :/

Pozdrawiam

Wed Mar 12, 2008 8:29 pm   

M... pisze:

Ja raz tak upaliłem 90s2313 że wszystko w nim działało poza kilkoma
operacjami, bodajże były to operacje arytmetyczne. Tak że można
uszkodzić procesor w dziwny sposób.

--
Pozdrawiam
Dumak
(usuń wszystkie '1' z adresu e-mail)

Wed Mar 12, 2008 9:17 pm   

Wiesz co, uczę się dopiero C, ale skoro SET_LED jest POZA pętlą, to jak
to ma działać?? On raz zapala diodę, a potem w pętli ją ciągle gasi...
gasi zgaszoną ... czyli efekt jest dobry - mrugnięcie na starcie!
pomijając fakt, że przy tak małym opóźnieniu robionym na FORze (o ile
kompilator w ogóle to umieszcza w kodzie wynikowym ;P), nie da Ci
sensowengo opóźnienia...

Pozdrawiam
Konop

Wed Mar 12, 2008 9:32 pm   

Gratuluje prawidłowo rozgryzłeś program! Tylko właśnie o to chodzi że
mikrokontroler wykonuje go po prostu źle, pomimo prawidłowego wczytania i
weryfikacji flasha. Większego opóźnienia nie mogę dać, bo nie wiem czemu
program nie dociera już do miejsca gaszenia diody. Tak czy inaczej dioda
mruga z częstotliwością około 5-10 Hz co też jest dziwne zważywszy, że
wewnętrzny oscylator to około 1MHz (nie pamiętam jaki ustawiłem dokładnie).

Pozdrawiam

Wed Mar 12, 2008 9:37 pm   

Hmm może masz racje. W każdym razie wszystko na to wskazuje. Nawet
ustawienie "Fusów" na różne sposoby nic nie dało.
Pytanie tylko dlaczego tak się stało? Pamiętasz jaka była przyczyna upalenia
Twojego procka? Pewnie coś zrobiłem źle, bo wątpię by umarł sam z siebie,
chociaż miał już niezły przebieg. Mógł się tak uszkodzić poprzez wyciąganie
wtyczki programatora?

Pozdrawiam

Wed Mar 12, 2008 10:01 pm   

M... pisze:

Jeżeli dobrze pamiętam to go przysmażyłem, chyba zwarłem mu wyjście do
masy albo do +5V, a on chciał wystawić coś przeciwnego.


--
Pozdrawiam
Dumak
(usuń wszystkie '1' z adresu e-mail)

Wed Mar 12, 2008 10:40 pm   

sprawdź w AVRstudio najpierw, może optymalizacja Ci pokrzaczyła program.
cc jest volatile?
Podłącz RS'a i zobacz gdzie co wysyła, jest gdzieś rejestr trzymający
powód restartu (MCUCSR).
PS ja tam nie lubie for(), może while(1) { while(--cc);CLR_LED;};

Wed Mar 12, 2008 11:11 pm   

cc jest oczywiście volatille.
Sprawdzałem w pliku lst po skompilowaniu i na pewno tego optymalizacja nie
usunęła. To raczej nie wina programu, bo nagle działający program przestał
działać. Wcześniejsze wersje też bez echa.


Hmm tego nie wiedziałem ale chyba jutro jak znajdę czas pojadę po scalaka i
go wymienię. Za małe prawdopodobieństwo chyba że jeszcze żyje :(


Też tak wolę. Ten For jest żywcem z przykładu. To w razie jak bym miał
pomroczność jasną i nie widział oczywistych rzeczy.

Pozdrawiam

Thu Mar 13, 2008 10:47 am   

M... pisze:

A ja widzę włączony Watchdog (WDTON=0).
Według datasheeta:
M103C=1 i WDTON=0 (0 oznacza zaprogramowany bit) Watchdog jest w trybie
SafetyLevel = 2, co oznacza, że jest włączony na stałe i musisz go
zerować w programie.
Spróbuj dodać do swojej pętli sekwencję zerującą Watchdoga.

Jeżeli nie grzebałeś w rej. WDTCR, to daje on reseta co jakieś 14ms. Do
tego dochodzi 65ms zwłoki po resecie, inicjalizacja pamięci w C i masz
swoje ~10Hz.

Qmexx.

Thu Mar 13, 2008 2:08 pm   

Ale jaja! Masz racje! Sprawdzałem ten bit i go przestawiałem. Po
przestawieniu program nie ruszył, ale najprawdopodobniej miałem już
namieszane coś w programie przez te testy :/ Zmyliła mnie książka w której w
tabelce masz coś takiego:
WDTON | Uaktywnienia wewnętrzny układ watchdog "na stałe" | 1 (watchdog
uaktywniany z poziomu programu) |

Ech, jednak pomroczność jasna. Zasugerowałem się tym "na stałe" i tą
jedynką, a tu trzeba czytać drobnym drukiem. :/

WIELKIE DZIĘKI!!! Bo już miałem jutro go wymieniać, bo zależy mi na czasie.
Przy tym nieudanym programowaniu PonyProg musiał to przestawić (dziwne), ale
że reszty nie zmienił to też dziwne.

Pozdrawiam i dziękuję wszystkim za pomoc jeszcze raz!