Nastał u mnie sezon cudów...

Jest tak :

Urządzenie z atmegą 128.
Programuję sobie z użyciem MkAvr Calculatora (bo wygodny), albo np.
SinaProg oraz programatora USBASP.

No i od czasu do czasu zdarza się, że coś się przy programowaniu wywali,
po czym oczywiście atmega przestaje dawać oznaki życia.

Ok, zatem za pomocą zestawu program + kabelek do LPT + generator 4Mhz
stawiam atmegę na nogi. Znaczy resetuję fusy.
(tutaj zapodany program dosowy i schemat kabelka ;
http://www.edaboard.com/thread131804.html)

Wracam zatem do SinaProga - atmega się zgłasza, ustawiam ponownie fusy
poprawnie.

Wydaje się, że będzie OK.
Ale nieeeeee - programowanie flesha wywala przy weryfikacji błędy.
Programowanie eeprom - ok.

I tak sobie próbuję n-razy ten flash zaprogramować. Zawsze błąd
weryfikacji. Po którymś razie - wywala się AVRDUDE, i atmega znowu
wylatuje w kosmos. Znaczy fusy spieprzone.

I tak można się bawić w kółko macieju.

Mógłbym podejrzewać, że USBASP coś nie halo - ale jak wymienię atmegę na
nową - będzie ok. (przerabiałem to).

Może ktoś mi to wyjaśnić ??

do góry

Jeszcze spróbuję to samo z AVRDRAGON, bo mam pod ręką.
Ale jakoś przeczucie mi mówi, że nic to nie zmieni...

do góry

A jeszcze słowo dodatkowe ;

ostatnie wywalenie zrobiłem z MkAVrCalculator, i przy programowaniu
flasha miałem włączony podglad AVR DUDE.

I tenże mi wyświetlił na koniec programowania, że fusy zostały zmienione
; znaczy poprzednio była jakaś wartość (np. 3F) a teraz 00, i czy chcę
przywrócić poprzednie wartości y/n.

Oczywiście dałbym Yes, ale to okienko podglądu w MkAvrCalculator nie
jest responsywne, więc oczywiście dupa i atmega padła.

Ale - ważniejsze jest, że wygląda na to, że podczas programowania są
czasem zmieniane wartości fusów i to jest ciekawe - dlaczego ??

do góry

On Thu, 09 Oct 2014 22:22:52 +0200, sundayman
<s...@p...onet.pl> wrote:
> No i od czasu do czasu zdarza się, że coś się przy programowaniu
wywali,
> po czym oczywiście atmega przestaje dawać oznaki życia.
> Ok, zatem za pomocą zestawu program + kabelek do LPT + generator
4Mhz
> stawiam atmegę na nogi. Znaczy resetuję fusy.

Tak trochę offtopicznie (nie znam się na atmegach stąd pytam). Co to
za problem, że atmega przy programowaniu "sie wywali"? Że jakoś
specjalnie trzeba stawiać na nogi po błędnym flaszowaniu? Nie można
po prostu jeszcze raz zaprogramować? Opisujesz to tak, jakby samym
procesem programowania można było coś popsuć.

--
Marek

do góry

> Tak trochę offtopicznie (nie znam się na atmegach stąd pytam). Co to za
> problem, że atmega przy programowaniu "sie wywali"? Że jakoś specjalnie
> trzeba stawiać na nogi po błędnym flaszowaniu? Nie można po prostu
> jeszcze raz zaprogramować? Opisujesz to tak, jakby samym procesem
> programowania można było coś popsuć.

No bo można. Błędne ustawienie fusów powoduje, że programowanie ISP
przestaje działać.

W lepszym przypadku daje się to przywrócić przez podłączenie
zewnętrznego generatora i odpowiednią operację na ISP.

W gorszym - tylko wyciąganie układu i programowanie go równoległe (w
moim przypadku to bez sensu, bo atmega 128 jest TQFP 64 więc jak
wylutuję, to łatwiej wstawić nową niż walczyć ze starą...)

do góry

On Thu, 09 Oct 2014 22:54:11 +0200, sundayman
<s...@p...onet.pl> wrote:
> No bo można. Błędne ustawienie fusów powoduje, że programowanie ISP
> przestaje działać.

Myślałem, że ISP jest podstawowym i zawsze działającym programowaniem
bez
względu na konfigurację.

--
Marek

do góry

> Myślałem, że ISP jest podstawowym i zawsze działającym programowaniem
> bez względu na konfigurację.

no niestety nie.
Ale że Atmel nie zrobił jakoś prościej możliwości zerowania MCU , to imo
nieporozumienie.

Oprócz ISP jest jeszcze (w mniejszych modelach) "szeregowe programowanie
wysokonapięciowe", z jakąś rozsądną ilością pinów, ale duże atmegi imo
mają tylko "pełne" programowanie równoległe jak ratunek, a to w
przypadku procesorów TQFP jest jakieś nieporozumienie.

Jeśli się mylę, to niech ktoś wyprostuje...

do góry

użytkownik Marek napisał:
> Opisujesz to tak, jakby samym
>
> procesem programowania można było coś popsuć.
>


Nie znasz megi/tiny:) Sa 2 mozliwosci, jak ustawisz
reset na IO lub wylaczysz ISP, a tak se wymyslili.
Pomaga przerobka programatora i podanie na reset
zamiast 5V - 12V, tak jak w picakach.

