Jak wyłączyć JTAG w Atmega32 bez blokowania procesora?

Jest jakiś w miarę prosty sposób na wyłączenie jtaga? Dzisiaj próbowałem z jakimiś komendami to zablokowałem jeden procesor ;/ .

skyline11 napisał:

Jest jakiś w miarę prosty sposób na wyłączenie jtaga?

JTAG-a wyłącza się poprzez przestawienie odpowiedniego (JTAGEN) Fusebit'a w stan "Disabled" + dodatkowo ODCEN (również na "Disabled").
http://www.voytek.evbox.pl/programy/fusebity/fuse_m16.html

Tutaj masz dobry kalkulator: http://www.engbedded.com/fusecalc

skyline11 napisał:

Dzisiaj próbowałem z jakimiś komendami to zablokowałem jeden procesor

Z jakimi komendami. Niestety domyśleć się nie potrafi(my).

Na zablokowane procesory pomaga programator równoległy i fusebit doctor.

Według poniższego linku:

http://www.engineersgarage.com/embedded/avr-microcontroller-projects/disable-jtag-port

gościo twierdzi, że wystarczy 2 razy wpisać komendę "MCUCSR|= (1<<JTD);". Niestety, łącząc się za pośrednictwem AVR Studio 4 z mikrokontrolerem wyskakuje mi w zakładce "Fuses", że pin "SPIEN" jest zaznaczony (z tego co się orientuję ten pin odpowiada za transmisję isp, a jeżeli jest zaznaczony to znaczy że jest wyłączony).

Ale spien nie ma związku z jtagiem, a użycie jtd nie zmieni fusebitow, ale wyłączy jtag podczas wykonywania programu.

Dokładnie. Ja w atmedze 644P wyłączam JTAG w ten sposób

Trzeba 2 razy ustawić ten bit w ciągu kolejnych kilku cykli zegara, żeby zaskoczyło.

Tak, i wtedy JTAG jest wyłączony do momentu resetu procesora.
Natomiast po resecie procesora, a przed momentem wywołania tych instrukcji (musimy na czas ich wykonywania zablokować przerwania) JTAG jest aktywny.
A stan tego bitu nie wpływa na JTAGEN we fusebitach, a tym bardziej na SPIEN, którego wyłączenie z poziomu SPI jest niemożliwe

piotrva napisał:

a tym bardziej na SPIEN, którego wyłączenie z poziomu SPI jest niemożliwe

Możesz rozwinąć tą myśl?
Zawsze myślałem (i byłem tego pewny), że programatorem ISP można sobie wyłączyć owe SPIEN. Tyle, że drugi raz się już nie połączę - więc np. weryfikacja fusebitów zawiedzie.
Żeby je ponownie włączyć - konieczny jest programator równoległy.
Dobrze myślę?

A przy okazji (jeśli można)
OCDEN - to on odpowiada za debugowanie, prawda?
To po co są dwa bity ( JTAGEN i OCDEN )?

Z tego co pamiętam jak kiedyś z kol. manekinen rozgryzaliśmy sprawę i w większości AVR SPIEN nie jest dostępny przez ISP, co potwierdzają też dokumenty Atmela (bodajze AVR ISP User Guide)
EDIT (bo kol. @U.P. wyedytował zanim wysłałem wiadomość):
Odpowiadając dokładnie na pytanie - w większości AVR nie dostaniemy się do SPIEN poprzez ISP, choć mogą być wyjątki (głównie w seriach Tiny - jak podaje AVR ISP User Guide).

Do ponownego ruszenia tego fusebitu potrzebna jest jakakolwiek inna komunikacja z procesorem przez programator - może być to JTAG, o ile nie został wyłączony, a zawsze uda się nam taka operacja przez HVSP/HVPP, czyli programator wysokonapięciowy.

Podobnie sprawa ma się z RSTDSBL, tyle że on jest za to dostępny przez ISP prawie zawsze (wg. dokumentacji Atmela mogą być wyjątki, ale nie spotkałem się z takowym).

Co do OCD i JTAGEN - OCD odpowiada za kontrolę debugowania, JTAGEN - za włączenie interfejsu JTAG (możemy zatem wyłączyć debugowanie, pozostawiając możliwość programowania). Dokładnie opisano to np. tu: http://www.avrfreaks.net/modules/FreaksArticl...rstanding%20JTAG%20fuses%20and%20Security.pdf

Np Atmega 8 datasheet strona 216 podpis pod tabelą
The SPIEN Fuse is not accessible in Serial Programming mode

miszczo997 napisał:

