POGOTOWIE - kłopoty z zaprogramowaniem, zablokowaniem, fusebit-ami, itp.

Brak ustawienia CKOPT wcale nie jest powodem, że procek nie działa na zewn kwarcu. Jeśli bawiłeś się tylko fusami CKOPT, to spróbuj podłączyć zewn. oscylator RC albo jakiś generator TTL do XTAL1 i obejdzie się bez żadnych równoległych programatorów

Przestawiałem CKSEL a nie CKOPT
Przestawienia dokonałem przez AVR-BASCOM.
Ponieważ podłączyłem zewnętrzny kwarc 16MHz.
No i w momencie przestawienia i dania WRITE FS, procek przestał być widziany przez programator.
Na pewno wystarczy dodatkowy generator?
Jakiej częstotliwości powinien być?

"Mały brat wyleczył dużego brata"
Zrobiłem generator na (wg. schematu Mirka z poprzedniej strony )555 +kondensator 10nF+opornik 47kΩ, podłączyłem do XTAL1 i Atmega8515 odzyskała "przytomność"

Witam
Nie bardzo wiedziałam gdzie mój problem podczepić, ale pomyślałam że „zablokowany mikrokontroler” będzie pasować.
Posiadam płytkę MMnet1001 propox'u z at91sam9260 na pokładzie. Od jakiegoś czasu bezskutecznie próbuję wgrać własnego U-boot'a. Najpierw zgodnie z instrukcja na stronie atmelowskiej przy użyciu programu sam-ba zapisuje bootloadera i u-Boot'a pod adresy zgodne z dokumentacja mojej płytki. Po pierwszym wyczyszczeniu pamięci i zapisie (zakończonym sukcesem według logów) w terminalu odzywa się jedynie RomBoot. Niestety więcej już do Samby wejść nie mogę bo komputer nie może wykryć USB z podłączonym procesorem.
Drugie podejście wiązało się z użyciem JTAG i programu Jflash SEGGER'a. I znów ustawiłam wszystko według dokumentacji podłączyłam JTAG'a i wybrałam “chip erase”. I znów czyszczenie zakończone sukcesem jednak oprogramowanie już więcej płytki nie wykryło. Zgłosiłam mój problem do propox'u, płytka została wymieniona jednakże nie otrzymałam informacji gdzie tkwił problem. Założyłam zatem że płytka była wadliwa I powyższą procedurę powtórzyłam z tym samym efektem końcowym.
Co się dzieje? Czy yo w ogóle możliwe, że wyczyszczona pamięć nie jest widoczna dla programów? Czy mogłam wyczyścić jakieś bity i teraz mikroprocesor jest zablokowany? W takim razie jak to naprawić skoro bez wykrycia procka nie mogę wgrać żadnego softu. Dodam, że RomBoot cały czas się uruchamia zatem chyba wszystko hardwarowo jest w porządku. Będę bardzo wdzięczna za jakiekolwiek pomysły. Pozdrawiam.

Witam mam problem z zaprogramowaniem atmegi32 podczas próby zaprogramowania
avr studio pokazuje komunikat Entering programming mode.. FAILED
próba zaprogramowania przez bascom avr kończy się zawieszeniem programu
dodam że atmega po podłączeniu działa prawidłowo i wykonuje program wcześniej zaprogramowany dodam jeszcze że zwarłem PIND0 do masy podczas gdy był na nim stan wysoki. Czy mogłem uwalić w ten sposób atmegę ?
Programator jakiego używam to avr-prog1 kompatybilny z stk500 i jest on prawidłowo wykrywany przez avr studio na wyjściu zasilającym atmegę jest 4.5v po podpięciu do mikro kontrolera spada bo 3.8v

Dobry wieczór,

mam luźne pytanie do kolegów fachowców. Programuje mikrokontrolery od 4 lat. Hobbystycznie. Problem jaki mam jest dość osobliwy. Padają mi ATMegi co jakiś czas. Na oknie leży mi ok. 5ciu padniętych ATMeg o łącznej wartości ponad 100zł. I taką mam nadzieję, że może ktoś doradzi, jeśli nie co do ich odratowania (ależ bym się ucieszył) to do zapobiegania podobnym sytuacjom w przyszłości.

