eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaznowu problemy z atmegą... › znowu problemy z atmegą...
  • Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.
    atman.pl!.POSTED!not-for-mail
    From: sundayman <s...@p...onet.pl>
    Newsgroups: pl.misc.elektronika
    Subject: znowu problemy z atmegą...
    Date: Tue, 14 Oct 2014 01:05:26 +0200
    Organization: ATMAN - ATM S.A.
    Lines: 43
    Message-ID: <m1hlvc$t0o$1@node2.news.atman.pl>
    NNTP-Posting-Host: 91.205.72.35
    Mime-Version: 1.0
    Content-Type: text/plain; charset=ISO-8859-2; format=flowed
    Content-Transfer-Encoding: 8bit
    X-Trace: node2.news.atman.pl 1413241644 29720 91.205.72.35 (13 Oct 2014 23:07:24 GMT)
    X-Complaints-To: u...@a...pl
    NNTP-Posting-Date: Mon, 13 Oct 2014 23:07:24 +0000 (UTC)
    User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101
    Thunderbird/24.6.0
    Xref: news-archive.icm.edu.pl pl.misc.elektronika:672652
    [ ukryj nagłówki ]

    Zapodane na elce, powielam tutaj, licząc na życzliwąpomoc kolegów;

    Chodzi o atmegę128.
    Fusy 3F D4 FF (lata na kwarcu 14Mhz).
    Do tego jest bootloader 1kb na wejściu (przerobiony MCS bootloader do
    bascoma), no i sam program "główny" w bascomie.

    "normalna" procedura wygrywania softu jest taka:

    Za pomocą AVRDRAGON, spod Atmel Studio ustawiam sobie fusy.
    Następnie wgrywam plik HEX bootloadera. Wgrywa się OK, weryfikacja OK (z
    ISP clock 2Mhz) - bootloader działa poprawnie.

    Potem, spod bascoma , już z użyciem bootloadera, przez RS232 wgrywam
    "główny" program. No i gitara - wszystko hula.

    No i dalej zaczynają się cuda;
    Chciałbym zrobić sobie "zrzut" całego flasha, żeby go potem wgrywać "w
    całości".
    Zatem znowu z użyciem AVRDRAGONA odczytuję sobie zawartość flasha. Dla
    pewności z wolniejszym ISP clock - np. 250 kHz.

    Odczytuje się ok, zapisuje mi pliczek.

    Jednak próba weryfikacji już nie jest OK :
    "Verifying Flash...Failed! address=0x0000 expected=0xff actual=0x0c"

    Kiedy to samo robię z pamięcią EEPROM - problemu nie ma. Dane odczytane
    się poprawnie weryfikują. Nawet przy ISP clock 2 Mhz.
    Czyli nie jest to problem z programatorem raczej.

    Aha, oczywiście lockbity są powyłączane...

    Żeby było śmieszniej, to pod adresem 0x0000 POWINNO być 0C.
    Kiedy zaglądam do pilku hex - tak właśnie jest zarówno w pliku wynikowym
    z bascoma, jak i w pliku odczytanym z flasha. Oczywiście plik z "samym
    programem głównym" jest krótszy niż plik odczytany z MCU już z
    bootloaderem.

    Ale akurat początki są oczywiście takie same - i w obu plikach jest pod
    adresem 0000 wartość 0C.

    Zatem skąd on bierze to "expected=0xff" podczas weryfikacji ??

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: