Rzeźbię teraz bootloader na Atmega8, który ściąga firmware przez I2C,
niestety dzieją się dziwne rzeczy.
Kod bootloadera uruchamia się, kontrolna dioda miga w określonej
sekwencji, czyli jest ok. W momencie kiedy wyślę pierwszy bajt po I2C,
układ się resetuje.
Podejrzewałem 1 z 3 możliwości:

1. Kod bootloadera jest za duży i nie mieści się w obszarze 1024 słów
(ale to wyeliminowałem przez porównanie zawartości flasha z tym co do
niego ładuję)

2. Jest niepoprawnie ustawiony wektor przerwania TWI i w momencie
otrzymania danej skacze gdzieś w maliny.

Na początku programu przepisuję tablicę wektorów przerwań:
GICR = (1<<IVCE);
GICR = (1<<IVSEL);

W pliku . map mam taki wpis:
0x00000d4e __vector_17

A w .lst taki:
302 .global __vector_17
304 __vector_17:
305 .LFB15:
306 .LM55:
307 /* prologue: frame size=0 */
308 00e2 1F92 push __zero_reg__

Więc wygląda, że wszystko jest na miejscu.

3. Ta opcja wygląda mi najbardziej podejrzanie: być może mam źle
ustawiony wskaźnik stosu i program resetuje się przy próbie powrotu z
przerwania.

HELP!

Dariusz Żołna

do góry

Dariusz Zolna pisze:
> Rzeźbię teraz bootloader na Atmega8, który ściąga firmware przez I2C,
> niestety dzieją się dziwne rzeczy.
> Kod bootloadera uruchamia się, kontrolna dioda miga w określonej
> sekwencji, czyli jest ok. W momencie kiedy wyślę pierwszy bajt po I2C,
> układ się resetuje.

Odpal to w AVR Studio i podejrzyj co sie dzieje.
Sprawdz boot lock bits, bootrst i IVSEL, bo nie wiadomo gdzie masz
wektor dla resetu, w SPMCR czy nie masz odblokowanych przerwan SPM,
ktorych nie obslugujesz.

do góry

T.M.F. pisze:
> Odpal to w AVR Studio i podejrzyj co sie dzieje.
> Sprawdz boot lock bits, bootrst i IVSEL, bo nie wiadomo gdzie masz
> wektor dla resetu, w SPMCR czy nie masz odblokowanych przerwan SPM,
> ktorych nie obslugujesz.

Dzięki. Jednak było to coś zupełnie innego niż przypuszczałem.
W dokumentacji Atmel podaje adress bootloadera w _słowach_ (zupełnie nie
wiem w jakim celu), a linkerowi trzeba podać w _bajtach_. Poprawiłem
makefile i wszystko śmiga.

Dariusz Żołna

do góry

> Dzięki. Jednak było to coś zupełnie innego niż przypuszczałem.
> W dokumentacji Atmel podaje adress bootloadera w _słowach_ (zupełnie nie
> wiem w jakim celu), a linkerowi trzeba podać w _bajtach_. Poprawiłem
> makefile i wszystko śmiga.

Dlatego w slowach, ze tak jest adresowana pamiec FLASH.

do góry

T.M.F. pisze:
>> Dzięki. Jednak było to coś zupełnie innego niż przypuszczałem.
>> W dokumentacji Atmel podaje adress bootloadera w _słowach_ (zupełnie
>> nie wiem w jakim celu), a linkerowi trzeba podać w _bajtach_.
>> Poprawiłem makefile i wszystko śmiga.
>
> Dlatego w slowach, ze tak jest adresowana pamiec FLASH.

A adres w tej pamięci podaje się w bajtach, więc nie tyle jest
adresowana w słowach, co zapisać i odczytać można tylko pełne słowo.

Dariusz Żołna

do góry

Dariusz Zolna pisze:
> T.M.F. pisze:
>>> Dzięki. Jednak było to coś zupełnie innego niż przypuszczałem.
>>> W dokumentacji Atmel podaje adress bootloadera w _słowach_ (zupełnie
>>> nie wiem w jakim celu), a linkerowi trzeba podać w _bajtach_.
>>> Poprawiłem makefile i wszystko śmiga.
>>
>> Dlatego w slowach, ze tak jest adresowana pamiec FLASH.
>
> A adres w tej pamięci podaje się w bajtach, więc nie tyle jest
> adresowana w słowach, co zapisać i odczytać można tylko pełne słowo.

Adresowana jest w slowach i tak sie podaje jej adres. Zauwaz, ze adresy
wszystkich stalych we FLASHu trzeba pomnozyc razy dwa. W slowach operuja
tez instrukcje skoku, jedyny wyjatek to instrukcje LPM i ELPM, ktore
operuja na adresie podanym w bajtach. I akurat o ile zapisac mozna tylko
pelne slowo (instrukcja SPM operuje wylacznie na slowach, rejestr Z
zawiera adres slowa zapisywanej komorki, a nie bajtu) to instrukcje
LPM/ELPM umozliwiaja odczyt pojedynczych bajtow, a nie slow. Moze to
troche pokrecone ale pewien sens ma, szczegolnie jesli patrzec na
architekture procesora.

do góry