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

Atmega8 problemy początkującego programisty - 2uP uśmiercone

16 Sty 2009 19:48 1891 11
  • Poziom 13  
    Koledzy jestem początkujący jeśli chodzi o programowanie uP. Dzisiaj pierwszy raz zaprogramowałem Atmege8 i na samym początku napotkałem problem. Posiadam zakupiony programator na allegro "PROGRAMATOR ISP SI PROG 2.2 + ADAPTER EEPROM" programowałem z poziomu PonyProg2000 i niestety dwa AVRy martwe :cry: (działały przez jakiś czas a po którymś wgraniu brak komunikacji). Co może być przyczyną?

    Moje podejrzenia:
    -programator ma ponoć automatyczną możliwość przełączania napięcia z wewnętrznego (z programatora) na zewnętrzne. Czy mogło być to przyczyną awarii bo programowałem przy ciągłym zasilaniu Atmegi.
    -czy za każdym razem przed wgraniem programu muszę czyścić pamięć czy przy wgrywaniu sama się automatycznie wymazuje
    -w programach które wcześniej się wgrywały i działały nie wprowadzałem dużych zmian(program powodował miganie diody zmieniałem tylko częstotliwość migania)

    Czy macie jakiś pomysł na odratowanie atmeg i ewentualne nie uśmiercenie następnych?


    Proszę nie umieszczać linków do aukcji internetowych/plików tymczasowych itp. - Regulamin. Link skasowałem. [c_p]
  • AM TechnologiesAM Technologies
  • Poziom 34  
    Sprawdź połączenia, uważaj z ustawieniem bitów sterujących do programowania użyj Bascoma (łatwiej się ustawia opcje bitów sterujących). A do odratowania użyj opcji z zewnętrznym zegarem (dodatkowy generator wyłączone ISP) a jak się nie da trzeba by zrobić programator równoległy.
  • AM TechnologiesAM Technologies
  • Poziom 13  
    Zrobiłem na szybko programator STK200 i niestety ale nie komunikuje się z uszkodzonymi uP ze sprawnymi 'gada'. Podłączałem również kwarc 6MHz i dwa kondensatorki (30pF - nie miałem 22pF) nic nie pomaga. Co mogło spowodować uszkodzenie ze nie mogę skomunikować się. Nie bawiłem się fusebitami jedynie co zrobiłem to zmieniłem częstotliwość procesora w Makefile z 1MHz wewnętrznego na 4MHz (czy zamiast 4MHz zaprogramowanych mogę podłączyć 6MHz lub mniej bo 4 nie mam) i drobne zmiany w programie ale nawet nie programowałem nóżki od RESETU. Boję się wziąć następne uP bo mam jeszcze kilka ale nie chce żeby je spotkała podobna sytuacja.
  • Pomocny post
    Poziom 26  
    krzysztof85 napisał:
    Zrobiłem na szybko programator STK200 i niestety ale nie komunikuje się z uszkodzonymi uP ze sprawnymi 'gada'. Podłączałem również kwarc 6MHz i dwa kondensatorki (30pF - nie miałem 22pF) nic nie pomaga. Co mogło spowodować uszkodzenie ze nie mogę skomunikować się. Nie bawiłem się fusebitami jedynie co zrobiłem to zmieniłem częstotliwość procesora w Makefile z 1MHz wewnętrznego na 4MHz (czy zamiast 4MHz zaprogramowanych mogę podłączyć 6MHz lub mniej bo 4 nie mam) i drobne zmiany w programie ale nawet nie programowałem nóżki od RESETU. Boję się wziąć następne uP bo mam jeszcze kilka ale nie chce żeby je spotkała podobna sytuacja.

    w makefile nie zmienisz częstotliwości procesora. Można ją zmienić tylko za pomocą fuse'ów. Zmieniając to tylko w makefile pisząc np "_delay_ms(1)" program tak naprawdę źle obliczy czas. W twoim przypadku program obliczy ok 1/4 ms. Będzie też problem np z szybkością UARTA - źle zostanie obliczona stała służąca do kalibracji prędkości UARTA.

    Jeżeli zmieniasz prędkość w makefile, aby wszystko grało tak jak dotychczas musisz zmienić też we fusach (lub zmienić kwarc, lub sygnał zegarowy). Atmegi domyślnie są ustawione na wewnętrzny sygnał zegarowy 1MHz. Można ustawić go przestawić na 2,4,8MHz, zewnętrzny rezonator kwarcowy lub zewnętrzny sygnał zegarowy.

    W twoim przypadku albo spaliłeś uC albo namieszałeś w fusach. W fusach jeżeli zrobisz:
    - wyłączysz reset
    - wyłączysz programowanie przez SPI
    - ustawisz źródło zegara na zewnętrzny kwarc którego nie ma
    - ustawisz źródło zegara na zewnętrzny sygnał zegarowy którego nie ma
    to będziesz miał problemy z zaprogramowaniem zwykłym programatorem (na SPI).

    pozdrawiam hot-dog
  • Poziom 13  
    No właśnie między innymi bawiłem się _delay_ms(10) zmieniając je w programie sądziłem że jest to odpowiedzialne za częstotliwość migania. Czy jest to przyczyną uwalenia uP?



    Code:

    #include <avr/io.h>
    #include <util/delay.h>               

    int main(void)
    {
        DDRB  |= _BV(1);               
        PORTB &= ~_BV(1);                   
        unsigned char i;
        for (;;)
        {
          PORTB ^=_BV(1);           
              for (i = 0; i <100; i++)
                          _delay_ms(10);           
        }
        return 0;
    }


    Czy da sie coś zrobić z tym szkoda mi tych procesorów :cry:
  • Pomocny post
    Poziom 20  
    Oto sposób, którym na 99% ożywisz procesory.
    Podaj na wejście XTAL1 przebieg prostokątny o częstotliwości ok. 1MHz z zewnętrznego generatora lub z działającego procka i użyj programatora STK200. Jeśli będzie komunikacja musisz zmienić fusy dotyczące taktowania (wewnętrzny RC czy Xtal). Potem odłączasz generator i sprawdzasz. Możesz spróbować z inną częstotliwością, jaką masz pod ręką, ale raczej nie mniejszą niż 500kHz. Ja zawsze używam 1MHz lub więcej.

    Mnie udało się 'przywrócić' programowanie ISP wszystkim prockom, które przy programowaniu nagle przestały odpowiadać (nie dotyczy upalonych fizycznie). Piszę w cudzysłowie, ponieważ nie raz wykorzystuję właśnie taktowanie zewnętrzne. Aby taki kontroler programować wymagany jest ten zewnętrzny sygnał taktujący.

    Takie przypadki zdarzają się w przypadku marnej jakości programatora ISP, głównie prowadzenia przewodów sygnałowych i ich długości.
  • Pomocny post
    Poziom 26  
    krzysztof85 napisał:
    No właśnie między innymi bawiłem się _delay_ms(10) zmieniając je w programie sądziłem że jest to odpowiedzialne za częstotliwość migania. Czy jest to przyczyną uwalenia uP?

    Oczywiście że nie. Nie uwalisz w ten sposób procesora. I jest to odpowiedzialne za opóźnienie (jest w miarę dokładne jeżeli zadeklarowana częstotliwość jest równa prawdziwej częstotliwości taktowania).

    krzysztof85 napisał:
    Czy da sie coś zrobić z tym szkoda mi tych procesorów :cry:

    Jeżeli wyłączyłeś reset, bądź programowanie przez SPI, to odłóż je na półeczkę, lub zrób sobie HVProg.

    Ogólnie to może układ w którym ich używasz pali te procesory, za dużo prądu z nich chcesz zabrać, czy coś... No albo właśnie w fusach na grzebałeś tak jak wcześniej pisałem.

    DXFM napisał:
    Oto sposób, którym na 99% ożywisz procesory.
    Podaj na wejście XTAL1 przebieg prostokątny o częstotliwości ok. 1MHz z zewnętrznego generatora lub z działającego procka i użyj programatora STK200. Jeśli będzie komunikacja musisz zmienić fusy dotyczące taktowania (wewnętrzny RC czy Xtal). Potem odłączasz generator i sprawdzasz. Możesz spróbować z inną częstotliwością, jaką masz pod ręką, ale raczej nie mniejszą niż 500kHz. Ja zawsze używam 1MHz lub więcej.

    Mnie udało się 'przywrócić' programowanie ISP wszystkim prockom, które przy programowaniu nagle przestały odpowiadać (nie dotyczy upalonych fizycznie). Piszę w cudzysłowie, ponieważ nie raz wykorzystuję właśnie taktowanie zewnętrzne. Aby taki kontroler programować wymagany jest ten zewnętrzny sygnał taktujący.

    Takie przypadki zdarzają się w przypadku marnej jakości programatora ISP, głównie prowadzenia przewodów sygnałowych i ich długości.

    Nie te w których wyłączysz fusami reset lub możliwość programowania przez SPI.

    pozdrawiam hot-dog
  • Poziom 13  
    Sprawdź czy na pewno masz wszystko poprawnie na PCB. Softem raczej trudno zabić procka no chyba, że właśnie na PCB jest coś nie tak podłączone.
  • Poziom 20  
    [quote="hotdog"]
    DXFM napisał:
    Oto sposób, którym na 99% ożywisz procesory.
    (...)

    Masz rację, chociaż nikomu w moim otoczeniu akurat nie zdarzyło się przypadkowo przestawić tego bitu. Znacznie częściej przestawia się właśnie taktowanie. Czyli 99% należy zmienić na 90% ? Może mniej :)
  • Poziom 26  
    ja kiedyś zamieniłem hfuse z lfuse i mega8 w tqfp uwalona. W dip'ie by to nie bolało bo bym poprostu wymienił, a tak to się napocić musiałem.. i płytka tak ładnie też już nigdy wyglądać nie będzie.

    Nie czepiałem się tego że napisałeś te 99% tylko chciałem podkreślić gdzie leży ten 1%.

    Wniosek jeden. Jeżeli nie chcesz mieć problemów 3 razy sprawdź co chcesz we fusy wpisać.

    pozdrawiam
  • Poziom 20  
    hotdog napisał:
    Jeżeli nie chcesz mieć problemów 3 razy sprawdź co chcesz we fusy wpisać.

    I używaj sprawdzonego programatora, bo sporo jest przypadków ustawienia fusów tylko przy programowaniu pamięci programu. Jakieś zakłócenie, dzwonienie na liniach czy przesłuchy między nimi i coś niespodziewanego może się wpisać. O to mi raczej chodziło.
  • Poziom 13  
    Programatora używam zakupionego na allegro jego wykonanie wygląda bardzo profesjonalnie w systemie SMD. Więc chyba to nie wina programatora :( Dam mu jeszcze szanse. A tam te procki odłożyłem na razie na półkę jak zdobędę więcej doświadczenia to spróbuję je jeszcze raz odratować.