-
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 ??
Następne wpisy z tego wątku
- 14.10.14 10:43 Robert Zemła
Najnowsze wątki z tej grupy
- Disk on Module, czym to odczytać?
- Pasta ochronna? Lutownicza?
- zagadka pneumatyczna
- Klip testowy, jak sie to używa
- Jak sie smazy elektronike z odleglosci kilkuset metrów?
- William Shockley, co-inventor of the transistor
- Gazowy kocioł CO regulacja cyklingu i regulacja pogodowa
- Zamek elektroniczny
- szablon do pasty DIY
- Głośnik potrzebny
- Silikonowy przewód ekranowany
- Wtyk bananowy ekranowany
- Co może być gorsze od pożaru elektryka?
- daltonizm
- Mały Linux
Najnowsze wątki
- 2025-11-17 NOWY: 2025-11-16 IBM i Holocaust - komentarz.pdf
- 2025-11-16 PESEL i problemy
- 2025-11-16 Jak przywrócić motyw?
- 2025-11-16 policja ochrania
- 2025-11-16 Disk on Module, czym to odczytać?
- 2025-11-16 Disk on Module, czym to odczytać?
- 2025-11-15 zaściankowe bydło
- 2025-11-15 Pasta ochronna? Lutownicza?
- 2025-11-14 "Partia rządzi, partia radzi. Partia nigdy cię nie zdradzi..."
- 2025-11-14 Czyja PRAWNA wina: Ukraina zestrzeliła ruski pocisk Iskander na ambasadę Azerbejdżanu
- 2025-11-14 Warszawa => Junior Rekruter <=
- 2025-11-14 Myślenice => Specjalista ds. kontrolingu <=
- 2025-11-14 Warszawa => Fullstack PHP Developer <=
- 2025-11-14 Warszawa => Mid/Senior IT Recruiter <=
- 2025-11-14 Zakrzewo => SAP HCM Consultant <=




Elektromobilność dojrzewa. Auta elektryczne kupujemy z rozsądku, nie dla idei