Ubiłem Atmegę? Błąd z "expected signature for ATmega328P is 1E 95 0F" oraz niedziałający reset

[KatzePL]

1 godzinę temu, rafal220 napisał:

jak masz zrobione to filtrowanie? Bezpośrednio pomiędzy pinem reset a GND? Do normalnej pracy nie mam nic przeciwko, ale w czasie programowania bym się zastanowił czy ten kondensator nie wprowadza jakiś opóźnień.

Po prostu pin podciągnięty do zasilania za filtrem...

 

59 minut temu, Sheppard25 napisał:

Nie mam również dlatego zmontowalem uklad na prototypowej, najpierw bez oscylatora potem z oscylatorem, podpialem woltomierz (pominalem tylko reset z programatora bo chyba do sprawdzenia polaczenia nie jest konieczne). Woltomierz pokazuje 0 mimo ze na wyjsciach pomiedzy VCC i GND mam 5V. 

Odłącz reset tak jak napisałem i sprawdź stan RST na wyjściu programatora. Reset powinien być wyzwalany stanem niskim, nie odwrotnie.

Podaj jakiego dokładnie programatora używasz, bo są i różne klony. Niektóre mają zworki do ustawień i trzeba będzie ustawić.

[Gość]

@KatzePL Luknij na tą fotkę którą wstawił @Sheppard25. Przecież reset ma podciągnięty bezpośrednio poprzez rezystor do V+ (chyba V+ bo drugiego końca rezystora nie widać). A 0V ma dlatego ponieważ mierzy napięcie bezpośrednio na rezystorze... Do tego twierdzi, że wcześniej to działało co świadczy że zworki powinny znajdować się w dobrej konfiguracji. Zastanawiam się, czy czasem jakieś bugi przypadkiem nie utknęły w pamięci megi podczas wgrywania programu. Niepewna podstawka, niepewne zasilanie itd.  

 

[Sheppard25]

@KatzePL @rafal220 Dokładnie, reset jest podciągnięty do zasilania przez rezystor, tam musi być napięcie równe napięciu zasilania na tym oczku. Nawet zakładając że prąd tam jest bardzo mały to powinien być mierzalny, jednak ani podpinająć szeregowo żeby zmierzyć prąd ani równolegle żeby zmierzyć napięcie mamy równe 0, żadnych minimalnych wartości. Kupię dziś drugą Atmegę i sprawdzę czy działa, niemniej wolałbym wiedzieć jak to się popsuło, żeby nie ubijać tych kontrolerów które tanie nie są  

Jeżeli chodzi o jakieś fakapy w pamięci, to pytanie czy to ma wpływ na samo połączenie, zczytanie fusbitów. Co do podstawki i zasilania, no tu nic lepszego nie wymysle, zrobiłem to nawet na płytce prototypowej i sytuacja jest ta sama.

Czy płytka mogła się ubić bo np przypadkowo zwarłem GND z VCC na pinach albo puściłem wysoki prąd na RESET? 

[Gość]

52 minuty temu, Sheppard25 napisał:

albo puściłem wysoki prąd na RESET

To trzeba by wiedzieć czy w linii programatora masz jakieś rezystory ograniczające. Jeżeli nie ma, to teoretycznie jeżeli podciągnąłeś reset bezpośrednio do zasilania w czasie programowania, to mogłeś coś ubić.

55 minut temu, Sheppard25 napisał:

Jeżeli chodzi o jakieś fakapy w pamięci, to pytanie czy to ma wpływ na samo połączenie, zczytanie fusbitów

Swojego czasu na tej kiepskiej podstawce z dźwignią zablokowała mi się jedna mega168 w czasie programowania fusebitów. Z tego co pamiętam to chyba użyłem innego programatora do jej odblokowania. Zresztą już nie używam tych podstawek bo są kiepskie. Bywało że często nie miałem styku (brak połączenia), albo jakieś bzdury w czasie odczytywania fusebitów.  

[Sheppard25]

10 godzin temu, rafal220 napisał:

 Przez rezystor płynie tak mały prąd, że możesz nie zauważyć spadku napięcia na rezystorze w zakresie "V" z tond te 0V. Zmierz pomiędzy RST a GND.

