Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

AVR231 bootloader - działa z atemga644 a nie działa z atmega128

Karol966 04 Lip 2016 16:50 924 8
  • #1 04 Lip 2016 16:50
    Karol966
    Poziom 30  

    Witam

    Odchodzę od zmysłów. Uruchamiałem kiedyś ten bootloader z mniejszymi procesorami i było ok, teraz od 3 dni męczę się z atmegą128. Wszystko się kompiluje, ładuję bootloader a potem podczas aktualizacji wyskakuje mi info:

    Cytat:
    CRC error. File dameged
    tyle, że nie używam sprawdzania CRC.
    Ostatnio, w zasadzie za każdym razem jest po prostu brak odpowiedzi od targetu.

    Przerobiłem projekt przygotowany dla procesora ATmega128, klika zmian jakie wprowadziłem:
    sys_startup.c zakomentowałem część dotyczącą MCUSR bo był błąd
    Kod: c
    Zaloguj się, aby zobaczyć kod

    w pliku aesflash.S zamieniłem odwołania do SPMCR na SPMCSR
    Kod: c
    Zaloguj się, aby zobaczyć kod


    w opcjach linkera:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    w opcjach kompilatora:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    w pliku loader.c
    zmienna address:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    oraz:
    Kod: c
    Zaloguj się, aby zobaczyć kod




    Bazuję na przykładach z książki TMF (która już jest lekko zmęczona życiem dla tego rozdziału;) ) Używam AtmelStuido 6.2 (zamiennie na laptopie 7.0)
    Projekt w załączniku. Bardzo proszę o wskazówkę gdzie może znajdować się błąd. Przy okazji, czy to normalne, że program update.exe nie pozwala aby COM miał wysoki numer? Nie sprawdzałem dokładnie, ale używając numerów 2/5/7 działa ok a jak dam COM20/29 to wyskakuje błąd, z tego co pamiętam o braku protu lub jego zajętości.

    0 8
  • #2 04 Lip 2016 23:32
    Karol966
    Poziom 30  

    Dodam, że sam program bootloadera reaguje na przycisk, zapala diodę a jak dodałem na chwilę programowe echo dla USART to również działało więc hardware jest RACZEJ ok. BOOTSZ mam ustawiony na największy rozmiar (nie pamiętam już jaki).

    0
  • #3 05 Lip 2016 01:46
    373522
    Użytkownik usunął konto  
  • #4 05 Lip 2016 07:58
    Karol966
    Poziom 30  

    Tak, wiem że bootloader umieszcza sie na końcu flasha - opcja linkera to robi, adres jak widzisz jest 1E000 czyli blisko konca, wzór z książki tmf ale to właśnie jest bajtowo a nie word tyle że tak identycznie jest w książce czy przykładach. Symbol rampz oczywiście jest użyty, widziałeś pliki?

    0
  • #5 05 Lip 2016 10:00
    373522
    Użytkownik usunął konto  
  • #6 05 Lip 2016 21:41
    Karol966
    Poziom 30  

    W książce jest jak byk napisane:

    Kod: c
    Zaloguj się, aby zobaczyć kod
    oraz napisane jest, że atmel 'chce' adresy w typie word czy zatem nie powinno być w opcjach linkera podana połowa z 0x1E000 (co oznacza: 122880 dec) czyli 0xF000 (61440 dec). Również w plikach z przykładów do pobrania do książki, z której korzystałem mają zapisane 0x1E000 zamiast 0xF000 - jak to w końcu jest?[/code]

    Dodano po 1 [godziny] 48 [minuty]:

    Post pod postem ale przynajmniej ktoś zobaczy, że działam/ walczę nadal ale bez efektu.

    Zmieniłem opcję linkera na: -Wl,--section-start=.text=0xF000 no i teraz program update kończy się sukcesem, że niby pomyślnie zaktualizowano procesor ale flash od adresu 0x0000 jest pusty (same 0xFF).

    PS. Co tak na prawdę daje zmiana bitów bootsz? Dla każdej możliwości aplikacja niby się aktualizowała (dla każdej pozostawał pusty flash aplikacji).

    0
  • #7 05 Lip 2016 22:02
    373522
    Użytkownik usunął konto  
  • #8 05 Lip 2016 22:10
    Karol966
    Poziom 30  

    niveasoft napisał:
    Teraz sobie wyobraź że masz bootloader mniejszy niż ustawiłeś bitami BOTSZ0 i BOTSZ1 .. tam będą FFFF i procesor skoczy pod ten adres przy stacie i nic znaczącego się nie stanie bo on będzie czytał po kolei kolejne komórki pamieci flash aż w końcu napotka Twój Bootloader :D i zacznie działać.
    Dokładnie tak to sobie wyobraziłem ale teraz popatrz: ustawiam sobie fusami początek bootloadera dla rozmiaru 512kw (1kb) czyli baaardzo blisko końca pamięci flash a w opcji linkera jest podany początek znacznie wcześniej (bo bootloader ma np 2kb) więc przy starcie programu procesor ruszy od połowy bootloadera racja? Czy wtedy zresetuje się procesro (licznik stanu czy jak tam mu było) i ruszy od zera - tu nic nie ma bo flash pusty więc w końcu dojdzie do właściwego początku bootloadera, który jest 2kb od końca flash a nie 1kb?? Dobrze myślę?

    PS. Bij zabij - program działa, nie wiem dla czego, różnica taka, że teraz pracuję z AS7 a na drugim kompie mam AS6.2 więc mam inne ustawienia projektu (może jakieś flagi są ustawione, dodatkowe opcje kompilatora/ linkera)? Adres dla linkera jednak musi być 0x1E000.

    0
  • #9 07 Lip 2016 00:50
    Karol966
    Poziom 30  

    A czy możecie mi podpowiedzieć jak wykonać opcję uruchamiania bootloadera za pomocą markera w eepromie? Chciałem zrobić wg książki tmf'a ale czegoś nie rozumiem.
    Bootloader szuka w ostatniej komórce pamięci eeprom wartości APP_OK

    Kod: c
    Zaloguj się, aby zobaczyć kod
    jeśli tam taka jest to znaczy, że program jest aktualny a jeśli nie ma tam takiej wartości to uruchamia się loader. Docelowy program jawnie do komórki pod adresem E2END wpisuje wartość APP_OK. Jeżeli użytkownik zechce wykonać aktualizację to poprzez opcję z menu program zapiszę w komórce E2END wartość !APP_OK oraz wykona restert procesora. No i teraz powstanie problem bo loader ładuje nowy firmware po czym się restartuje i ponownie uruchamia bootloader, który sprawdza, że nadal w E2END znajduje się !APP_OK (bo aplikacja jeszcze nie zdążyła się uruchomić). No ale chyba aplikacja powinna się uruchomić skoro po aktualizacji firmware jest skok:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Ogólnie tak to wygląda:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Czego znowu nie rozumiem? :)

    _______________
    Jeżeli po aktualizacji firmware zmienię celowo bity BOOTSZ tak by były błędne czyli z
    Kod: c
    Zaloguj się, aby zobaczyć kod
    na np
    Kod: c
    Zaloguj się, aby zobaczyć kod
    czyli gdzieś już za bootloaderem (a na pewno nie na jego początku) przez co program w rezultacie zacznie się od adresu 0x0000 czyli uruchomi się aplikacja a wtedy dokona się zapis APP_OK:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Potem przestawiłem fusy na prawidłowe no i już bootloader "widział', że app jest OK.

    Zmieniłem nawet główną funkcję uruchamiająca boota:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Czyli po aktualizacji na chama zapisuję do komórki eepromu o adresie E2END wartość APP_OK a dopiero potem reset = nic to nie daje :(
    Proszę o pomoc, głowa paruje a tu znowu w miejscu człowiek stoi. Bootloader męczę od kilku dni więc pewnie wielu rzeczy jeszcze nie wiem dlatego wybaczcie jeśli jakieś moje błędy są karygodne.

    0