Z bootloaderem przygód ciąg dalszy.
Na ATMega8 wszystko pięknie działa, chcę teraz zrobić podobną rzecz na
ATMega128 i znowu dzieją się jakieś jaja. Bootloader jest duży, ponad
6kB, więc rezerwuję na niego największy możliwy 8kB obszar począwszy od
$00F000. Dla linkera podaję adres początkowy segmentu .text jako
0x1e000, ale w pliku .hex mam :10E00000 a na dodatek pierwsza linia
tego pliku wygląda tak :020000021000EC, czyli że 2 bajty zapisywane są
pod adresem $000000.
Po wgraniu tego pliku przy użyciu AVR Studio, nic się nie dzieje. Fuse
bity ustawione prawidłowo. Jeśli adres startowy ustawię na $00000 to
program działa (choć oczywiście niczego nie programuje, ale wiadomo że
to nie jest jakiś zwis czy błąd w kodzie).
No i teraz zupełnie nie wiem gdzie szukać błędu - w kompilatorze,
linkerze, programatorze czy jeszcze gdzieś.

Dariusz Żołna

do góry

Dariusz Zolna wrote:
> No i teraz zupełnie nie wiem gdzie szukać błędu - w kompilatorze,
> linkerze, programatorze czy jeszcze gdzieś.

Sprawdź:

avr-objdump -h -S prg.elf >prg.lst

Powinno się sporo wyjaśnić.

do góry

Sebastian Bialy pisze:
> Sprawdź:
>
> avr-objdump -h -S prg.elf >prg.lst
>
> Powinno się sporo wyjaśnić.

Program jest ok, zaczyna się od $1e000 i kończy na $1f762, więc jest we
właściwym miejscu. Wektory przerwań (oprócz wykorzystywanego przeze mnie
TWI pokazują na instrukcję skoku pod $1e000, a pod $1e000 jest skok na
początek programu).
Mam wrażenie, że problem leży jednak w pliku .hex, w którym brakuje
jednej cyfry adresu (nie ma $1e000, jest $e000), no chyba że dla układów
z flashem większym niż 64kB, pliki .hex są jakoś specjalnie obsługiwane.

Dariusz Żołna

do góry

Dariusz Zolna wrote:
> Mam wrażenie, że problem leży jednak w pliku .hex, w którym brakuje
> jednej cyfry adresu (nie ma $1e000, jest $e000)

A probowałeś wygenerować plik .bin zamiast hex i załadować go?

I po drugie - czy odczyt pamięci z mikrokontrolera daje ten sam plik co
zapis?

>, no chyba że dla układów
> z flashem większym niż 64kB, pliki .hex są jakoś specjalnie obsługiwane.

Nie wiem jak dla narzędzi avr, ale IntelHEX może być 32 bitowy i chyba
taki powinien własnie tu byc.

do góry

On 24 Sty, 23:45, Dariusz Zolna <a...@u...com> wrote:
> Z bootloaderem przygód ciąg dalszy.
> Na ATMega8 wszystko pięknie działa, chcę teraz zrobić podobną rzecz na
> ATMega128 i znowu dzieją się jakieś jaja. Bootloader jest duży, ponad
> 6kB, więc rezerwuję na niego największy możliwy 8kB obszar począwszy od
> $00F000. Dla linkera podaję adres początkowy segmentu .text jako
> 0x1e000,  ale w pliku .hex mam :10E00000 a na dodatek pierwsza linia
> tego pliku wygląda tak :020000021000EC, czyli że 2 bajty zapisywane są
> pod adresem $000000.

Wszystko jest OK. Wpis :020000021000EC stanowi rozszerzenie
przestrzeni
adresowej bo adresowanie jest 16 bitowe. Proponuję poczytać jak
wygląda
format IntelHEX.
pozdrawiam
Robert Zemła

do góry

Dariusz Zolna pisze:
> Z bootloaderem przygód ciąg dalszy.
> Na ATMega8 wszystko pięknie działa, chcę teraz zrobić podobną rzecz na
> ATMega128 i znowu dzieją się jakieś jaja. Bootloader jest duży, ponad
> 6kB, więc rezerwuję na niego największy możliwy 8kB obszar począwszy od
> $00F000. Dla linkera podaję adres początkowy segmentu .text jako
> 0x1e000, ale w pliku .hex mam :10E00000 a na dodatek pierwsza linia
> tego pliku wygląda tak :020000021000EC, czyli że 2 bajty zapisywane są
> pod adresem $000000.

Tak jak poprzednio - nie wiem czy linker nie przyjmuje adresu jako
slowa, a nie bajty.

> Po wgraniu tego pliku przy użyciu AVR Studio, nic się nie dzieje. Fuse
> bity ustawione prawidłowo. Jeśli adres startowy ustawię na $00000 to
> program działa (choć oczywiście niczego nie programuje, ale wiadomo że
> to nie jest jakiś zwis czy błąd w kodzie).
> No i teraz zupełnie nie wiem gdzie szukać błędu - w kompilatorze,
> linkerze, programatorze czy jeszcze gdzieś.

