Dzień dobry.
Mam małą uwagę do ładowania wsadów MkBootloaderem.
Program bardzo ładnie programuje mi AVRy.
Obecnie robię w Bascomie pewien projekt w którym Atmega 1284P wysyła non stop dane do terminala PuTTY.
Zrobiłem programową detekcję komendy reset wysyłanej z MkBootloadera (reakcja na AT+RST)
I to działa bez zarzutu do momentu kiedy procesor nie wysyła nic do terminala.
Kiedy wysyłanie jest aktywne to w momencie wciśnięcia przycisku UPLOAD HEX/BIN procesor resetuje się
ale bardzo często (nie zawsze) MKBootloader zgłasza błąd, to samo przy wykrywaniu typu procesora (przycisk BLS INFO)
Podejrzewam że w momencie wciśnięcia UPLOAD HEX/BIN MkBootloader jest "bombardowany" danymi z procesora.
Używam przejściówki USB/RS232 z chipem FT232 i może pewne dane odebrane z procesora siedzą jeszcze w buforze odbiorczym przejściówki.
Tak jak pisałem wyżej gdy AVR nie nadaje do terminala proces ładowania wsadu startuje praktycznie za każdym razem.
Typ chipa jest wykrywany za każdym razem.
I tu moja sugestia, może zdobić w MkBootloaderze funkcję która opóźnia reakcję na dane wysyłane przez bootloader.
Przykładowo wciskam UPLOAD HEX/BIN i MkBooloader wysyła komendę reset po czym czeka np 1 sek i zaczyna nasłuchiwać bootloadera.
Można by zrobić ustawiany czas tego opóźnienia.
Nie wiem czy rozumuję w dobrym kierunku.

Pozdrawiam.

To że się procek resetuje to niestety nie może być żadną winą MkBootloadera - coś u ciebie poszło nie tak i musisz poszukać przyczyny.

Zaś sam MkBootloader na PC działa właśnie DOKŁADNIE tak jak piszesz czyli jak ma sprawdzić - to dopiero wysyła komendę AT+RST i wtedy odbiera - a nie, że cały czas .... coś nie tak może albo zaobserwowałeś albo opisałeś niestety. Gdyby MkBootloader miał cały czas nasłuchiwać to byłby kompletny nonsens niestety - od pierwszej wersji tego programu, nigdy tak nie było żeby on cały czas nasłuchiwał.

Tzn nie mówię że nie ma żadnego problemu - ale musiałbyś może spróbować jeszcze raz to u siebie poobserwować i opisać

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Nie no MkBootloader nie powoduje samoistnych resetów mojego procka.
Procek sobie działa i mierzy sobie temperaturę.
Dane wysyła nonstop do UARTu czyli do pinu TX, tym samym UARTem wgrywam wsad do flasha.
I teraz jeżeli zachodzi sytuacja że mój procek nadaje do TX dokładnie w momencie wciśnięcia
przycisku UPLOAD HEX/BIN to np 7 na 10 prób kończy się tylko programowym resetem mojego układu
(poprawny odbiór komendy AT+RST)
Natomiast gdy zablokuję wysyłanie danych do pinu TX UARTa to wgrywanie działa 10/10.
I stąd moja sugestia że zaraz po wciśnięciu przycisku UPLOAD HEX/BIN do MkBootloadera docierają jeszcze dane
wysłane w mojego procka które MkBootloader źle interpretuje zgłaszając błąd i kończy pracę.
(może te dane siedzą jeszcze w buforze przejściówki FT232)

Pomyślałem że mogło by to działać tak:

init delay w BLS Generator ustawiony na 2 sek
I teraz przycisk UPLOAD HEX/BIN --> komenda AT-RST --> 1 sek ignorowania tego co nadchodzi z UART
i dopiero oczekiwanie na zgłoszenie się bootloadera.

Spróbuję dać po pracy screena co dokładnie zgłasza MkBootloader.

A ok, teraz rozumiem ideę problemu, rzeczywiście tak może być ... ale masz na to proste rozwiązanie:


1. MkBootloader może sprzętowo resetować procka przed wysłaniem zapytania (masz ptaszki dla linii DTR i RTS)
2. wyprowadź te linie z przejściówki USB/RS232 i szeregowo przez kondensator 100nF podłącz ale tylko jedną z tych linii do pinu RESET procka

i będzie pełnia szczęścia bo procek zanim wyśle AT+RST? to najpierw zresetuje procka sprzętowo.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Bardzo trafna uwaga, już tak robiłem jednak pojawiła się konieczność programowania procka zdalnie.
Robiłem już próby i bez problemu programowałem układ przez internet korzystając z modułów UART-LAN.
I tu niestety mam do dyspozycji tylko sygnały TX i RX.

Tez tak mam gdy sie intensywnie używa uart. Jednak klikniecie raz czy dwa razy zanim się zresetuje to chyba nie jest az taki wielki problem.

A może by wykorzystać 2 UART i MKBootloader3.
I niech Twoje dane wyrzuca na UART1 a UART2 do BLS.
A Twój AVR to 1284P więc ma taką opcję.

No zgadza się , tak będzie trzeba zrobić.
Mogę jeszcze zdalnie wyłączyć nadawanie do UART i też to rozwiąże problem

ok ja spróbuję sobie za jakiś czas zasymulować taki problem i jeśli będzie tak samo występował jak u autora - to rzeczywiście może jeszcze coś pokombinuję w MkBootloaderze

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Jeżeli mogę coś dorzucić, to ja też miałem problem przy ładowaniu wsadu przez wirtualny COM po WiFi.
Najpierw idą krzaki dopiero później właściwa komenda AT+RST, program w uP traktuje to jako jedna obcą komendę i nie resetuje procka.
Co ciekawe w wersji MKBootloader2 ten problem nie występuje.
Z tego co zauważyłem to MKBootloader2 powtarza wysyłanie tej komendy kilka razy, MKBootloader3 już tylko raz.
U mnie MKBootloader2 pod tym względem lepiej się sprawdza.