ATMega potrafi pracować tydzień i jest wszystko OK, biorę ją do przeprogramowania: raz, drugi, trzeci, -nasty - i koniec. Po kilkunastu wyciągnięciach z podstawki DIP ATMegi padają (program nadpisywany był ok. kilkadziesiąt razy). Takie "padnięcie" objawia się dość osobliwie i zawsze (co chciałbym podkreślić) w ten sam sposób, mianowicie, najpierw taki procesor zaczyna dziwnie pracować w docelowym układzie - zaczynają się skoki do obszarów programu, które nie powinny być wykonywane, potem program staje się nieprzewidywalny. Podłączam taki procesor do programatora. Ze dwa razy mogę zaprogramować chip jeszcze raz i wszystko wraca do normy, jednak po drugim razie (od zauważonych dziwnych zachowań), gdy wsadzam go do programatora dzieje się coś takiego: Wszyściuteńko wygląda normalnie. Da się odczytać sygnaturę procesora (prawidłowa), Fusebity (prawidłowe), Lockbity (prawidłowe, odblokowane). Próbuję więc zaprogramować procesor. Następuje zapis Flash, potem odczyt i... komunikat, że odczytany Flash nie jest równy Flashowi zapisanemu.
Co najciekawsze, po operacji zapisu, gdy odczytamy Lockbity, wszystkie są w stanie blokady (w tym również "futher programming disabled") - czyli procesor zablokowany.

Jeszcze jedna charakterystyczna rzecz. Kiedy użyje funkcji "Chip Erase", znów będę widział poprawną sygnaturę, Fusebity i Lockbity... do momentu kiedy czegoś nie spróbuje zapisać do procesora (czy to program czy to fusy). Po jakiejkolwiek operacji zapisu, procesor się blokuje.


Programator JTAG wykluczam, ponieważ po włożeniu innej, nowej kostki, wszystko sprawnie działa i da się programować. "Złą" serię układów wykluczam, ponieważ kupowałem je na przestrzeni wielu miesięcy, lat. Zasilanie do układu podciągnąłem zgodnie z Datasheetem i tematem na elektrodzie "[ATMega] Dobre praktyki przy podłączaniu".

4 z 5 procesorów padło mi w obecnym układzie (który działa praktycznie bez przerwy. Nie chciałbym za bardzo sugerować rozwiązania, że to wina układu). Jest to efekt świetlny. Działa w oparciu o 32 diody podłączone do portów kontrolera.
Jedyne, co mi przychodzi do głowy (a właściwie dwie rzeczy):

1) to może fakt iż być może za bardzo obciążam wyjścia w moim układzie (do wszystkich pinów IO podpięte diody z rezystorami ciągnące max 6.5mA na diodę). Kilka miesięcy temu nawet dałem większą oporność do diod, aby jeszcze bardziej ograniczyć prąd. I już się cieszyłem, że pomogło, do momentu kiedy przed chwilą padł mi kolejny mikrokontroler. I tak się zastanawiam (bo w Datasheecie ATMegi piszą ciekawe rzeczy o obciążalności)... czy przypadkiem nadal nie przesadzam i czy to nie jest przyczyną problemów. Dodam, że kontroler jest zimny podczas pracy.

2) jeden z pinów jest wyjścio-wejściem (podczas przerwania Timera zmienia się na wejście, odczytuje wartość (H lub L) i z powrotem zmienia się na wyjście) i podaje na niego niekiedy sygnał z jednej linii kabla RS232 z komputera (w komputerowym RS232 tam jest +15V w stanie wysokim, ale dołączyłem rezystor 10kOhm i mam nadzieję, że nie to jest źródłem problemów).


Proszę tylko o informacje, czy opisane zachowanie może być skutkiem zbytniego obciążenia portów, czy też mojego wyjścio-wejścia. Jeśli nie, to ewentualnie co może powodować padanie kolejnych ATMeg?

Bardzo serdecznie dziękuję za przeczytanie i zainteresowanie.

Witaj,

na dobry początek proponuję zbudować FuseBitDoctor - proste urządzonko na jedno popołudnie, opis znajdziesz na forum. Wykluczysz wówczas kwestię, czy Twoje Atmegi są zablokowane, czy uszkodzone.
Nie używasz przypadkiem w programie zapisu do eeprom ? Miałem kiedyś taki przypadek, że nieopatrznie w pętli głównej umieściłem zapis zmiennej do pamięci, po kilku dniach pracy urządzenia komórki się "zepsuły".

bajerybajery wrote:

..................(w komputerowym RS232 tam jest +15V w stanie wysokim, ale dołączyłem rezystor 10kOhm i mam nadzieję, że nie to jest źródłem problemów).

