Boot loader i ATmega128
Masz problem? Zapytaj na forum elektroda.pl
From: "Sebcio" <thesebcio_at_nospam_tlen.NO-SPAM.pl>
Subject: Boot loader i ATmega128
Date: Sun, 13 Jul 2003 17:04:07 +0200
Witam,
podczas pisania boot loadera dla ATmega128 napotkałem na pewien problem
którego nie mogę znaleźć w dokumentacjach, mianowicie - mój boot loader
znajduje się pod adresem F000h i po inicjalizacji portów itd. ma za zadanie
obliczyć CRC obszaru pamięci programu od 0000h do EFFFh po czym porównać go
z CRC zapisanym w EPROM'ie. Ma to na celu stwierdzenie czy program jest
prawidłowy czy też jest uszkodzony i w zależności od tego albo przekazać mu
sterowanie albo przejść do trybu samoprogramowania pamięci FLASH.
Odczyt zawartości FLASH wykonywany jest instrukcją ELPM przez kod jak
poniżej:
unsigned int readromword(unsigned int addr)
{
#asm
ldd r31, y + 1
rol r31
ld r30, y
clc
rol r30
clr r26
clr r26
sts rampz, r26
elpm r26, z+
elpm r27, z
mov r30, r26
mov r31, r27
#endasm
}
Powyższa funkcja jest funkcją w C, para rejestrów R30:R31 to adres słowa
(nie bajtu!) w pamięci FLASH, wynik funkcji czyli odczytane spod podanego
adresu słowo również ląduje w R30:R31. Otóż problem polega na tym że
jakkolwiek funkcja ta bezbłędnie czyta kod boot loadera to próba odczytu
adresów od np. 0000h do 000Fh powoduje że funkcja zwraca FFFFh bez względu
na zawartość tych komórek.
Sprawdzałem wszelkie lockbity, nic nie wskazuje na to aby rozkaz ELPM
wywoływany z bootblocka nie miał mieć dostępu do obszaru aplikacji - co więc
może być przyczyną ?? Proszę, pomóżcie !
Pozdrawiam,
Sebcio
========
Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.gazeta.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: "Sebcio" <thesebcio_at_nospam_tlen.NO-SPAM.pl>
Subject: Re: Boot loader i ATmega128
Date: Sun, 13 Jul 2003 17:24:02 +0200
Użytkownik "Sebcio" <thesebcio_at_nospam_tlen.NO-SPAM.pl> napisał w wiadomości
news:bersdj$9pk$1_at_nospam_atlantis.news.tpi.pl...
Odczyt zawartości FLASH wykonywany jest instrukcją ELPM przez kod jak
poniżej:
nadmienię że właśnie zrobiłem mały test i zamiana ELPM na LPM bez
ingerencji w resztę kodu powoduje że niskie adresy czytane są bezbłędnie a
więc jest różnica w działaniu obu rozkazów. Niestety, ja muszę używać ELPM
jako że potrzebuję czytać całe 128KB pamięci programu a nie tylko 64KB jakie
jest w stanie adresować LPM :-(
Pozdrawiam,
Sebcio
========
Path: news-archive.icm.edu.pl!news.icm.edu.pl!news.webcorp.com.pl!not-for-mai
From: maurycysajdak_at_nospam_mail.zetosa.com.NOSPAM.pl (simon71)
Subject: Re: Boot loader i ATmega128
Date: Sun, 13 Jul 2003 20:47:48 +0000 (UTC)
Przyczyn szukałbym w ustawianiu bitu RAMPZ. LPM nie korzysta z tego
bitu, a ELPM korzysta.
--
Wyslano z forum elektronicznego: https://www.elektroda.pl/rtvforum/
========
Path: news-archive.icm.edu.pl!news.icm.edu.pl!news.astercity.net!not-for-mai
From: Adam Dybkowski <adybkows_at_nospam_amwaw.edu.pl>
Subject: Re: Boot loader i ATmega128
Date: Sun, 13 Jul 2003 23:12:35 +0200
Sebcio wrote:
Odczyt zawartości FLASH wykonywany jest instrukcją ELPM przez kod jak
poniżej:
[...]
clr r26
clr r26
sts rampz, r26
Po co 2x czyścisz R26? Do tego w RAMPZ na stałe zapisujesz 0 - czy o to
na pewno chodziło?
--
Adam Dybkowski
adybkows_at_nospam_amwaw.edu.pl
http://www.amwaw.edu.pl/~adybkows
========
Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!newsfeed.gazeta.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: "Sebcio Łastowski" <sebcio_at_nospam_sebcio.please.dont.spam.me.com>
Subject: Re: Boot loader i ATmega128
Date: Mon, 14 Jul 2003 13:46:10 +0200
Użytkownik "Adam Dybkowski" <adybkows_at_nospam_amwaw.edu.pl> napisał w wiadomości
news:3F11CB43.6090101_at_nospam_amwaw.edu.pl...
Odczyt zawartości FLASH wykonywany jest instrukcją ELPM przez kod
jak
poniżej:
clr r26
clr r26
sts rampz, r26
Po co 2x czyścisz R26? Do tego w RAMPZ na stałe zapisujesz 0 - czy o to
na pewno chodziło?
nie, skopiowałem kod z chwili gdy testowałem - winno być w oryginale clr
r26, rol r26 (bo poprzednie operacje umieszczały w Carry bit który wskazywał
na właściwą połówkę pamięci), sts rampz, r26. Natomiast wykryłem problem -
mianowicie zamiast sts rampz, r26 winno być out rampz, r26 i teoretycznie
działa. Teoretycznie gdyż w niektórych sytuacjach wywołanie tej procedury
powoduje dziwne zachowanie się printf() w CodeVisionAVR i podejrzewam że
jest to jakiś bug albo niekompatybilność... :-(
--
Pozdrawiam,
Sebcio
========
Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!not-for-mai
From: "Łukasz P." <lukbob[nospam]_at_nospam_poczta.onet.pl>
Subject: Re: Boot loader i ATmega128
Date: Mon, 14 Jul 2003 08:31:35 +0200
Witam!
Temat bootloadera dla ATmega128 byl wielokrotnie poruszany na forum
http://www.dragonsgate.net/mailman/listinfo.
Dobrze zauważyłeś, że aby odczytać część pamięci FLASH powyżej 64kB
należy używać instrukcji ELPM zamiast LPM.
Nie będę wnikał w szczegóły, ponieważ programowanie pamięci FLASH
jest bardzo dobrze opisane w dokumentacji dla procesora ATmega128.
Nie analizując Twojego kodu źródłowego przytaczam fragment kodu, który
prawidłowo funkcjonuje. Napisany jest w assemblerze, ale wystarczy
zdefiniować
nagłówki do niego w pliku h i będzie można używać je oczywiście w C.
Procedury w zasadzie się nie różnią z wyjątkiem instrukcji LPM i ELPM.
Jednak zwróć uwage, że odczytują słowo 16-bitowe, czyli dwa bajty
pamiecie flash, także przy odczycie całej pamięci adr trzeba inkrementowac
co 2 nie co 1.
Druga sprawa, to że należy ustawiać RAMPZ = 0 przed wywołaniem read....._lo,
oraz
RAMPZ = 1 przed read..._hi.
;unsigned int read_program_memory_lo (unsigned int adr ,unsigned char cmd);
_read_program_memory_lo::
MOV R31,R17 ;R31=ZH R30=ZL
MOV R30,R16
SBRC R18,0
STS SPMCR,R18
LPM ;read LSB
MOV R16,R0
INC R30
LPM
MOV R17,R0
RET
;unsigned int read_program_memory_hi (unsigned int adr ,unsigned char cmd);
_read_program_memory_hi::
MOV R31,R17 ;R31=ZH R30=ZL
MOV R30,R16
SBRC R18,0
STS SPMCR,R18
ELPM
MOV R16,R0
INC R30
ELPM
MOV R17,R0
RET
Pozdrawiam Łukasz z Bydgoszczy.
========
Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.gazeta.pl!news.gazeta.pl!not-for-mai