Ewentualnie dobrym rozwiązaniem byłoby wysłanie przed właściwą komendą znaków CRLF.
Wyczyściło by to w uP ewentualny bufor ze śmieciami.

To jak już będziesz kombinował to wykombinuj, żeby MkBootloader 3 wykrywał do jakiego portu jest podłączony Ftdi. Tak jest w poprzedniej wersji. Przy większej ilości urządzeń trzeba pamiętać na jakim porcie co jest. Często odpalam MK2, tylko po to żeby sprawdzić na jakim porcie mam podłączone.

Też podobny problem zaobserwowałem u siebie dawno temu - używam "mkBoot LOADER ver.2.0.0 build 11" (pisownia tak jak w okienku programu).

Poradziłem sobie programowo - w zdalnie programowanym urządzeniu z ATmega88 przez Bluetooth HC-05 dodałem kolejne polecenie AT - wyciszenie komunikacji "wychodzącej" UART. Nie należy mylić z wyłączeniem UART! Po otrzymaniu owej specjalnej komendy UART cały czas działa bez zmian, jedynie kontroler przestaje wysyłać wszelkie dane / komunikaty jakie poprzednio wysyłalem przez UART do terminala.

Tym samym aby zdalnie zaprogramować moje urządzenia muszę wysłać dwa polecenia:
- najpierw z poziomu terminala PuTTY (lub innej dowolnej aplikacji terminalowej lub własnej) komendę AT "wyciszającą" komunikację wychodzącą,
- następnie - po zaznaczeniu odpowiedniej opcji "mkBoot LOADER" wysyła komendę AT+RST.

Działa bez zarzutu od kilku lat w 3 domowych urządzeniach.

Równie dobrze można by opisane wyżej "wyciszanie" komunikacji wychodzącej umieścić w procedurze obsługi komendy resetującej AT+RST. Ja wolałem mieć dwie osobne.

Nie uważam, że to idealne i jedynie słuszne rozwiązanie (zresztą wspominane powyżej), ale może powyższy pomysł szerzej opisany kogoś zainspiruje lub komuś pomoże.

ok - przyjąłem wszystkie uwagi - popracuję nad tym, tym bardziej że już wiem jak sobie to testować

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Po wciśnięciu przycisku BLS INFO błąd jaki zwraca MkBootloader to: ERROR - Bad PageSize from BLS[]
Po wyłączeniu nadawania do UART 10 na 10 poprawnych zgłoszeń typu procesora.

jasne - pseudo naukowcy - będą działać nad poprawkami

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Znowu zagonisz klony do pracy?

eeeeh właśnie już mi się pokończyły klony

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Przy okazji zapytam o to czy MkBootloader podczas wgrywania wsadu do procka weryfikuje poprawność wgrania ?

nie weryfikuje bo nie ma takiej potrzeby

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Pytam bo podejrzewam że czasem wsad wgrywa się z jakimś błędem.
MkBootloader pokazuje 100% wgrania wsadu i niby wszystko jest OK ale
program albo nie startuje i muszę wgrać go ponownie i wtedy działa.
Albo program rusza i np ekran powitalny na LCD wyświetla jakiś krzak.

W takim przypadku podłączyłem programator na ISP i dokonałem porównania wsadów.
(funkcja weryfikacji wsadów w programie do obsługi prog na ISP)
Podczas wadliwego działania programu takie porównanie zawsze pokazuje różnicę między
wsadem wzorcowym a tym odczytanym z flasha procka.
Kiedy wgranie MkBootloaderem przebiegnie poprawnie porównanie wsadów zawsze pokazuje 100%
zgodności.
Na stole to nie problem bo wgram sobie wsad jeszcze raz ale jeżeli będę chciał wgrywać zdalnie
to już trochę komplikuje sprawę.

Pewnie że czasem się może nie wgrać wsad ale to chyba jasna sytuacja i trzeba powtórzyć. Jeśli się wgra w 100% to jest OK.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

No właśnie wgrywa się na 100% i czasem program nie uruchomi się wcale lub startuje z błędami w napisach
które wyświetla LCD.
Ponowne wgranie rozwiązuje problem.
Nie wiem jak działa ładowania flasha poprzez bootloader ale czy nie może się czasem przekłamać jakiś bajt ?

A to nie jest przypadkiem problem złego doboru baudrate do kwarcu?

_________________
Lampka Leuchtglas
Motorek Witka

Też mi się tak wydaje, że tak może być - jeśli się dobierze na przykład:

kwarc: 16 MHz
baudrate: 115200

przy takim układzie procent błędu to zdaje się jest = 3

więc tego typu problemy mogą być na porządku dziennym.


to podaj konkretnie jaki masz kwarc, procek, fusebity i baudrate ok? Aha i jak masz w procku wyliczoną wartość do rejestru UBRR bo tu też można sobie napsuć

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

ATMega2560 na płytce arduino MEGA 2560 Pro
Moduł USB-232 na tej płytce to UC340G z kwarcem 12
kwarc zmieniłem z 16 na 14,7456 MHz
baudrate 38400

Akurat bawię się Bascomem i daję zrzut ustawień fusebitów.

[/url]

coś ten zrzut ekranu źle wkleiłeś

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

o przepraszam

No to jeśli masz kwarc tak jak pisałeś to powinno być ok

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]