Jeżeli ten rezystor 10k jest włączony szeregowo to w dalszym ciagu masz na wejściu sygnal w stanie wysokim 12V, podczas gdy datasheet pozwala na przekroczenie max. 0.5V ponad Vcc. Myślę że rezystorowy dzielnik napięcia byłby tu skuteczniejszy w wyrównaniu poziomów napięć.
Obciążalność prądowa processora wg. datasheet jest dopuszczana w granicach do 40mA/200mA dla pin/total odpowiednio. Są to ogólne maxymalne wartości dla warunków statycznych. Jeżeli te, ileśtam diod dają obciążenie o charakterze dynamicznym to te wartości należy obniżyć.
Patrz szczegóły w "Electrical Characteristics".

e marcus

Witaj!

bajerybajery wrote:

Po kilkunastu wyciągnięciach z podstawki DIP ATMegi padają (program nadpisywany był ok. kilkadziesiąt razy).

może to jest przyczyna?
Wiem, wiem sam też tak robię (staram się unikać) ale ESD nie śpi.

emarcus wrote:

bajerybajery wrote:

..................(w komputerowym RS232 tam jest +15V w stanie wysokim, ale dołączyłem rezystor 10kOhm i mam nadzieję, że nie to jest źródłem problemów).

Jeżeli ten rezystor 10k jest włączony szeregowo to w dalszym ciagu masz na wejściu sygnal w stanie wysokim 12V, podczas gdy datasheet pozwala na przekroczenie max. 0.5V ponad Vcc. Myślę że rezystorowy dzielnik napięcia byłby tu skuteczniejszy w wyrównaniu poziomów napięć.
e marcus

Kolega już prawo Ohma przerabiał? Jak widać nie. Jak masz wstręt do teorii to zmontować układ i sobie multimetrem zmierzyć.

Dodano po 6 [minuty]:

bajerybajery: a dlaczego go ciągle wyciągasz z podstawki? ISP znaczy in-system programming Takie ciągłe przekładanie może być źródłem problemów (ładunki elektrostatyczne, brak kontaktu itd.). Nie wykluczałbym od razu programatora. Jakim programem programujesz?
FLASH zachowuje się dziwnie głównie przy przetaktowaniu procesora i przy przegrzaniu. Bie bywa gorący? Może ci się jakieś latch-up robi?

Kuniarz wrote:

proponuję zbudować FuseBitDoctor

Czy on pomoże coś więcej niż programator JTAG? Układy Atmela można programować tylko przez ISP i przez JTAG. Jak pracuje Fusebit doctor ? Czy jest jakiś trzeci sposób na programowanie układu?

Kuniarz wrote:

Nie używasz przypadkiem w programie zapisu do eeprom ?

Nie.

Emarcus wrote:

Jeżeli ten rezystor 10k jest włączony szeregowo to w dalszym ciagu masz na wejściu sygnal w stanie wysokim 12V

Czy nie będę miał na nim spadku napięcia 10V?. Dziękuję za uwagę związaną z niedopuszczalnością przekroczenia napięcia o więcej niż Vcc+0.5 - być może napięcie nie jest dokładne i mam np. 5.7V. Mimo, że sygnały z RS232 są odbierane w miarę prawidłowo (czasami zdarza się nieodebranie sygnału - nie mam pojęcia dlaczego). Zaraz pomierze i dam znać.

shadow0013 wrote:

Witaj!

bajerybajery wrote:

Po kilkunastu wyciągnięciach z podstawki DIP ATMegi padają (program nadpisywany był ok. kilkadziesiąt razy).

może to jest przyczyna?
Wiem, wiem sam też tak robię (staram się unikać) ale ESD nie śpi.

Hmm.... No właśnie pozostali też tak robią. Poza tym, mnie nie padła przypadkowo jedna ATMega, tylko 5, wszystkie przed swoim upadkiem zachowywały się identycznie.

tmf wrote:

bajerybajery: a dlaczego go ciągle wyciągasz z podstawki? ISP znaczy in-system programming Takie ciągłe przekładanie może być źródłem problemów (ładunki elektrostatyczne, brak kontaktu itd.). Nie wykluczałbym od razu programatora. Jakim programem programujesz?
FLASH zachowuje się dziwnie głównie przy przetaktowaniu procesora i przy przegrzaniu. Bie bywa gorący? Może ci się jakieś latch-up robi?

Wyciągam go cały czas z podstawki, ponieważ w tym układzie nie mam dolutowanego złącza JTAG.
Mój programator to JTAG ICE (wersja pierwsza, nie mkII). Mam też zakupionego niedawno AVR ISP (zgodny z STK500). Nie próbowałem jeszcze na nim nic programować.
Procesor nie bywa nigdy gorący. Zawsze podczas pracy jest zimny. Czasami, gdy zaczyna padać, obserwuje nagłą, niekontrolowaną zmianę częstotliwości taktowania (albo na większą albo na mniejszą) - tak jakby następował niekontrolowany zapis do pamięci.
Nie spotkałem się nigdy z pojęciem Latch-Up - teraz czytam, że jest to jakiś typ zwarcia. Mógłby Pan przybliżyć?


