Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Wyłączenie jtaga - Atmega32

skyline11 13 Kwi 2013 08:13 2073 17
  • #1 13 Kwi 2013 08:13
    skyline11
    Poziom 11  

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

    0 17
  • #2 13 Kwi 2013 08:44
    mickpr
    Poziom 39  

    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).

    0
  • #4 13 Kwi 2013 13:52
    skyline11
    Poziom 11  

    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).

    0
  • #7 13 Kwi 2013 15:29
    piotrva
    Moderator Mikrokontrolery

    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 :D

    0
  • #8 13 Kwi 2013 15:43
    emarcus
    Poziom 34  

    skyline11 napisał:
    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).


    Fuse "SPIEN" nie ma nic wspólnego z "JTAGEN".
    Jeżeli fuse jest zaznaczony to znaczy że jest enable inaczej włączony. Gdyby SPIEN był wyłączony nie mógłbyś się komunikowac z uC.
    Oba fusy: SPIEN orax JTAGEN fabrycznie sa włączone.
    Jeżeli nie masz potrzeby korzystania z JTAG i te piny chcesz wykorzystac jako GPIO to masz dwie alternatywy.
    Albo zrobisz to przez zmianę fusebitu: bit6 =1 w FBH (usunąc checkmark/odznaczyc JTAGEN),
    albo wpis w software ( edit MCUCSR) tak jak masz na początku twojego postu.

    Jest to konsekwencja fragmentu datasheet str 274:

    Programming via the JTAG Interface
    "This provides a means of using the JTAG pins as normal port pins in running mode while still allowing In-System Programming via the JTAG interface.........."

    e marcus

    0
  • #9 13 Kwi 2013 15:44
    mickpr
    Poziom 39  

    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 )?

    0
  • #10 13 Kwi 2013 15:50
    piotrva
    Moderator Mikrokontrolery

    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. @UP 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

    0
  • #12 13 Kwi 2013 15:57
    mickpr
    Poziom 39  

    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?

    0
  • #13 13 Kwi 2013 16:01
    miszczo997
    Poziom 27  

    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.

    0
  • #14 13 Kwi 2013 16:04
    piotrva
    Moderator Mikrokontrolery

    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.

    0
  • #15 13 Kwi 2013 16:34
    mickpr
    Poziom 39  

    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"?

    0
  • #16 13 Kwi 2013 16:51
    piotrva
    Moderator Mikrokontrolery

    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.

    0
  • #17 13 Kwi 2013 16:54
    mickpr
    Poziom 39  

    @piotrva - Dziękuję za wyjaśnienie :)

    0
  • #18 16 Kwi 2013 23:51
    skyline11
    Poziom 11  

    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".

    0