Wydaje mi się, że robię wszystko dobrze.

Ustawiam fusebity zgodnie z poradnikami Mirka i za pomocą MKAvrCalculator-a.
Programuję je przez wbudowany w zestaw atb-usbasp.
Wchodzę do mkbootloader-a. Wybieram właściwego Atmega32. Generuję wsad, kompiluję i wgrywam. Testuję BLS Info. Pokazuje tak jak powinno.
Wchodzę do MKClipse. Kompiluję najprostszego Blink-a, wybieram wgrywanie przez MKBoot RS232. I program się wgrywa. Widać, że działa.
Ale przy ponownym załadowaniu przez mkbootloader już tego nie chce zrobić.
Gdzie szukać problemu?

Pozdrawiam,
frank75

Problem już chyba znalazłeś, teraz warto by znaleźć jego źródło, albo jeszcze lepiej rozwiązanie

Bootloader uruchamia się zaraz po resecie mikrokontrolera. Jeśli w procku nie ma innego wsadu, to (jak dobrze pamiętam) jest aktywny cały czas, a jak jest inny wsad - to przez krótki czas (ustawioną w konfiguracji liczbę sekund)
Jak wrzucisz sam bootloader, to po prostu czeka on na wysłanie wsadu z MKBootLoadera/MKClipse.
Jak już ten wsad wrzucisz, to procek się resetuje, bootloader jest zapewne aktywny parę sekund i potem przechodzi do Twojego programu, który miga diodą.
W tym prostym programie zapewne nie ma obsługi UARTA, więc kiedy MKBootLoader/MKClipse wysyła komendę "AT+RST?" to nic się nie dzieję - procek się nie resetuje i nie będzie czekał na wsad.

Teraz jest kilka opcji. Zapewne jeśli tuż przed wysłaniem wsadu z MKBootLoadera/MKClipse sam zresetujesz procka, to wsad zapewne zostanie normalnie wgrany na MCU przez BootLoader.
Możesz też zaimplementować włąsną rutynkę, która w programie będzie oczekiwała na odpowiednią komendę. Chyba były gdzieś poradniki Mirka na ten temat, ale nie mogę teraz na szybko znaleźć. Na pewno jest to opisane w GreenBooku - na przykładzie aplikacji testowej (str. 406, rozdział 10 : UART - zdarzenia, parsowanie danych). Jak wolisz rozwiązanie "bez gwarancji", to możesz też rzucić okiem na mój program testowy dostępny tutaj: kmUsartTermLogTest

Można też MKBootLoader3 użyć rozwiązania resetu hardware-oweg. Wtedy nie trzeba nic programować dodatkowo. Działa to z modułami ATNEL-WIFI-ESP.
Tutaj krótka demonstracja:

ATNEL ESP-01m4 - zastępca dla poprzednika ATNEL WIFI232-T - PLUS nowe możliwości - zdalny hard RESET

Mam nadzieję, że informacje się przydadzą

W mkbootloader jest opcja sprzętowego resetu, używając linię DTR. Nie pamiętam, jak jest w mkClipse. Zawsze możesz spróbować spiąć DTR z listwy między przetwornicą a wyświetlaczem z pinem RESET ATmegi

Dziękuję kolegom za nakierowanie na źródło problemu, bo zdecydowanie chodziło mi o znalezienie przyczyny Wszystko działa.



Dokładnie tak było i właśnie to jako pierwsze przetestowałem. Jak uruchamiałem wgrywanie przez bootloader i zaraz potem nacisnąłem przycisk, program się ładował. Tak samo z BLS info. Odczytywał gdy nacisnąłem reset.

Trochę straciłem czasu, bo przestawiłem sobie wcześniej w MkClipse: Settings → as BLS section na wartość 0x7E00. Ma być 0x0000 czyli Set Default address. Efekt był taki, że program ładował się przez mkbootloader ale nie startował (nic się nie działo).

Te zdania dały mi do myślenia:




Sprawdziłem dokumentację dla ATB 1.05a wpisując DTR:
strona 15:
[ JP8-ARST ] - zwarta, włączony auto RESET z linii DTR układu, FT232R (jak w Arduino)
rozwarta *, linia RESET odłączona od DTR

Domyślnie jest zatem rozwarta czyli RESET odłączony od DTR (tak było też u mnie). Przestawiłem i wgrywanie działa już za każdym razem z MkBootloder-a, z MkClipse-a oraz z Eclips-a.

Załączam zdjęcie zworki po przestawieniu: