Witam.
Mam wgrany BLS do uC.




Następnie wgrywam z powodzeniem HEX ( działa po RS232 i po WIFI).



Kolejna próba wysłania pliku HEX kończy się niepowodzeniem. Proszę o pomoc w znalezieniu błędu.

Aby bootloader działał musi być odpowiednio zmodyfikowany wgrywany program który chcesz obsługiwać BLSesem.
A z kodu widzę że wgrywasz czysty wsad jaki jest w książce. Musisz bardziej dokładnie zapoznać się z poradnikami Mirka w tym
zakresie.

Musisz na pewno odpowiednio ustawić fusebity, tu link do poradnika Mirka :
https://www.youtube.com/watch?v=J3kPNmb3wV4, jak dobrze kojarzę tam jest wyjaśnione co i jak, jak nie będzie to do AVPlayer ( który znajduje się na stronie atnel ) wrzuć hasło bootloader i wyskoczą Ci wszystkie poradniki na ten temat. Miłego oglądania.

A czy w kodzie który próbujesz wgrać masz odbiór stringa resetującego mikrokontroler AT+RST?

Bo to jest prawdopodobnie powód timeoutu przy następnej próbie zaprogramowania uC.

Krótki test wciśnij wgraj i naciśnij reset na uC.

Witam.
Posiadam Atmegę328 i sprawdzałem wgrywanie tego samego pliku.
Mogę wgrywać tyle razy ile mi się podoba.
Wgrywam przez RS-232 i bootloader.
W bootloader zakładka hardware RESET mam zaznaczone: Reset on i RTS

Odznacz ptaka "use string"

Mam wrażenie że kolega nie do końca łapie całą ideę bootloadera.
Owy bootloader to jest osobny program zapisany na końcu pamięci flash (dokładne miejsce wyznacza się ustawieniami fusbitów).
I teraz zasada jest taka jeśli w pamięci uC jest wgrany tylko bootloader bez docelowego programu to procek czeka cały czas na dane po UARCIE bo jedynym programem w uC jest właśnie bootloader - więc jest on aktywny cały czas.
Natomiast gdy w pamięci uC ląduje już napisany przez Ciebie program wówczas po starcie uC bootloader jest aktywny przez czas jaki podałeś na początku jego kompilacji w sekcji "Wait time after restart (sec)". Jeśli w ciągu tego czasu po UARCIE nie nadlecą właściwe dane uruchamiany jest program główny. Właśnie dla tego nie możesz nic ponownie wgrać bo w procku w tym monecie działa Twój program a nie bootloader. W momencie gdy chcesz wgrać (gdy klikasz "Upload hex") musisz szybko zresetować procka by ten uruchomił bootloadera.
Jeśli byś chciał móc wgrywać bez ręcznego resetowania procka to w swoim programie musisz dodać opcje samoresetu - poprostu w Twoim programie musi być "ciągłe nasłuchiwanie" UARTA specyficznego ciągu znaków (opcja software reset w MkBootloader). W odpowiedzi na odebrany ciąg robisz aktywację watchdoga z najkrótszym czasem zadziałania i czekasz aż watchdog zrobi robotę czyli zresetuje procka, a co za tym idzie wymusi start bootloadera i cały proces programowania poleci jak trzeba.
Reasumując bootloader jest aktywny tylko przez czas timeoutu zaraz po starcie procka chyba że jest jedynym kodem wgranym na uC. Z czasem timeoutu też nie można przesadzać bo jednocześnie opóźnia to start docelowego programu procka. Dasz za długi timeout to przy każdym uruchomieniu procek będzie czekał na dane po UARCIE więc przy użytkowaniu urządzenia w którym procek będzie siedział może być to uciążliwe, natomiast za krótki czas może być problematyczny np przy programowaniu przez bluetootch - czas zestawienia połączenia przez moduły musi być krótszy niż timeout bootloadera.
Pooglądaj dobrze poradniki Mirka w tym temacie, jak również poczytaj dokładnie co jest napisane na stronie atnel http://www.atnel.pl/mkbootloader.html

------------------------ [ Dodano po: 2 minutach ]

Opcja ta ma sens gdy masz podpięty do resetu swojego procka sygnał RTS z portu RS232(oczywiście uwzględniając konwersję napięć jeśli konieczna), wówczas MkBootloader właśnie przy pomocy tego sygnału wymusi reset procka.

Bardzo czytelny opis, przyda się potomnym