logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Bootloader AVR231 - przeróbka na Atmega4809 - brak zapisu do flash

electro 13 Cze 2020 13:57 1056 11
REKLAMA
  • #1 18756712
    electro
    Poziom 18  
    Chciałbym użyć przykładowego bootloadera z AES z Microchipa AVR231 Link (oryginalnie dla Atmega 328PB)
    Jednak chciałbym go używać na Atmega4809.
    Najpierw zrobiłem drobne przeróbki i przeprowadziłem testy na 328P, wszystko działało poprawnie. Następnie przerobienie obsługi USART dostosowując do 4809, poszło bez problemów jednak nie umiem sobie poradzić z zapisem flasha przez bootloader, niby wszystko działa, program do uploadu po serialu ładuje, dochodzi do 100%, ale po restarcie mamy znów bootloader. Po odczytaniu pamięci widać że nic się nie zapisuje, podejrzewam że to przez nie odpowiednia obsługę kontrolera NVM, lub coś pomieszane w adresach. W przykładzie obsługa zapisu do flash jest zrobiona w ASM.

    Zapis to jedno, chyba jest coś nie tak z ustawieniami fuse bitów, BOOTEND i APPEND, kiedy ręcznie wrzuciłem plik programu od 0x0 flasha to program startuje poprawnie. (dla ustawień boot i app na 0x0) W tym samym momencie bootloader zaczynał się od 0xAC00, i tak też był ustawiony linker (-Wl,-section-start=.text=0xAC00) kiedy wyczyszczę pamięć aż do 0xAC00 to startuje bootloader, przy takich samych ustawieniach BOOTEND i APPEND. Czyli niezależnie od położenia początku programu startuje od 0x0, a jak nic nie ma "po drodze" to jakby leci aż coś znajdzie?
    Kolejną sprawą jest to że w 328P bootloader jest zlokalizowany na końcu pamięci, a start ustawiony jest poprzez fusebit np na 0x7800, z tego co widzę w 4809 jest chyba odwrotnie, przykładowy bootloader dla nowszych AVR, bez obsługi AES mam Tutaj,

    Niestety nie mogę tego ogarnąć i proszę o pomoc, jeżeli to kogoś bardziej zmotywuje to może być odpłatna...

    Poniżej projekt przerobionego bootloadera w AS7
  • REKLAMA
  • #2 18756896
    tmf
    VIP Zasłużony dla elektroda
    W tych MCU wszystko wygląda zupełnie inaczej niż w starych megach. Przede wszystkim procesor zawsze startuje od 0x0000. Jeśli używasz bootloadera, to masz kilka opcji:
    - jeśli nie przeszkadza ci, że kod aplikacjci może zapisywać FLASH to nic nie robisz, cały FLASH ustawiasz jako sekcję bootloader.
    - jeśli przeszkadza, to musisz zmienić fusebity dzieląc FLASH na sekcję bootloadera i aplikacji.
    Bootloader jak widzisz zawsze startuje od 0x0000, natomiast kod aplikacji jeśli nie ma bootloadera to też od 0x0000, jeśli jest to tam gdzie ustawisz fusebitami. Czyli jest odwrotnie niż w starych AVR, ale jest to lepsze rozwiązanie.
    Aby móc zapisywać do FLASH, kod musi być wykonany z sekcji bootloadera, kod aplikacji ignoruje instrukcje zapisu, niezależnie od ustawień NVM. Czyli, żeby to działało, musisz wydzielić sekcję bootloadera przy pomocy fusebitów, umieścić tam bootloader, który po zakończeniu pracy wywoła kod aplikacji, a aplikację wgrywasz nie pod adres 0x0000, lecz pod adres wynikający z ustawień fusebitów. Stąd też wynika, że kompilacja aplikacji musi się odbyć z odpowiednim przesunięciem segmentu .text (tak jak to wcześniej się robiło z bootloaderem).
    No i pamiętaj, że trzeba odpowiednio skonfigurować NVM i że niektóre operacje są chronione, wioęc wymagane jest wcześniejsze zezwolenie w NVM, które jest wążne, o ile pamiętam 4 takty zegara. W tym czasie musi być wykonana operacja modyfikacji strony pamięci.
  • #3 18759848
    electro
    Poziom 18  
    Poświęciłem na to kolejne próby parę godzin i niestety bez efektów. Ostatecznie poskładałem obraz pamięci, tak żeby zobaczyć czy w ogóle mcu będzie startował, pod wskazany adres(0x0AA0) wrzuciłem program, który bootloader miał uruchamiać, program kompilowany z parametrem (Flash Segment .text=0x0AA0) BOOTEND i APPEND ustawiona na 0, ale za nic to nie działa, więc nawet nie startuje to przerabiania zapisu do flash.
    Do startu użyłem konstrukcji opisanej w bootloaderze do nowszych konstrukcji Link

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    A więc podtrzymuje ofertę płatnej pomocy, bo utknąłem :(
  • REKLAMA
  • #4 18760118
    tmf
    VIP Zasłużony dla elektroda
    A ten powyższy kod, gdzie się znajduje? Najlepiej zrób podgląd w oknie disassembly i pokaż co tam jest począwszy od 0x0000.
    BTW, pamiętasz, że Adresy we FLASH to adres podzielony przez 2? FLASH jest adresowany słowami.
  • REKLAMA
  • #5 18760844
    electro
    Poziom 18  
    Ok, można powiedzieć że jestem krok dalej:

    po ustawieniu fuse BOOTEND na 0xB oraz kompilacji programu aplikacji z parametrem linkera:

    -Wl,--section-start=.text=0x0B00.

    oraz ręcznym wrzuceniu programu aplikacji pod adres 0x0B00 flasha mcu program startuje, oraz poprawnie wywołuje tryb DFU bootloadera po resecie. zastosowałem poniższą konstrukcję

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Czyli wygląda na to że kluczem było ustawienie BOOTEND

    Ale to mniej niż połowa sukcesu, pozostaje zapis do pamięci, czyli funkcje:

    spmErasePage();

    z tego co mówiłeś, udało mi się znaleźć funkcję odpowiedzialną za odblokowanie np. kasowania strony, jednak jak by m nie próbował wmontowywać to do żadnego zapisu nie dochodzi. Nie wiem tez do końca jak to wyłapać debbugerem, mam to na płytce ATmega4809 Curiosity Nano ale coś mi nie łapie breakpointów.

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Załączyłem tez to co pokazuje mi się w debugerze disassembly, w trybie DFU
  • #6 18761362
    JarekC
    Poziom 32  
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
    Do noty aplikacyjnej AN2634 jest dostępny przykładowy kod bootloadera UART (projekt w AS7)
    https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en604508.

    Najprostsza metoda zapisu do flasha w nowych AVR jest po prostu bezpośrednie pisanie po pamięci:

    definiujemy wskaźnik na pamięć Flash gdzie ma być aplikacja (WAŻNE jest to adres względniający offset dla FLASHA dla ATMEGA4809 jest to 0x4000)
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    wpisujemy dane i inkrementujemy wskaźnik, aż do zapełnienia bufora strony
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Powyższe działania powodują że dane są wpisywane do bufora strony pamięci FLASH
    Rzeczywisty zapis nastąpi po wywołaniu:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    Wykonanie zapisu automatycznie kasuje bufor strony tak ze mamy czysty przed następnym zapisem.
    Powyższa metoda jest właściwa jeżeli chcemy zapisać całą stronę, lub tylko jej część a pozostałą skasować.
    W przypadku gdy chcemy zmodyfikować część strony to wcześniej musimy, wyzerować bufor strony, wypełnić go kopią z FLASHa uzupełnić nowymi danymi i dopiero wywołać zapis.

    Kluczowym problemem u Ciebie jest prawdopodobnie to że nie uwzględniasz offsetu dla FLASHA ewentualnie EEPROMu.
  • #7 18761897
    electro
    Poziom 18  
    No dobra jest znów krok do przodu, jest zapis! Co prawda zapisują się bzdury, ale od odpowiedniego momentu czyli 0x0B00, z adresami już wszystko OK. Zapis wziąłem z przykładu bootloadera dla megaAVR 0-series. Niestety tam tam bufor zapisu był ładowany bezpośrednio ze znaków odczytanych z UART, tutaj jest trochę inaczej bo po odczycie są przepuszczane przez dekodowanie. I znów problem, załączam kod odpowiedzialny za dekodowanie i zapis z moimi zmianami i komentarzami.
    Czuję że problem jest w odpowiednim przepisywaniu danych z pageBufferPtr do app_ptr, czyli naszego bufora do zapisu, ale na obecnym etapie nie łapię się w tych wskaźnikach.


    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
  • #8 18763903
    electro
    Poziom 18  
    Udało mi się opanować debbuger, czytał plik ELF release zamiast debug. Przy jego pomocy ustaliłem że do funkcji zapisu idą poprawne adresy.

    spmWriteWord(addrCounter, mnemonic); // addrCounter - adres komórki pamięci, zgodny z lokalizacją aplikacji, zaczyna się w moim przypadku od 0x0B00


    Wygląda na to że gdyby w tym miejscu wpisywać dane z pageBufferPtr do app_ptr, czyli do pamięci zaczynając od 0x0B00 a poźniej wywołać zapis to powinno działać, sęk w tym że kompletnie nie mogę ogarnąć tych wskaźników :( i nie wiem jak to zapisać. Panowie poratujcie
  • #10 18764293
    electro
    Poziom 18  
    Czekam z niecierpliwością. Mam nadzieję że będę mógł się odwdzięczyć!
  • REKLAMA
  • #11 19847582
    Karol966
    Poziom 31  
    Na czym stanął temat? Poszło coś na PW, że nie ma zakończenia? Również mam ten sam problem do przejścia. Na razem bez stresu, bez pośpiechu ale nie obejdzie się bez przeróbek as231 chyba że powstał inny, nowy szyfrowany bootloader.

    Pozdrawiam

Podsumowanie tematu

Użytkownik stara się zaadoptować bootloader AVR231 z AES od Microchipa, pierwotnie zaprojektowany dla Atmega 328PB, do mikrokontrolera Atmega4809. Po wstępnych modyfikacjach i testach na Atmega 328P, użytkownik napotkał problemy z zapisem do pamięci flash, mimo że proces uploadu przez UART kończył się sukcesem. Problemy te mogą wynikać z niewłaściwej obsługi kontrolera NVM oraz ustawień fuse bitów, takich jak BOOTEND i APPEND. Użytkownik odkrył, że kluczowe było poprawne ustawienie BOOTEND, co umożliwiło uruchomienie aplikacji z odpowiedniego adresu w pamięci. W dalszej części dyskusji poruszono metody zapisu do pamięci flash, w tym bezpośrednie pisanie do pamięci oraz użycie wskaźników do zarządzania danymi. Użytkownik poszukuje pomocy w poprawnym przetwarzaniu wskaźników i implementacji funkcji zapisu.
Podsumowanie wygenerowane przez model językowy.
REKLAMA