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

[Mega32U4] Bootloader - jak wykonać bez dodatkowych zworek

09 Lip 2018 15:38 609 15
  • Poziom 5  
    Cześć!

    Programuję procesor Atmega32U4 z wbudowanym sprzętowym wejściem USB za pomocą bootlodera oraz pfogramu o nazwie Flip ze strony Atmela.

    Niestety za każdym razem muszę ręcznie przepiąć zworkę na pinie PE2, która decyduję czy procesor ma wgrać program czy go rozpocząć.

    Pytanie w jaki sposób wyeliminować konieczność ręcznego przełączania tej zworki. To znaczy podpinam kabel USB, włączam Flipa i wgrywam program.

    Od razu dodam, że jest utrudnienie i samo podłączenie przewodu nie musi być tożsame z wgraniem programu, ponieważ 5 V z USB służy w tym przypadku do zasilania.

    Czyli jak w temacie jak wykonać "bootloder" bez zworek;)
  • Poziom 5  
    Cześć!

    Odświeżam ten temat, ale z troszkę innymi pytaniami:

    Bootloader działa, wgrywany za pomocą przejściówki RS232, reset procesora z wykorzystaniem systemu watch dog.

    1. Wgrywanie programu przez ISP kasuję bootloader. Czy jest możliwość w Atmel Studio opcji kasowania bootloadera podczas programowania przez ISP?

    2. Poszukuję konwertera plików hex na bin. Niestety z jakiś powodów nie mogę uruchomić na moim komputerze programu "hex2bin".

    3. Mam dwa pliki hex. Jeden od bootlodera i drugi program główny. Czy można i w jaki sposób połączyć te dwa programy w jeden plik i wgrywać je za jednym razem przez bootloder?

    4. W jaki sposób dołączyć do pliku hex informację o lockbitach i fusbitach?

    Pozdrawiam!
  • Pomocny post
    Moderator Mikrokontrolery Projektowanie
    ad 1. Jak sądzę interesuje cię opcja zachowania bootloadera podczas programowania ISP? Tak, da się to zrobić, musisz w oknie programowania przejść do zakładki production file, odznaczyć "erase memory before programming" i zaznaczyć jakie sekcje MCU chcesz programować.
    ad 2. objcopy -I ihex plik.hex -O binary plik.bin
    ad 3. Tak, użyj programu srec, który masz w toolchainie. Przy czym oczywiście możesz potem to wgrać programatorem, przez bootloader nie bardzo, bo dojdzie do sytuacji w której bootloader programuje bootloader.
    ad 4. Zasadniczo się nie da. W tym celu użyj formatu elf. W HEX można to zrobić na około - np. ustalić, że pod jakimś nieistniejącym w pamęci MCU adresem masz wartość tych bitów. Potem bootloader natrafiając na taki adres może to odpowiedni zinterpretować.
  • Poziom 5  
    Dziękuję za pomocną odpowiedź!

    Program "hex2bin" jednak działa, wystarczyło "przeciągnąć" plik "hex" na ikonkę programu i automatycznie wygenerował on potrzebny plik "bin".

    Przy okazji mam jeszcze jedno pytanie:

    Zależy mi na tym, aby zachować stan logicznej jedynki na jednym z pinów. Niestety podczas resetu stan na tym pinie jest także resetowany. Czy można jakoś zachować "informację" tak aby nie uległ on zmianie nawet w przypadku resetu?
  • Moderator Mikrokontrolery Projektowanie
    Są mikrokontrolery, które mają taką możliwość, niestety wymieniony przez ciebie do nich nie należy. Taki efekt możesz uzyskać stsoując rezystor podciągający na tym pinie. W trakcie normalnej pracy MCU będzie możliwość wystawienia 0 lub 1, natomiast przy wyjściach w stanie wysokiej impedancji (np. reset) rezystor wymusi stan 1.
  • Poziom 5  
    W sumie obecnie używam Atmega328PB, ale rozumiem, że to dotyczy całej rodziny AVR?

    Jest jeszcze opcja zmiany fusebitów, tak aby zmniejszyć czas bezczynności po resecie. Czy zmiana tego czasu na najkrótszy jest z jakiegoś powodu niekorzystna, są jakieś zastrzeżenia?
  • Moderator Mikrokontrolery Projektowanie
    Tak, dotyczy to całej rodziny AVR.
    Pawel_1985 napisał:
    Jest jeszcze opcja zmiany fusebitów, tak aby zmniejszyć czas bezczynności po resecie. Czy zmiana tego czasu na najkrótszy jest z jakiegoś powodu niekorzystna, są jakieś zastrzeżenia?

    To zależy od innych komponentów na płytce i zasilacza. To opóźnienie jest potrzebne np., do stabilizacji napięć, oscylacji zegara itd. Ale nawet jeśli je maksymalnie skrócisz to i tak przez krótki czas będziesz miał czas nieustalony. Wszystko zależy co pod ten pin masz podłączone i jak się zachowa jeśli tam się pojawi przypadkowe 0. Rozwiązanie z rezystorem jest powszechnie stosowane - np. sygnały CS urządzeń SPI.
  • Poziom 5  
    Jeszcze jedno pytanie. Korzystam z gotowego bootloadera działającego na Windowsie.

    Chciałbym wykonać taki sam program działający pod Windowsa.

    W celu sprawdzenia jak działa taki program podłączyłem sobie mikrokontroler do przejściówki RS232/USB oraz poprzez specjalny program podglądałem co dokładnie dzieje się na magistrali, jakie bajty są przesyłane.

    Specjalnie stworzyłem bardzo krótki program, tak więc wiedziałem z jakich bajtów po kolei składa się przesyłany program.

    Po teście okazało się, że faktycznie program wyłuskuję z pliku hex pojedyncze bajty i przesyła je do MCU.

    Niestety dodaję też jakieś swoje dodatkowe bajty, których nie ma w pliku hex.

    Teraz pytanie czy każdy program do wgrywania hex do bootloadera (np. megaload, bascomowy bootloader) działa w taki sposób i jeśli tak to gdzie taki format mogę znaleźć?
  • Moderator Mikrokontrolery Projektowanie
    Tak, każdy tak działa. Nie ma sensu większego na małych MCU robić interpretacji IntelHEX po stronie bootloadera, więc najczęściej na PC program konwertuje HEXa do postaci binarnej, a następnie opakowuje w specyficzny dla siebie format i przesyła do bootloadera w MCU. Zwykle ten format nie jest jakiś pogmatwany i szybko można go samemu rozkminić - na początek można zacząć od formatów opisanych w notach Atmela. Szczególy o ile są dostępne to znajdziesz je w opisie samego bootloadera.
  • Poziom 5  
    Poniżej wklejam "przechwyconą transmisje".

    Bardzo ładnie widać, że program hex jest przesyłany do pamięci flash bajt po bajcie w formie 128 słów na stronę.

    Zastawaniem się tylko nad początkiem tej transmisji i nad jej końcem.

    Początek to musi być adres początkowy pamięci ("01 01 FE") i próbuję znaleźć w dokumentacji Atmega328 dlaczego pamieć zaczyna się od tego numeru, a nie od wartości zerowych.

    Zastanawiam się też co oznacza ostatni bajt ("ED").

    Kod: c
    Zaloguj się, aby zobaczyć kod
    [/code]
  • Poziom 21  
    Pawel_1985 napisał:
    Korzystam z gotowego bootloadera działającego na Windowsie.
    (raczej na uK - program na windows to uloader) Napisz do autora maila i się zapytaj. Najprostsza metoda.
  • Moderator Mikrokontrolery Projektowanie
    Pawel_1985 napisał:
    Początek to musi być adres początkowy pamięci ("01 01 FE") i próbuję znaleźć w dokumentacji Atmega328 dlaczego pamieć zaczyna się od tego numeru, a nie od wartości zerowych.

    Zastanawiam się też co oznacza ostatni bajt ("ED").


    128 bajtów to pewnie wielkość programowanej strony w tym MCU. ED to bajt pewnie oznaczający koniec danych na stronie. Początek 0101FE to pewnie instrukcja określająca adres programowanej strony - przy każdej stronie jest to sekwencja 0101FE, czy dla kolejnych stron się zmienia? To jak ten zapis interpretuje kod bootloadera może być dowolne i dokumentacja MCU tu wiele nie pomoże.
  • Poziom 5  
    Nie, nagłówek i koniec zmeiniaja się. Nagłówki po kolei o 1 zmniejszają się, a bajt końcowy jest trudny do przewidzenia.

    Program jest krótki, więc strony po 128 słów są tylko trzy:
    1. 01 01 FE i koniec ED
    2. 01 02 FD i koniec AB
    3. 01 03 FC i koniec C8 (wcześniej program dopisuje, aby wypełnić stronę wartość 1A).

    Spróbuję zapytać się producenta oprogramowania ;)
  • Moderator Mikrokontrolery Projektowanie
    No to wygląda, że 0x01 to znacznik początku strony, potem masz nr programowanej strony, inwersję tego numeru, następnie dane i na końce zapewne jakaś kontrola poprawności danych - sprawdź po prostu sumę modulo 256, CRC8, czy coś w ten deseń.
  • Poziom 5  
    Końcowy bajt to suma kontrolna wyliczana według sumy modulo 256.

    Dziękuję za pomoc!
  • Poziom 5  
    Mały update sytuacji.

    W mikrokontrolerze mam wgrany bootloader pochodzący od MCS Electronics. Program wgrywam bardzo prostym programem od tego samego producenta.

    W pierwszej opcji wgrywam go za pomocą kabla z podglądem transmisji. Nie ma żadnych problemów, wszystko działa.

    Niestety nie rozumiem jak program bootloadera oblicza sumę kontrolną.

    Dla przykładu jedna ramka danych (3 bajty początkowe adresowe, 128 bajtów danych i jeden bajt sumy kontrolnej).

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Bajt sumy kontrolnej obliczany jest jako suma modulo 256 ze 128 bajtów danych.

    I tak wgrywane ramki z takimi sumami kontrolnymi przy wgrywaniu programu za pomocą kabla rs232 powoduje prawidłowe działanie mikrokontrolera.

    Natomiast w samym programie bootlodera nie widzę w jaki sposób jest to obliczane. Fragment kodu bootloadera poniżej:

    Kod: vbnet
    Zaloguj się, aby zobaczyć kod


    Patrząc na ten kod i ramkę danych:
    1. Pierwszy "waitkey" pobierze 01 jako "Bsstatus"
    2. Drugi "waitkey"pobierze 01 jako "bblock" plus dodanie do sumy kontrolnej
    3. Trzeci "waitkey" pobierze FE jako "Bcsum1" plus dodanie do sumy kontrolnej
    4. Kolejny "waitkey" to pobranie 128 danych plus dodanie do sumy kontrolnej
    5. Ostatni "waitkey" to pobranie ostatniego bajtu z ramki czyli sumy kontrolnej

    W przypadku przesłania sumy kontrolnej 0xED to nijak ma się do tego co wylicza bootloader, co wynika z kodu.

    Ten sam plik z tymi samymi danymi (podejrzanymi podczas transmisji) przesyłam przez kabel z wykorzystaniem programu od MCS i działa. Gdy te same dane wgrywam za pomocą innego programu to suma kontrolna nie zgadza się i program nie wgrywa się.

    W komentarzu w paragramie bootlodera jest taki zapis: "'this is the loader routine. It is a Xmodem-checksum reception routine "