logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

[ATMEGA64][AVRGCC] trudne początki

mgradzki 26 Sie 2008 21:26 3720 5
  • #1 5477820
    mgradzki
    Poziom 16  
    Witam, do dziś używałem ATMEGA32, teraz walczę z ATMEGA64. Na początek coś prostego miganie diodami (PORTA) - procedura opóźniająca zaczerpnięta z jakiegoś starego programu na ATMEGA32.
    
    #define F_CPU 16000000UL
    #include <util/delay.h>
    #include <avr/io.h>
    
    void waitms(unsigned int ms) 
    { 
    unsigned int i; 
    for (i=0;i<ms;i++) 
      { 
       _delay_ms(1);
      } 
    }
     
    int main(void)
    {
    DDRA=0xff;
    while(1) 
      {
    waitms(5);
    PORTA^=0xff;
      }
    }
    
    


    i nie działa, na PORTA nic się nie dzieje. Jeśli zamiast


    wstawię
    
       _delay_ms(1);
       _delay_ms(1);
       _delay_ms(1);
       _delay_ms(1);
       _delay_ms(1);
    



    to diody zaczynają migać (miganie jest widoczne, więc nie migają z okresem 10ms). Jeśli procedurę opóźniającą wywołuję więcej razy to wszystko przestaje działać.

    Myślałem, że przesiadka na "większy" procesor będzie łatwa, ale widzę schody. Zastanawiam się, czy "makefile", którego używałem z ATMEGA32 nie powinien być zmodernizowany (pomijając zmianę typu procesora). Używam takiego:
    
    PRG            = pro
    OBJ            = pro.o
    MCU_TARGET     = atmega64
    OPTIMIZE       = -O2
    
    DEFS           =
    LIBS           =
    
    # You should not have to change anything below here.
    
    CC             = avr-gcc
    
    # Override is only needed by avr-lib build system.
    
    override CFLAGS        = -g -Wall $(OPTIMIZE) -mmcu=$(MCU_TARGET) $(DEFS)
    override LDFLAGS       = -Wl,-Map,$(PRG).map
    
    OBJCOPY        = avr-objcopy
    OBJDUMP        = avr-objdump
    
    all: $(PRG).elf lst text eeprom
    
    $(PRG).elf: $(OBJ)
    	$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS)
    
    clean:
    	rm -rf *.o $(PRG).elf *.eps *.png *.pdf *.bak 
    	rm -rf *.lst *.map $(EXTRA_CLEAN_FILES)
    
    lst:  $(PRG).lst
    
    %.lst: %.elf
    	$(OBJDUMP) -h -S $< > $@
    
    # Rules for building the .text rom images
    
    text: hex bin srec
    
    hex:  $(PRG).hex
    bin:  $(PRG).bin
    srec: $(PRG).srec
    
    %.hex: %.elf
    	$(OBJCOPY) -j .text -j .data -O ihex $< $@
    
    %.srec: %.elf
    	$(OBJCOPY) -j .text -j .data -O srec $< $@
    
    %.bin: %.elf
    	$(OBJCOPY) -j .text -j .data -O binary $< $@
    
    # Rules for building the .eeprom rom images
    
    eeprom: ehex ebin esrec
    
    ehex:  $(PRG)_eeprom.hex
    ebin:  $(PRG)_eeprom.bin
    esrec: $(PRG)_eeprom.srec
    
    %_eeprom.hex: %.elf
    	$(OBJCOPY) -j .eeprom --change-section-lma .eeprom=0 -O ihex $< $@
    
    %_eeprom.srec: %.elf
    	$(OBJCOPY) -j .eeprom --change-section-lma .eeprom=0 -O srec $< $@
    
    %_eeprom.bin: %.elf
    	$(OBJCOPY) -j .eeprom --change-section-lma .eeprom=0 -O binary $< $@
    
    # Every thing below here is used by avr-libc's build system and can be ignored
    # by the casual user.
    
    FIG2DEV                 = fig2dev
    EXTRA_CLEAN_FILES       = *.hex *.bin *.srec
    
    dox: eps png pdf
    
    eps: $(PRG).eps
    png: $(PRG).png
    pdf: $(PRG).pdf
    
    %.eps: %.fig
    	$(FIG2DEV) -L eps $< $@
    
    %.pdf: %.fig
    	$(FIG2DEV) -L pdf $< $@
    
    %.png: %.fig
    	$(FIG2DEV) -L png $< $@
    
    

    Mam kwarc 16M, fusebity ustawione jak na rysunku.
    [ATMEGA64][AVRGCC] trudne początki

    Jeśli ktoś wie, co robię nie tak, to proszę o jakieś info, bo siedzę nad tym już kilka godzin.
    Pozdrawiam.


    ----------------------------------------------------------EDIT---------------------------------------------------------------------------------------------

    Zmieniłem soft na coś takiego:
    
    int main(void)
    {
    USARTUSB_Init();
    sei();
    USARTUSB_Transmit(48);
    USARTUSB_Transmit(49);
    USARTUSB_Transmit(50);
    USARTUSB_Transmit(51);
    USARTUSB_Transmit(52);
    USARTUSB_Transmit(53); 
    USARTUSB_Transmit(54);
    USARTUSB_Transmit(55);
    USARTUSB_Transmit(56);
    USARTUSB_Transmit(57);
    
    while(1)
      {
      }
    }
    

    i okazuje się, że śle na terminal sekwencję "012345" i tak w kółko. Wniosek jest taki, że się resetuje - z parametrów transmisji można wyliczyć po jakim czasie jeśli taka informacja coś wniesie.

    Teraz konkurs, co może być źródłem resetu?
    Watchdog nie jest włączony (nie dotykałem jego rejestrów)
    Brown-out reset też to raczej nie
    Pin RESET jest podciągnięty do VCC przez Rez. 15k

    Zostaje jeszcze JTAG, ale już dziś jeden procesor przestał gadać ze mną po SPI jak przestawiłem fusebit JTAGEN na 1 i wolałbym nie eksperymentować z ostatnim działającym prockiem :).
    W ATMEGA32 i 16 nie wyłączałem JTAGA jeśli nie potrzebowałem jego portu i nie było problemu.

    Wyczyściłem procesor do ustawień fabrycznych, więc tryb zgodności z ATMEGA103 nie jest już włączony.
    Kiedyś miałem takie szopki, jak wgrałem do ATMEGA16 kod skompilowany na ATMEGA32
  • #2 5478045
    rrata
    Poziom 19  
    Twój Makefile jest chyba z jakiejś starszej wersji. Ściągnij nowszą wersję WinAVR i wtedy próbuj. Oczywiście MakeFile tworzysz przy pomocy MFile. Dodatkowo _delay_ms(ms); tworzy już opóźnienie w milisekundach (tak mniej więcej) i nie trzeba tego wkładać w pętle.
  • #3 5478164
    BoskiDialer
    Poziom 34  
    rrata: Istnieją co najmniej dwa sensowne powody, aby _delay_ms wsadzić w pętlę:
    1/ "The maximal possible delay is 262.14 ms / F_CPU in MHz." Co oznacza, że gdyby opóźnienia były większe niż (tutaj) 16ms, to pojawił by się problem z zastosowaniem tej funkcji
    2/ Jeśli jako argument podać zmienną, to do kodu zostanie wkompilowana cała obsługa liczb zmiennoprzecinkowych, co jest wymagane do liczenia liczby iteracji opóźnienia względem zegara.
    Oczekiwanie 1ms wrzucone do pętli w bardzo prosty i sprytny sposób omija oba te ograniczenia.

    Sam kod po skompilowaniu (moim makefilem) wydaje się być poprawny, problem pojawia się w momencie wywołania funkcji lub powrotu z niej, mogę więc wnioskować, że są problemy ze stosem, ale jako, że ten musi być poprawnie inicjalizowany, problemem może być załączony tryb kompatybilności z atmega103 (wtedy wgrywając soft na atmega64 nie będzie dostępnych około 100 bajtów z początku stosu). To jest jedyne co mi się uwidoczniło.

    Dodano po 13 [minuty]:

    Co tu dużo mówić - przecież dołączyłeś zdjęcie z ustawieniami fusebitów i wyraźnie widać, że bit M103C jest zaprogramowany. Wyłącz go.
  • #4 5478350
    mgradzki
    Poziom 16  
    BoskiDialer napisał:
    rrata:

    Co tu dużo mówić - przecież dołączyłeś zdjęcie z ustawieniami fusebitów i wyraźnie widać, że bit M103C jest zaprogramowany. Wyłącz go.


    Zauważyłem to i wyłączyłem chwilę temu, ale zachowanie bez zmian.
    Po wyłączeniu CKSEL0 wskoczył mi na 0 i nie mogę go ustawić na 1.

    Zastanawiam się, czy nie mam jakiegoś problemu z procesorem - jutro kupię kilka nowych podlutuję i będę testował. Przy uruchamianiu RESET przez chwilę był zwarty do VCC (bezpośrednio) i procek trochę się podgrzał.

    W stosunku do ATMEGA32, czy 16 zachowuje sę dziwnie.
    Nie wiem jak powinien działać pin PEN. Jak jest dołączony do masy po programowaniu procesor nic nie robi, do momentu odłączenia go od masy i odłączenia (i podłączenia) zasilania.
    Jak jest dołączony do masy to przed każdą operacją: odczytem lub zapisem fusebitów, programowaniem, itp. trzeba odłączyć zasilanie i podłączyć je - tak jakby przed każdą operacją trzeba było wejść w tryb programowania. Jeśli się tego nie zrobi to krzyczy błędy, albo pokazuje, że wszystkie Fusebity są na 0.

    Teraz jeszcze pomyślałem, że może pin PEN nie jest wewnętrznie podciągany do góry i nie powinienem go zostawiać wiszącego w powietrzu na czas pracy układu.
  • #5 5478394
    BoskiDialer
    Poziom 34  
    U mnie w jednej z aplikacji podobny procek ma pin PEN podłączony na stałe do VCC. Wszystko działa normalnie - układ daje się programować przez spi.
  • #6 5478417
    mgradzki
    Poziom 16  
    BoskiDialer napisał:
    U mnie w jednej z aplikacji podobny procek ma pin PEN podłączony na stałe do VCC. Wszystko działa normalnie - układ daje się programować przez spi.


    Jak czytałem datasheet to pomyślałem sobie, że podłączę go na stałe do GND i będzie kukać. Napisane jest, że PEN w czasie normalnej pracy nie wpływa na działanie układu, a ja tu mam od kilku godzin niezłą jazdę z programowaniem. Na szczęście w czasie projektowania płytki uruchomieniowej dałem w zasilaniu zworkę do odłączania zasilania.

    Posprawdzam jeszcze pytkę, może mam jakiś problem sprzętowy i się krzaczy.
REKLAMA