Teraz ode mnie kilka słów: przede wszystkim, bardzo dziękuję za zainteresowanie. Dzisiaj sobie jeszcze raz zerknąłem na notę katalogową ATMegi16 - piszą tam coś takiego:

Quote:

Although each I/O port can sink more than the test conditions (20 mA at Vcc = 5V, 10 mA at Vcc = 3V) under steady state
conditions (non-transient), the following must be observed:
PDIP Package:
1] The sum of all IOL, for all ports, should not exceed 200 mA.
2] The sum of all IOL, for port A0 - A7, should not exceed 100 mA.
3] The sum of all IOL, for ports B0 - B7,C0 - C7, D0 - D7 and XTAL2, should not exceed 100 mA.

Warunek pierwszy spełniam. Warunek drugi spełniam. Ale warunku trzeciego nie spełniam jeśli te 100mA to sumaryczna obciążalność portów B, C, D. Właśnie nie jest to doprecyzowane, ale najwyrażniej chyba jednak tak (w końcu w przeciwnym wypadku punkt 2 nie byłby napisany osobno). Przez porty B,C,D idzie mi łącznie (ciągle) w krytycznym punkcie programu około 156mA (około 52mA na port).

I jeszcze odnośnie podłączonego portu RS232 - przypomnieli mi Panowie o ciekawej rzeczy. W przerwaniu wykonywanym co (chyba) 4 sekundy, miałem warunek, który sprawdzał czy linia RS232 jest w stanie wysokim (sygnał z komputera trwał 6 sek.). I co ciekawe program nie zawsze mi wychwytywał sygnał. Być może jest to czegoś oznaką. Sygnał był wychwytywany ok. 7 na 10 razy. Nigdy nie doszedłem dlaczego (mimo wprowadzenia odpowiednich (duzych nawet) opóźnień po zmianie wyjścia na wejście i z powrotem (tak aby procesor zdążył je przełączyć)). Nawet mogę dać kod tego przerwania - w zasadzie wszystko OK:

Pomierze napięcie wejściowe z RS232 i napiszę.

Dodano po 16 [minuty]:

Nie, to nie to... Rezystor jest nawet większy i przy przychodzącym sygnale z RS232 na nóżce kontrolera PB0 mam napięcie 3,04V. ATMega jest zasilana 4.52V.

Być może tak niskie napięcie (3V) tłumaczy nie załapywanie niekiedy stanu wysokiego na wejściu, choć w nocie katalogowej pisze, że ATMegi załapują "jedynkę" od 0.7V. A, właśnie... czy 0.7Vcc oznacza 0.7V, czy też oznacza napięcie wejściowe przmnożone przez 0.7?

Dołączam filmik ilustrujący istotę problemu (film kodowany w H264 gdyby ktoś miał jakiekolwiek problemy z kodekami).

Po ponownym podłączeniu ATMegi do zasilania jest dokładnie to samo.

jak dla mnie to stos się przepełnia. Na dzień dobry wywaliłbym sei() z obsługi przerwania, bo przy wyjściu z podprogramu stan przerwań sam się przywróci.

Witam
Jak większość osób również i ja źle zaprogramowałem Fuse bity w Attiny2313 a mianowicie zamiast ustawić CKSEL3..0: 1110 i SUT1..0: 10 to ustawiłem odwrotnie czyli CKSEL3..0: 0001 i SUT1..0: 01 (nie zauważyłem opisu: "checked means programmed bit=0")

Niestety w nocie Attiny jest adnotacja że: "CKSEL3..0: 0001/0011/0101/0111 - Reserved

Zwykły programator USBasp nie chce tego ruszyć ale czy ruszy go programator równoległy (fusebit doctor) ?

Może kwestia dołączenia odpowiedniego zewnętrznego taktowania ale na rezonatorze 4MHz nie rusza.

Drugi Attiny ustawiłem już poprawnie i chodzi ok.

Dodano po 1 [godziny] 21 [minuty]:

Problem rozwiązany.

Okazało się, że w innym miejscu noty Attiny2313 w dziale External Clock było: CKSEL3..0: 0000-0001 0-16 MHz

Podłączyłem zewnętrzny generator kwarcowy 20MHz (taki znalazłem) i wszystko ładnie prze-programowałem

Pozdrawiam