Toolchain raczej bym wykluczyl, tyle osob to testowalo, ze szansa, ze
nie wyszlaby do tej pory tak gruba rzecz jest zadna.
Zobacz jak wygladaja wygenerowane pliki .map i .lss. Tam bedziesz mial
dokladnie pokazane co jest pod jakim adresem umieszczone i jak wyglada
wygenerowany kod assemblerowy.
Jesli nie chcesz nam pokazac listingow programu to napisz jakis krotki
programik, ktory produkuje ten sam blad. Wtedy bedzie mozna powiedziec
cos wiecej.

do góry

> na dodatek pierwsza linia
> tego pliku wygląda tak :020000021000EC, czyli że 2 bajty zapisywane są
> pod adresem $000000.

Nie
To jest extended segment address record.

Paweł

do góry

T.M.F. pisze:
> Tak jak poprzednio - nie wiem czy linker nie przyjmuje adresu jako
> slowa, a nie bajty.

Jako bajty. Ale ten trop też sprawdzałem, program wtedy się odpali,a le
nie jako bootloader i co oczywiste nie zapisuje pamięci.



> Toolchain raczej bym wykluczyl, tyle osob to testowalo, ze szansa, ze
> nie wyszlaby do tej pory tak gruba rzecz jest zadna.
> Zobacz jak wygladaja wygenerowane pliki .map i .lss. Tam bedziesz mial
> dokladnie pokazane co jest pod jakim adresem umieszczone i jak wyglada
> wygenerowany kod assemblerowy.

Oglądałem i wszystko jest ok.

> Jesli nie chcesz nam pokazac listingow programu to napisz jakis krotki
> programik, ktory produkuje ten sam blad. Wtedy bedzie mozna powiedziec
> cos wiecej.

Z pokazaniem kodu jest tylko jeden problem - jest za długi żeby tu
wklejać. Ale żeby pokazać, że jest ok, wkleję co istotniejsze fragmenty.

bootloader.elf: file format elf32-avr

Sections:
Idx Name Size VMA LMA File off Algn
0 .data 00000004 00800100 0001f764 000017f8 2**0
CONTENTS, ALLOC, LOAD, DATA
1 .text 00001764 0001e000 0001e000 00000094 2**1
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .bss 00000452 00800104 00800104 000017fc 2**0

[...]

0001e000 <__vectors>:
1e000: 0c 94 a4 f1 jmp 0x1e348 ; 0x1e348 <__ctors_end>
1e004: 0c 94 c4 f1 jmp 0x1e388 ; 0x1e388 <__bad_interrupt>
1e008: 0c 94 c4 f1 jmp 0x1e388 ; 0x1e388 <__bad_interrupt>

[...]

0001e348 <__ctors_end>:
1e348: 11 24 eor r1, r1
1e34a: 1f be out 0x3f, r1 ; 63
[...]
1e380: 0e 94 14 f6 call 0x1ec28 ; 0x1ec28 <main>
1e384: 0c 94 b0 fb jmp 0x1f760 ; 0x1f760 <_exit>

0001e388 <__bad_interrupt>:
1e388: 0c 94 00 f0 jmp 0x1e000 ; 0x1e000 <__vectors>

[...]

nt main( void )
{
1ec28: 1f 93 push r17
// u16 i;

cli();
1ec2a: f8 94 cli
TIMSK = 0; // disable timer interrupts
1ec2c: 17 be out 0x37, r1 ; 55

/* Enable change of interrupt vectors */
MCUCR = (1<<IVCE);
1ec2e: 11 e0 ldi r17, 0x01 ; 1
1ec30: 15 bf out 0x35, r17 ; 53
/* Move interrupts to boot flash section */
MCUCR = (1<<IVSEL);
1ec32: 82 e0 ldi r24, 0x02 ; 2
1ec34: 85 bf out 0x35, r24 ; 5

[...]


Pliki .hex (zapisany i odczytany) wyglądają ok.
A może jest coś czym musi się różnić bootloader na ATMega128 od tego dla
ATMega8?

Dariusz Żołna

do góry

Dnia Sat, 24 Jan 2009 23:45:50 +0100, Dariusz Zolna napisał(a):
> Fuse bity ustawione prawidłowo.

Nieśmiało spytam, bo nie śledziłem - M103C = 1 ?

Pozdrawiam
--
Marcin Stanisz

"A lie will go round the world before the truth has got its boots on"
Terry Pratchett, "Truth"

do góry

Marcin Stanisz pisze:
> Nieśmiało spytam, bo nie śledziłem - M103C = 1 ?

Nie. Ale właśnie się wyjaśniło.
Kompilator nie ostrzega, że pgm_read_byte() działa tylko z krótkimi
adresami, bootloader siedzi powyżej 64k, a ja wszystkie dane typu
teksty/grafika trzymam we flash, no i jak tylko program dochodził do
miejsca, w którym powinien wyświetlić testowy napis, procek się resetował.
No i jak zwykle nie tam gdzie szukałem :)

Dariusz Żołna

do góry