No dobrze sprobuje ale troche sie zastanawiam jak to dziala to podciagniecie ze jak wcisne przycisk to tam jest 0V skoro oba uklady maja obieg. GND jest za przyciskiem ktory jest rozwarty wiec w tym oczku nie ma pradu ale jak rozumiem w oczku z resetem juz jest, masa jest ta sama a gdy przycisk wcisne oba oczka powinny miec prad (chyba ze w samej atmedze jest cos co to kontroluje, jakis tranzystor czy cos). 

[_LM_]

Sprawdź omomierzem ten pin do zasilania i do masy. Zrób pomiar kiedy at jest w podstawce i poza nią. Jak reset jest permanentnie zwarty do której linii to mikrokontroler jest tango down

 

[_LM_]

Mogłeś go uszkodzić ładunkiem statycznym. AVR są dość wytrzymałe przynajmniej te oryginalne. Ale tu ciężko powiedzieć 

[Gość]

29 minut temu, Sheppard25 napisał:

No dobrze sprobuje ale troche sie zastanawiam jak to dziala to podciagniecie ze jak wcisne przycisk to tam jest 0V skoro oba uklady maja obieg. GND jest za przyciskiem ktory jest rozwarty wiec w tym oczku nie ma pradu ale jak rozumiem w oczku z resetem juz jest, masa jest ta sama a gdy przycisk wcisne oba oczka powinny miec prad (chyba ze w samej atmedze jest cos co to kontroluje, jakis tranzystor czy cos). 

Ale wykonałeś pomiar o który prosiłem? Czyli napięcie bezpośrednio pomiędzy RST a GND. Podciąganie w tym przypadku działa na tej zasadzie, że kiedy port jest ustawiony jako wejście resetujące, to znajduje się on w stanie wysokiej impedancji i nie ma opcji ażebyś pomierzył jakieś nA płynące przez rezystor podciągający do V+ na zakresie V w multimetrze (spadek napięcia na rezystorze podciągającym 10k). Zwłaszcza że ten w środku US (prawdopodobnie 100k ?) też podciąga RST do V+  

Gdy wciśniesz przycisk to prawidłowo pomiędzy RST a GND powinno pojawić się 0V a spadek napięcia na rezystorze ~5V. Kiedy przycisk jest rozwarty to na RST względem GND powinno być ~5V a na rezystorze ~0V.

 

[Sheppard25]

@_LM_ @rafal220 Dziękuję Panowie za zaangażowanie. Faktycznie, źle to mierzyłem, wynikało to pewnie z tego, że nie rozumiem do końca działania tego pull-up rezystora i "ściągania" do masy. Jak zmierzyłem między RESET a GND to dostałem 5V a w momencie wciśnięcia przycisku 0V czyli tak jak powinno być, dobrze zmontowałem.

Natomiast niczego to nie zmienia w kontekście samej Atmegi, która nadal nie odpowiada.

Podłączyłem nową atmegę i ona działa w porządku. 

Edytowano Sierpień 20, 2024 przez Sheppard25

[Sheppard25]

Mam mały trop co mogło ubić tamten mikrokontroler. Zacząłem używać PlatformIO i gdy próbuję wgrać jakiś program z diodą na nowy (i na poprzedni też tak miałem) to wywala mi ten błąd

 

Looking for upload port...
Uploading .pio\build\ATmega328\firmware.hex
avrdude error: cannot set sck period; please check for usbasp firmware update
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9514 (probably m328)

avrdude: processing -U flash:w:.pio\build\ATmega328\firmware.hex:i
avrdude: reading input file .pio\build\ATmega328\firmware.hex for flash
         with 390 bytes in 1 section within [0, 0x185]
         using 4 pages and 122 pad bytes
avrdude: writing 390 bytes flash ...
Writing | ################################################## | 100% 0.46s
avrdude: 390 bytes of flash written
avrdude: verifying flash memory against .pio\build\ATmega328\firmware.hex
Reading | ################################################## | 100% 0.27s
avrdude warning: verification mismatch
        device 0x00 != input 0x0c at addr 0x0000 (error)
avrdude error: verification mismatch

avrdude done.  Thank you.