Witam
Sprawa może wydaje się banalna ale niestety tak nie jest.
Wymyśliłem sobie że zegar będzie 128kHz z podziałem przez 8 (efektywnie 16kHz).
Napisałem program i zaprogramowałem Attiny - jednak zawiera błąd.
Chciałem wgrać ponownie jednak a AVR studio wyskakuje komunikat aby zwiększyć zegar do co najmniej 5kHz. Przy 100Hz mogę odczytać FUSEBITS - zawsze poprawnie - jednak próba ich zmiany jest niemożliwa. Przed zaprogramowaniem zmieniłem zegar na 128kHz po czym bez problemu mogłem zmienić na inny (9,6MHz).

Nie wiem co robić.

Dodatkowo sygnatura się odczytuje jako 0x53 0x53 0x53 - wyskakuje że to niewłaściwy mikrokontroler z listy.

Programator to AVRISP MKII.

A skasować flash można? Zobacz czy nie ruszy np. PonyProg-iem ale potrzebny port LPT.

N.

Nie można skasować. Mam LPT i STK200 ale z Ponyprogiem nie sprawdzałem.

Sprawdzałem pod ISP Programmer - to samo. Odczytuje sygnaturę trzy razy 0x53.

Może zewnętrzny Clock potrzebny?
A przewody od programatora do tiny nie za długie przypadkiem?

N.

Jaki zewnętrzny? Odczytuje 128kHz itd. Problem w tym że teraz coś się stało że nie idzie ich zmienić - chyba z 50x pod rząd próbowałem - ciągle wraca na 0x53.
Czuję że zasili grono poległych.

Mirkowy MKAvrCalculator ma taki zwyczaj że przy sprawdzaniu procesora schodzi do bardzo małej częstotliwości- na pewno poniżej 5kHz.
Sprawdziłem- po jego użyciu i ponownym włączeniu programatora w AVRStudio trzeba za każdym razem ustawiać częstotliwość na większą.
Niestety z AVRISPmk2 nie potrafię tego programu uruchomić.
Może masz jakiś AVRisp albo STK500v2- z tymi działa.
Z STK200 nie sprawdzałem- ale powinien działać.

Mam jego program i STK200 i jeszcze na nim sprawdzę.

Też miałem podobny problem z Attiny13 i STK200, więc trafił do szuflady. Ale niedawno spróbowałem ponownie zmienić fusybity przy użyciu programatora USB Asp i o dziwo udało mi się je zmienić. Jeśli masz taki programator to spróbuj nim.

ks_fenix wrote:

... spróbowałem ponownie zmienić fusybity przy użyciu programatora USB Asp i o dziwo udało mi się je zmienić. Jeśli masz taki programator to spróbuj nim.

Słuszna uwaga, tu można zejść tak nisko z SCK z programatora, że procek może być taktowany nawet częstotliwością kilka kHz. Sam na pewno próbowałem z USBASP przy taktowaniu z zewn. generatora TTL ok 22kHz zmieniać fuski w ATtiny2313. Zero problemów.

Mi na STK500v2 też tak nisko z częstotliwością schodził że w AVRStudio trzeba było zmieniać częstotliwość żeby zechciał programować.
No ale nie wiem czy każdy klon tak działa.

Witam
Programując Fuse bity w ATmega8 nie chcący ustawiłem na external low freq XTAL i przestała działać komunikacja przez SPI w Bascomie. Czy jest szansa na odblokowanie kostki ?

Tak, najlepiej podepnij jakiś kwarc o niskiej cz.

Podpiąłem kwarc zegarkowy i dalej to samo

Quote:

Podpiąłem kwarc zegarkowy

Przeczytaj ten wątek w całości (a jest tego trochę) a dowiesz się jakim sposobem naprawić swój błąd.

Program Mirka jest FREE co oznacza że muszę go kupić abym mógł cokolwiek zrobić z ATTiny13 - szkoda że do książki nie dodał na płycie pełnej wersji.

Bilans jest taki że zarówno AVRStudio jak i ISPPROG "poprawnie" odczytują sygnaturę 0x53 0x53 0x53 jak i fusebits ale nie potrafią ich zmienić. Szkoda mi już czasu na kombinacje za 3 zł - ten AVR już poległ i NIECH SPOCZYWA W sPOKOJU.

A czy próbowałeś zaprogramować procesor poprzez Bascoma?
Miałem ostatnio także problemy z usbaps i stk200 w Eclipse.
Raz mogłem zaprogramować a 20 razy nie. Niby odczytywał dane z procka ale czasem nawet fusebitów nie szło przestawić.
Dla testu uruchomiłem nową wersję Bascoma i odziwo problemu nie ma. Idzie zarówno zapisywać jak i odczytywać dane.