Witam,
Powróciłem do swojego projektu na atmega8u2 z którym miałem już problem przy flashowaniu, problem rozwiązałem z pomocą forum. Teraz natomiast mam trochę inny problem. Programator niby czyta sygnaturę, niby flashuje procka a finalnie zwraca błąd że ma fuse bity źle ustawione. Po poprawnym ustawieniu fusów, bez zwrotki błędu, historia się ponawia. Czyli wychodzi na to że ten zapis fusów jest mało skuteczny. Próbowałem już dwóch programatorów efekt podobny. Nie mam pojęcia o co może chodzić

czyli co? nie zapisuje ci fusebitów ? bo tego nie napisałeś. A procek jest nietypowy i stąd taka historia panie

------------------------ [ Dodano po: kilkunastu sekundach ]

czyli co? nie zapisuje ci fusebitów ? bo tego nie napisałeś. A procek jest nietypowy i stąd taka historia panie - może zassaj sobie najnowsze avrdude i tam on będzie dodany

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Jest niewiele dostępnych procków w takiej obudowie, potrzebne jest sporo pinów i zarazem nie ma na to miejsca;/ stąd taki a nie inny wybór. Chociaż z tej perspektywy wolałem wziąć attiny. Wygląda na to że jakoś przestawiłem fusebity i nie mogę tego odwrócić. Niby czyta sygnaturę niezależnie od kwarcu czy jego braku i zwraca fuse ok, flash zapisuje ale przy weryfikacji zwraca że fus low ma wartość 20 zamiast 62. Więc po kolejnym zapisie fusebitów przeze mnie zwracat fuse ok, ale przy flashowainu i weryfikacji już są błędy. Fuse low na 20 oznacza że trzeba zewnętrzny generator wpiąć i tak próbowałem, podałem sygnały od 1-5MHz i niestety to samo. Zmieniłem finalnie programator na stk500v2 pożyczony od znajomego i tutaj w ogóle się nie dogaduje. Cały czas rc=-1. Chyba udało mi się zabić procka.

Problem udało się zażegnać, chociaż nie wszystko zachowuje się w pełni przyzwoicie. Postanowiłem podać jeszcze raz sygnał zegarowy z DDS, tym razem 8MHz, i zadziałało. Co prawda uC zgłosił jeszcze 2 razy błędne fusy, ale teraz już zrobiłem około 20 prób flashowania i wszystko działa z weryfikacją włącznie. Mam nadzieję, że jeśli ktoś trafi na podobne problemy ten temat mu trochę pomorze;) Martwią mnie te dwukrotne errory ale zobaczymy co będzie dalej.

Przejąłem projekt po koledze @kuba_adam. Niestety programowanie nadal nie działa. Przeanalizowałem schemat elektryczny i znalazłem jedną nieścisłość. Wyprowadzenie PD7 atmegi podłączone jest bezpośrednio do masy. W datasheet od Atmega8u2 można wyczytać, że za pomocą PD7 można wprowadzać procesor w tryb bootloadera. Jeśli dobrze interpretuję dokumentację to fabrycznie fusebity są tak ustawione aby dało się wprowadzić atmegę w ten stan. Zastanawiam się czy jeśli procesor rzeczywiście wchodzi w bootloader to czy programowanie po ISP wtedy będzie działało? Może to właśnie pin PD7 jest tutaj problemem? Zanim przetnę ścieżkę od GND do PD7 chciałbym oszacować jaka jest szansa, że to właśnie w tym połączeniu leży problem.

A kto w ogóle robi takie herezje żeby pin I/O procka przylutowywać bezpośrednio do masy ???

To się robi przez rezystor do GND - typowy Pull DOWN a nie przyspawanie do masy.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Herezja jest i to spora. Aby tego było mało, połączenie zostało wykonane pod procesorem (QFN) na płytce 4 warstwowej. Cięcie ścieżki w tym miejscu będzie dość ryzykowną zabawą. Jutro przyniosę do firmy swoją płytkę ATB - może na programatorze z tego zestawu coś ruszy. Na analizatorze stanów logicznych widać, że na linii MOSI jakieś dane się pojawiają. Nie działa ani wgrywanie fuse bitów ani odczytywanie. MISO cały czas jest w stanie wysokim.