do góry

W dniu 2014-10-09 22:22, sundayman pisze:
> Nastał u mnie sezon cudów...
>
> Jest tak :
>
> Urządzenie z atmegą 128.
> Programuję sobie z użyciem MkAvr Calculatora (bo wygodny), albo np.
> SinaProg oraz programatora USBASP.
>
> No i od czasu do czasu zdarza się, że coś się przy programowaniu wywali,
> po czym oczywiście atmega przestaje dawać oznaki życia.
>
> Ok, zatem za pomocą zestawu program + kabelek do LPT + generator 4Mhz
> stawiam atmegę na nogi. Znaczy resetuję fusy.
> (tutaj zapodany program dosowy i schemat kabelka ;
> http://www.edaboard.com/thread131804.html)
>
> Wracam zatem do SinaProga - atmega się zgłasza, ustawiam ponownie fusy
> poprawnie.
>
> Wydaje się, że będzie OK.
> Ale nieeeeee - programowanie flesha wywala przy weryfikacji błędy.
> Programowanie eeprom - ok.
>
> I tak sobie próbuję n-razy ten flash zaprogramować. Zawsze błąd
> weryfikacji. Po którymś razie - wywala się AVRDUDE, i atmega znowu
> wylatuje w kosmos. Znaczy fusy spieprzone.
>
> I tak można się bawić w kółko macieju.
>
> Mógłbym podejrzewać, że USBASP coś nie halo - ale jak wymienię atmegę na
> nową - będzie ok. (przerabiałem to).
>
> Może ktoś mi to wyjaśnić ??

Być może masz za długi kabelek od programatora do mikrokontrolera lub
ustawiłeś za dużą szybkość programowania. Zapnij zworkę SLOW w USBAsp i
zobaczysz, czy błąd się powtarza. Ale będziesz dłuuuuugo czekać.

P.P.

do góry

Użytkownik "sundayman" <s...@p...onet.pl> napisał w wiadomości
news:m16v4t$as6$1@node2.news.atman.pl...
>
> Oprócz ISP jest jeszcze (w mniejszych modelach) "szeregowe programowanie
> wysokonapięciowe", z jakąś rozsądną ilością pinów, ale duże atmegi imo
> mają tylko "pełne" programowanie równoległe jak ratunek, a to w przypadku
> procesorów TQFP jest jakieś nieporozumienie.
>
> Jeśli się mylę, to niech ktoś wyprostuje...

Tak chyba faktycznie w mega było.
Od 5 lat używamy Xmega programowanych przez PDI.
Nawet nie wiem, czy mają równoległe programowanie.

Coś im początkowo nie wyszło z progami brown-out.
OIDP były inne niż w karcie katalogowej. Potem w kartę wstawili te
prawdziwe, a potem coś poprawili i teraz znów są te co miały być od
początku. Już się sytuacja normuje.
Poruszam ten temat bo nieświadomy tego zablokowałem sobie procesor wpisując
brown out np. 3V0, co faktycznie oznaczało 3V49 no i przy 3V3 procesor nie
chciał gadać.
Jak się zorientowałem, że to może być przyczyna podpiąłem do 3V3 w układzie
zasilacz laboratoryjny i się z procesorem dogadałem.
P.G.

do góry