The SPIEN Fuse is not accessible in Serial Programming mode

Czyli z poziomu ISP nie wyłączę sobie SPIEN (programowania przez ISP)?
To skąd w takim razie tyle "blokujących się" mikrokontrolerów AVR?

Bo jest jeszcze fusebit RSTDISBL który można włączyć przy pomocy programatora szeregowego.
EDIT: i jest jeszcze możliwość ustawinia złego źródła taktowania np na zewnętrzny generator TTL albo oscylator RC.

Odpowiedź na część pytań w edytowanej wiadomości,
A zablokowane procesory są najczęściej z powodu:
1. Ktoś akurat trafi na kostkę z dostępnym SPIEN via ISP (rzadkie)
2. Przeprogramowanie RSTDSBL - wyłączenie resetu uniemożliwia komunikację po ISP
3. Ustawienie nieprawidłowej opcji źródła sygnału zegarowego w stosunku do dostępnego sprzętu (np. ustawienie taktowania na kwarc przy braku jego podłączenia, zewnętrzny sygnał zegarowy, generator RC itp.)
4. Inne opcje, np. wpisanie gdzieś wartości reserved itp.

piotrva napisał:

Ustawienie nieprawidłowej opcji źródła sygnału zegarowego w stosunku do dostępnego sprzętu (np. ustawienie taktowania na kwarc przy braku jego podłączenia, zewnętrzny sygnał zegarowy, generator RC itp.)

Przecież to nie oznacza "zablokowania" MCU, wystarczy podpiąć kwarc/generator RC/zewnętrzny zegar i powinien hulać.

piotrva napisał:

4. Inne opcje, np. wpisanie gdzieś wartości reserved itp.

Mógłbyś dokładniej to rozwinąć? Jakie są te "inne opcje/reserved".

Z całej wypowiedzi wnioskuję , że głównym problemem (wymagającym użycia programatora równoległego) blokowania ISP w AVR jest.... zablokowany RESET.

Co do dokumentacji o blokowaniu SPIEN dotarłem do tego, że :

Cytat:

"Some of the tiny AVR devices allow access to the SPIEN and RSTDISBL fuses. Unprogramming/programming these fuses will disable further ISP programming."

Czyli tylko niektóre "tinyAVR"?

mickpr napisał:

Przecież to nie oznacza "zablokowania" MCU, wystarczy podpiąć kwarc/generator RC/zewnętrzny zegar i powinien hulać.

To co dla nas jest oczywiste, niestety czasem nie jest oczywiste dla początkujących - dla nich czasem niestety podpięcie generatora TTL, czy RC jest wyzwaniem.
Oczywiście, jak to niektórzy Koledzy piszą, wtedy procesor jest "zablokowany", a nie zablokowany. (Kiedyś na Alle... kupiłem tak chyba 5-6 sztuk "zablokowanych" Atmega8 za grosze)
Tu ciekawostka, że kiedyś testowałem różne tryby i zawsze (choć nie pamiętam czy sprawdziłem wszystkie możliwe ustawienia CKSEL), niezależnie od ustawienia Fusebitów, pomagał generator TTL 1MHz podpięty pod XTAL1.

Wpisanie wartości reserved - czasem niektóre fusebity są oznaczone jako reserved (np. kombinacje CKSEL itp.) i nie powinny być zapisywane daną wartością. W tej chwili nie pamiętam dokładnego przykładu, ale pamiętam, że w którymś modelu powodowało to dziwne problemy z dalszym programowaniem (oczywiście HV zawsze pomaga).

Inne opcje - mam tu na myśli np. uszkodzenie sygnatury - niby niemożliwe, a jednak się zdarza (najczęściej w wyniku zakłóceń podczas programowania). Czasem dla niektórych osób programowanie w trybie "force" i komunikaty ostrzegawcze też są postrzegane jako zablokowanie procesora.

Co do tego które to procesory mają dostęp a które nie nie powiem Ci nic z autopsji, bo kwestia ta mnie bardziej nie interesowała, gdyż jeśli korzystałem z ISP to nie miałem potrzeby wyłączania, a jak robiłem zabezpieczenie na zasadzie całkowitego odcięcia interfejsów programowania to wystarczało mi RSTDSBL, albo całe programowanie szło przez HV i wtedy wszystko było wyłączone.

@piotrva - Dziękuję za wyjaśnienie

Jednak atmega wcale mi się nie zablokowała, a jtaga wyłączyłem za pomocą AVR Studio (po połączeniu z mikrokontrolerem wystarczy w zakładce "Fuses" odznaczyć pole "JTAGEN".