Witam,

Próbowałem ostatnio ustawić moją atmegę 328 jako USB HID z użyciem V-USB. Po wielu próbach udało mi się, by była wykrywana poprawnie przez Windowsa, po czym zabrałem się za przesył danych. Wraz z biblioteką V-USB przychodzą przykłady - jeden z nich służy do zapisu i odczytu paczki danych do EEPROM'u mikro. Po pierwszej próbie zapisu bajtu danych mikrokontroler natychmiast rozłączył się (przestał być wykrywany poprawnie jako HID). Od tego czasu przy każdej próbie zapisu extended fuse bitów wyrzuca błąd niespójności:

Jeżeli chodzi o high i low fusy to nie ma żadnych problemów (nie było na początku - czytaj dalej). Jakiś wpływ na zapis efuse'ów jest, ponieważ przy próbie z różnymi wartościami są różnice przy weryfikacji (próbując zapisać 0xFF faktycznie zapisywane jest 0x07, przy 0xFE -> 0x06, przy 0xFD->0x05). Również wgrywane na mikro programy działają bez zarzutu, choć przy ich wgrywaniu bez załączonego zasilania również występuje błąd niespójności danych (wcześniej tego nigdy nie zauważyłem). No i co najważniejsze, w żaden sposób nie mogę dojść do tego by mikro ponownie został poprawnie wykryty jako HID, a to największy problem. Były próby zmiany efuse'ów zarówno z zewnętrznym zegarem jak i wbudowanym, z dzieleniem / 8 i bez, z zewnętrznym zasilaniem, czy w trybie unsafe.

Po ostatniej próbie zapisu low fuse bitów wartość zadana przeze mnie również została przekręcona i straciłem kontakt z mikrokontrolerem. Kupiłem nową atmegę328P, ale problem występuje nadal. Próbowałem również z programatorem usbasp kolegi i z użyciem jego komputera - dalej to samo. Rozłożyłem cały układ, wymieniłem wszystkie kabelki i komponenty na nowe, zmontowałem na nowo w innym miejscu płytki stykowej - dalej to samo. Używałem 3 różnych wersji avrdude (5.8, 5.11, 6.1), naturalnie bez skutku. Jakieś pomysły?

Schemat układu (na resecie jest pull-up 10k Ohm, zapomniałem go dodać do schematu) (przepraszam za brak zgodności z jakimikolwiek normami, ale robie to pierwszy raz i z pierwszym znalezionym programem):

pisałem niedawno i to szeroko na forum o tej kwestii

przy programowaniu fusebitów na niektórych prockach szczególnie na 16mega48/88/168/328 i podobnych po prostu w MkAvrCalcu nie włączać Weryfikacji i wszystko będzie działać poprawnie .... a jeśli chodzi o przyczyny to trzeba znaleźć ten wątek gdzie pisałem o fusebicie extended i dlaczego weryfikacja w jego przypadku nie ma znaczenia

_________________
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 ]

http://forum.atnel.pl/topic9080.html#p102613 (ten post i następny Mirka).

Co do korelacji między efusami i niedziałaniem V_USB: te efusy odpowiadają za ustawienie poziomu BOD (Brown-out detection) czyli ustawieniem minimalnego napięcia zasilania przy którym uC może działać - poniżej ustawionego napięcia proc. wchodzi w stan resetu. Wartość 0x7 (czy jak wolisz 0xff, to wszystko jedno) to wyłączenie detekcji. Trudno się chyba dopatrzyć jakiejś korelacji.

_________________
+++++[>++++<-]>[>++++++<-]>.---------.+++.

MkAvrCalculator WCALE nie przekręca wartości fusebitów to już twoja nadinterpretacja ....

------------------------ [ Dodano po: 2 minutach ]



dokładnie a korelacja może być co najwyżej taka gdy ktoś sobie ustawi zły próg np zbyt wysoki a ma pokaszanione napięcie zasilania i wtedy procek prawie cały czas np jest w stanie RESET i wydaje się być jak zablokowany ... tymczasem do oblokowania wystarczy co ? podać prawidłowe napięcie

_________________
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 ]

Wszystko jasne. Nigdy mi nie przyszło na myśl, że te nie istotne bity pozostają nieruszone... Naturalnie w tym wypadku 0xFD == 0x05. Aż wstyd się przyznać do takiego niedopatrzenia.


Nigdy nie używałem programu o którym Pan wspomina - winię avrdude za "przekręcanie" (czyli moją głupotę )

Wydaje mi się jednak, że nie poinformowanie przez avrdude użytkownika o pomyślnym zapisie (jak choćby w przypadku efusów i nieszczęsnego 0xFD == 0x05) i wywalanie błędu niespójności, jest mocno mylące, szczególnie dla początkującego.

Jeżeli zaś chodzi o przekręcenie low fusów, o którym wspomniałem - tutaj zapis jest jednoznaczny (cały bajt jest istotny), a mimo to na mikro weszła inna wartość niż podana przeze mnie (niestety nie zrobiłem zrzutu ekranu). Być może miało to związek z wcześniej załączonym brown-outem i faktycznym błedem zapisu spowodowanym niepoprawnym zasilaniem.

Bardzo dziękuję za rozwiązanie mojego problemu