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

[AVR][GCC][ECLIPSE] - objawy konca zywotnosci FLASH

adampyndzel 28 Lip 2012 23:33 2030 16
  • #1 28 Lip 2012 23:33
    adampyndzel
    Poziom 16  

    Witam.

    zastanawia mnie zjawisko występujące podczas programowania mikroklocka jkim jest atmega32. Otóż powiedzmy program ma cos tylko wyswietlic na lcd.
    Po zaprogramowaniu wyświetla jakieś pytajniki i wszystko jest porozrzucane, kolejny raz daję na zapis i wyświetla np jakieś inne znaki albo całą pierwszą linie jakieś kwadraty, dopiero przy którymś ponownym zapisie udaje się uzyskać to co powinno być. Zastawia mnie to dlaczego tak się dzieje skoro zawsze powinien być efekt takki sam jeśli zawsze jest ten sam hex. Pomyślałem że może to być już zajechana ta atmega bo programowań to ona miała już sporo, ale nie jestem pewien. Co może być przyczyną takiego zachowania???

    0 16
  • Arrow Multisolution Day
  • #2 29 Lip 2012 00:02
    kaken
    Poziom 15  

    Wg mnie masz problem z programem, częścią sprzętową układu (coś np. nie styka, zepsuty LCD) lub np. za długi kabel programatora (po programowaniu masz weryfikację poprawności?).

    0
  • #3 29 Lip 2012 00:12
    adampyndzel
    Poziom 16  

    weryfikacji nie mam ale inne programy czy lcd czy jakieś inne ładuje dobrze i wszystkie działają. W ogóle to w programie który próbuje załadować wystarczy zmienić linijkę kodu i wszystko działa ok natomiast jeśli jakąs dopiszę to dzieją się cuda.

    0
  • #4 29 Lip 2012 00:15
    kaken
    Poziom 15  

    Weryfikacja to na prawdę przydatna rzecz. Czy dopisana linijka kodu nie powoduje tego, że rozmiar programu przekracza wielkość pamięci dla m32?

    0
  • #5 29 Lip 2012 11:01
    adampyndzel
    Poziom 16  

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Po wpisaniu takiego kodu dzieją się jakieś czarodziejstwa i działa dopiero przy trzecim programowaniu. Zastanawia mnie dlaczego tak się dzieje ze nie startuje od razu po pierwszym załadowania hex. A co do poprawności połączenia to jest na pewno dobre.

    0
  • Arrow Multisolution Day
  • #6 29 Lip 2012 11:05
    kaken
    Poziom 15  

    A spróbuj dać w tej głównej pętli jakieś opóźnienie np. 100ms.

    0
  • #7 29 Lip 2012 11:11
    adampyndzel
    Poziom 16  

    dodałem ale to nic nie zmienia, poza tym powiem raz jeszcze że program działa poprawnie jednak dopiero za którymś załadowaniem hex-a. Wykluczyłem błędne podłączenie ponieważ inne programy się kompilują od razu a tylko ten jest jakiś uparty.

    0
  • #8 29 Lip 2012 12:03
    gaskoin
    Poziom 38  

    adampyndzel napisał:
    Wykluczyłem błędne podłączenie ponieważ inne programy się kompilują od razu a tylko ten jest jakiś uparty.


    Skoro ten się nie kompiluje tzn, że błąd jest w programie. Nie pokazałeś całego więc ciężko wskazać błąd. Koniec żywotności to to raczej nie jest bo ta jest dość spora (10k zapisów i jest to wartość orientacyjna, bo układ pewnie wytrzyma i z 20k) i raczej uważałbym ze stwierdzeniami "błąd kompilatora", "błąd krzemu" i "kończąca się żywotność".

    0
  • #9 29 Lip 2012 12:08
    adampyndzel
    Poziom 16  

    w zasadzie to jest cały program, ale żeby nie było wątpliwości wrzucę cały

    Kod: c
    Zaloguj się, aby zobaczyć kod


    kompilator nie pokazuje żadnych błędów ani ostrzeżeń.

    0
  • #10 29 Lip 2012 12:19
    gaskoin
    Poziom 38  

    Włączyłeś optymalizację ? Jeśli nie, to włącz.

    Spróbuj przed LCD_Init dać jakiś delay .

    0
  • #11 29 Lip 2012 14:18
    LordBlick
    VIP Zasłużony dla elektroda

    A z jakiej biblioteki do LCD korzystasz, bo nie dostrzegłem żadnych wskazówek w tym temacie... ?
    Poza tym 100 ms to jest zdecydowanie za krótko, aby coś dostrzec. Moja propozycja, jak już tak spopularyzowana jest metoda aby urlopować w blokadzie procesor :

    Kod: C
    Zaloguj się, aby zobaczyć kod
    P.S. Wszyscy po cichu zakładamy, że zadeklarowana wartość zegara w opcjach projektu zgadza się z rzeczywistą, na linii zasilania i reset nie ma zakłóceń itd. itp...

    0
  • #12 29 Lip 2012 16:10
    Elektronik9
    Poziom 30  

    A sprawdź jeszcze czy na porcie na którym podłączasz LCD nie ma działających innych układów - np. RS232 które zakłócają ten port lub niektóre jego piny. Biblioteka do LCD wydaje się znajoma. Działasz na płytce ATB Atnela? Jeżeli tak to tam na porcie D jak podłączysz LCD to warto wyjąć zworkę od odbiornika podczerwieni - miałem podobny problem i pomogło.

    0
  • #13 29 Lip 2012 18:46
    adampyndzel
    Poziom 16  

    płytka to EvB no mogę zmienić port pod który jest podłączony lcd ale to jakim cudem wcześniej działało. Biblioteki lcd z innymi programami działają. Np przykład inny w którym wszystko jest ok

    Kod: c
    Zaloguj się, aby zobaczyć kod


    zmieniłem port do którego podłączyłem lcd ale dalej to samo, program działa dobrze ale jako jedyny musi być programowany ok 3 razy. Teraz gdy coś sprawdzam to nie wiem czy to dobrze działa czy może mój błąd takie nieporozumienia.

    PS: C o przy kompilacji w eclipse daje taki komunikat bo sam nie wiem skąd to wynika.
    Kod: c
    Zaloguj się, aby zobaczyć kod

    0
  • #14 29 Lip 2012 22:33
    LordBlick
    VIP Zasłużony dla elektroda

    adampyndzel napisał:
    przy kompilacji w eclipse daje taki komunikat bo sam nie wiem skąd to wynika.
    Kod: c
    Zaloguj się, aby zobaczyć kod
    Trzeba starą kompilację wyczyścić:
    Kod: bash
    Zaloguj się, aby zobaczyć kod

    0
  • #15 30 Lip 2012 12:12
    voytaschec
    Poziom 24  

    Miałem podobny problem jak miałem wyłączoną weryfikację przy programowaniu i używałem hub'a USB do programatora (i to jakiegoś chińskiego). Często było dobrze, ale czasem po zaprogramowaniu program zachowywał się zupełnie nieprzewidywalnie.
    Od tego czasu programator mam zawsze wpięty bezpośrednio do portu i włączoną weryfikację.
    Dziwne jest to, że akurat dzieje się tak tylko na konkretnej kompilacji.

    0
  • #16 31 Lip 2012 02:59
    adampyndzel
    Poziom 16  

    OMG nie mam sił już do tego. Wcześniej programowałem przez bootloader-a ale teraz użyłem programatora stk500 v2 i AVRDude i jest dalej to samo, za którymś dopiero razem programuje się normalnie czyli tak jak powinien działać. Programy testuję dosyć często tak więc uczę się na nich i w zasadzie to teraz nie wiem czy to mikroklocek źle zaprogramowany czy może ja coś poknociłem w programie czy co. Logicznie myśląc jak zawsze laduję ten sam hex to zawsze powinno być to samo, a jednak tak nie jest, zawsze jakieś inne krzaczki na LCD ale w rezultacie oczekiwany efekt udaje się uzyskać.

    0
  • #17 31 Lip 2012 07:08
    bulek01
    Poziom 15  

    Czy kondensator 100nF jest przylutowany blisko nóżek zasilania mikrokontrolera? Jego brak powoduje podobne cuda. Po drugie taktowanie wnewnętrznym rezonatorem czy kwarcem? Jeśli wewnętrznym to daj kwarc.

    0