plus dioda zaczyna się dziwnie zachowywać, ledwo mrugać, tak jakby coś się źle wgrało. Pytanie czy PlatformIO od siebie nie dodaje jakiś flag którymi uploaduje program, np zmienia też te fusebity. Do tej pory wgrywałem programy wykonując prostą komendę w avrdude:

-p m328 -c usbasp -P usb -e -U flash:w:$(ProjectDir)Release\Testowy.hex:a

 

[Gość]

Oczywiście wgrywałeś z pominięciem tej podstawki z dźwignią? Nie wiem jak jest w PlatformIO, ale w AVRstudio ważne było ustawienie odpowiedniego programatora, prędkości transmisji danych, oraz ustawienie fusebitów. To ostatnie mogło skutkować zablokowaniem mikrokontrolera, bądź jego nieprawidłową pracą. 

Edytowano Sierpień 20, 2024 przez rafal220

[KatzePL]

12 minut temu, Sheppard25 napisał:

-p m328 -c usbasp -P usb -e -U flash:w:$(ProjectDir)Release\Testowy.hex:a

A ja bym tak ustawił:
 

-p m328p -c usbasp -P usb -U flash:w:$(ProjectDir)Release\Testowy.hex:a

I jeszcze raz sprawdź na starym uC, błędna sygnatura może wynikała z źle wpisanej wartości. Jak wywali że nie ma m328p to aktualizuj AVRdude.
 

12 minut temu, Sheppard25 napisał:

plus dioda zaczyna się dziwnie zachowywać, ledwo mrugać, tak jakby coś się źle wgrało.

W kodzie oczywiście zdefiniowałeś częstotliwość taktowania? Jak nie, to definiuj zgodnie z fusebitami. Jak nie ustawiałeś fusebitów to poszukaj domyślną nastawę.

Makro F_CPU, wartość w Hz.

#define F_CPU 16000000L

Powyżej przykład dla 16MHz.

Edytowano Sierpień 20, 2024 przez KatzePL

[Sheppard25]

4 minuty temu, KatzePL napisał:

A ja bym tak ustawił:
 

-p m328p -c usbasp -P usb -U flash:w:$(ProjectDir)Release\Testowy.hex:a

I jeszcze raz sprawdź na starym uC, błędna sygnatura może wynikała z źle wpisanej wartości. Jak wywali że nie ma m328p to aktualizuj AVRdude.

Juz ogarnalem. W platformIO miedzy flagą a jej wartoscia niep owinno byc spacji + mozna wylaczyc weryfikacje. Chat twierdzi ze blad z weryfikacja wynikac moze z taktowania i moze tak jest bo jak ustawiam miganie diody na 1sek to ona napiernicza  ze 100x szybciej. Nie ustawialem jeszcze zadnego zewnetrznego oscylatora ani nie modyfikowalem fuse bitow na nowej.

Jezeli chodzi o stara to tam juz nic sie nie da zrobic, tam nie wyrzuca juz bledow z weryfikacja tylko totalnie nie moze sie polaczyc. 

[Sheppard25]

9 minut temu, rafal220 napisał:

Oczywiście wgrywałeś z pominięciem tej podstawki z dźwignią? Nie wiem jak jest w PlatformIO, ale w AVRstudio ważne było ustawienie odpowiedniego programatora, prędkości transmisji danych, oraz ustawienie fusebitów. To ostatnie mogło skutkować zablokowaniem mikrokontrolera, bądź jego nieprawidłową pracą. 

Na nowa atmege wgralem ta moja podstawka. Pozostale parametry wybralem

[KatzePL]

9 minut temu, Sheppard25 napisał:

Chat twierdzi ze blad z weryfikacja wynikac moze z taktowania i moze tak jest bo jak ustawiam miganie diody na 1sek to ona napiernicza  ze 100x szybciej.

Jak napisałem powyżej, ustaw odpowiednio makro w kodzie. Fusebity możesz ustawić z AVRdude, ale osobną komendą. Kalkulatory fusebitów są w Internecie.
Nie wiem, jakie są domyślnie fusebity, i na jakie prędkości. Nie chce mi się szukać, na pewno są w dokumentacji. Z pewnością zewnętrzny oscylator nie będzie działać do czasu ustawienia fusebitów na zewnętrzny.

Edytowano Sierpień 20, 2024 przez KatzePL