ooo to nieźle polecieli - ale w sumie jeśli zrobili jakieś gotowe konkretne urządzenie które nigdy nie będzie zmieniane to się nic nie stanie. Nie mniej dla potrzeb serwisowych chociażby to jest strzał w stopę i kolano jeśli jeszcze zrobili tak jak piszesz - masakrung

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Na szczęście jest to tylko prototyp w ilości 1 szt. Przetestuję jeszcze z innym programatorem. Jeśli to nie pomoże, wlutuję nową atmegę.

aaa to twoja płytka

chociaż dziwne że jeśli ten PD7 nie bierze udziału w programowaniu ISP to nie powinien przeszkadzać ... Dlatego, że programowanie ISP daje RESET a wtedy wszystkie piny są w stanie Hi-Z więc ta masa sobie może tam być przyspawana w tym wypadku - a zaczyna się procedura programowania ISP

dobra ale coś mi się wydaje że źle robisz - zostaw rzeczywiście na razie ten PD7 i na przyszłość pamiętaj o rezystorze.

A teraz to nie ZAPISUJ do procka razem wsadu i fusbitów - po co ?

NAJPIERW wgraj wsad a później oddzielnie fusebity

------------------------ [ Dodano po: 1 minucie ]

poza tym to może być problem samych połączeń ISP jakieś mikro zwarcia - może coś z zasilaniem

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Płytkę dostałem już polutowaną na gotowo, HW wykonywała inna osoba ale nie to jest w tej chwili istotne.

Obecnie używam programatora sprzed 10 lat. (Płytki arduino z atmega328 wykrywa poprawnie)

Obstawiam, że problemem może być jedna z poniższych opcji.
- programator nie obsługuje rodziny U2
- brak połączenia (niedolutowana jedna z nóżek procesora)
- procek który obecnie znajduje się na PCB jest zablokowany fuse bitami lub jest uszkodzony.

Gdyby było jakieś zwarcie na liniach MOSI, RST, MISO lub SCK do GND nie miałbym stanu wysokiego na analizatorze więc zwarcia do thermal pada raczej nie ma.

7 lat programowania STM32 i tutaj taki projekcik mi wpadł. Nie spodziewałem się, że AVR jeszcze kiedyś minie dopadną. Powrót do przeszłości normalnie:)

Na chwilę obecną nic nowego nie wymyślę - czekam na nową atmegę

Wiesz co to oznacza ISP ? czy nie wiesz ? oj chyba nie - skoro masz w nocie że procek działa w ISP i masz programator który działa po ISP to wniosek zupełnie nietrafiony


Gdyby tak było na linii ISP to w ogóle by nie wykrywał procka i nawet nie próbował programować - miałbyś komunikat z avrdude rc=-1


No to znowu nie do końca teraz wiesz o fusebitach - gdyby nawet był zablokowany - to jakbyś mógł odczytać go albo coś zapisywać - cokolwiek ? (a tym bardziej uszkodzony)

Owszem jakieś złe połączenia czyli np zimny lut na którejś z linii ISP to tak, zły kabelek od programatora np za długi itp

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Próbuję wskrzesić swój stary zestaw ATB 1.04. Napotkałem na dziwny problem z wykrywaniem wbudowanego programatora.
Na wersji darmowej mkAVRCalculator, programator jest wykrywalny, po dodaniu licencji i zresetowaniu aplikacji już nie do końca.


W między czasie przygotowałem krótsze kabelki połączeniowe (około 10cm).
Debugowanie rozpocznę od testów na:
1. krótszych kabelkach.
2. wbudowanym w zestaw ATB programatorze
3. nowym procku

bo rozprogramowałeś sobie FT232 albo jest z tak starych czasów ten zestaw, że jeszcze był przed zdalną aktualizacją automatyczną a ty w tym czasie nie włączałeś zestawu i mkavrcalculatora który potrafił automatycznie zaprogramować FT232 w zestawie ATB

Tak czy inaczej trzeba teraz poprawnie zaprogramować FT232R

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]