Mam taki nieuciążliwy, ale dręczący mnie problem.

Korzystam w programie z możliwości sprawdzenia po resecie przyczyny zadziałania watchdoga. Generalnie wszystko działało do czasu, gdy przerzuciłem się na MkBootloader. Mimo, że jestem bardzo zadowolony, bo wsady do mega1284 po LANie śmigają jak TGV, to jednak program cały czas odczytuje rejestr MCUSR, jak gdyby został wyzerowany. Zajrzałem do kodu bootloader.c i rzeczywiście znalazłem tam

ale opatrzone warunkiem

Z kolei nigdzie nie znalazłem

więc, jak dobrze rozumiem, ten fragment nie powinien się kompilować.

Potrzebuje wiedzieć czy Mirkowy bootloader zeruje MCUSR, a jeśli tak, to czy można to wyłączyć i jak.

Oczywiście, że zeruje


Kod źródłowy jest otwarty można sobie wprowadzać dowolne zmiany

_________________
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 to kolejna seria pytań:
- czy można wyłączyć zerowanie MCUSR bez konsekwencji, tzn czy działanie bootloadera zależy od tego?
- gdzie następuje to zerowania - czy w tym miejscu, o którym pisałem, a jeśli tak, to gdzie zdefiniowany jest WDIF?

WDIF jest to nazwa bitu w rejestrze WDTCSR – Watchdog Timer Control Register

Wyzerowanie MCUSR jest "zapomnieniem" o przyczynie resetu mikroprocesora. Jak nie interesują Cię przyczyna, to możesz tego rejestru wcale nie dotykać. Ale wyzwolenie bootladera bo nieoczekiwanym resecie watchdoga, to tak trochę nie za ładnie.
Ja w swoim bootloaderze sprawdzam przyczynę resetu i nie w każdej pozwalam mu się uruchomić.

Pamiętaj tylko:


--
Pozdrawiam,
Robert

Generalnie wiem, jakie mam oczekiwania - chcę właśnie sprawdzać przyczynę resetu, stąd ten post. Ale już sobie z tym poradziłem - działa i bootloader i odczyt MCUSR:D

Ale za to:

masz ode mnie "Pomógł" - bardzo cenna uwaga!

Wątek do zamknięcia.

------------------------ [ Dodano po: 1 minucie ]

Ach, tutaj chyba nie da się samemu zakończyć wątku;)

Wątków nie należy zamykać jeśli ktoś w podobnym temacie może zadać pytanie.
Poza tym jak sobie poradziłeś to warto podać w jaki sposób - tak dla potomności.

--
Grzegorz...

No właśnie nie poradziłem sobie, jak się okazuje:/

Mam teraz taki problem, że po resecie procka poleceniem po "AT+RST", czyli gdy watchdog ustawia się na najkrótszy czas, w konsoli otrzymuję od bootloadera pytajniki bez możliwości zrobienia czegokolwiek. Wygląda to tak, jakby procesor ciągle się resetował. Tylko tyle, że w kodzie bootloadera mam taki zapis:


który teoretycznie powinien mi wyłączać watchdoga jeszcze przed programem. Nie wiem, co jest grane.

A przestaw watchdoga na maksymalny czas i zobacz czy zmniejszyła się częstotliwość resetów. Jak tak to na pewno działającego wina watchdoga, a jak nie, to masz jakiś inny błąd.

--
Pozdrawiam,
Robert

Wrócę do domu, to jak najbardziej sprawdzę. Ale czy to nie jest tak, że mimo ustawień watchdog po resecie i tak ustawia minimalny czas? Muszę zerknąć do dokumentacji.

Oczywiście reset przez watchdog ustawia domyślną wartość.
Ale mnie chodziło o zmianę przy procedurze wyłączania WD w bootloaderze. Jak twierdzisz, że Ci się WD nie wyłącza, to będzie można sprawdzić czy to prawda.

--
Pozdrawiam,
Robert

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

Jak masz ustawiony fuse bit WDTON?
Ustaw go fabrycznie (wyłącz "Watchdog Timer always on") i zobacz czy masz dalej cykliczne resety.

Zrobiłem więc następujące testy:
1. Brak bootloadera; WDTON=1 - reset programowy* działa prawidłowo.
2. Brak bootloadera; WDTON=0 - reset programowy działa prawidłowo.
3. Bootloader; WDTON=1 - bootloader działa prawidłowo, odpowiada na komendę "ui".
4. Bootloader; WDTON=0 - cały czas znaki "?", czasem, ale z wielkim trudem udaje się wymusić odpowiedź na "ui" - generalnie ciągły reset procka.

Ja z tego wnioskuję, że wyłączanie watchdoga w sekcji bootloadera nie działa. Tylko zastanawiam się teraz dlaczego. Korzystam z prawie standardowego kodu udostępnionego w mkBootloader z tą różnicą, że zmodyfikowałem go pod UART1.

* dla ścisłości reset programowy:

A pokaż sekwencję wyłączającą watchdoga w bootloaderze. Najlepiej wersję w asemblerze z pliku .lss.

--
Pozdrawiam,
Robert

A jak zmusić BLS Generator w mkBootloader żeby tworzył *.lss?

------------------------ [ Dodano po: 8 minutach ]

Nie znam się na assemblerze (żałuję, że za czasów Atari 800XE szerokim łukiem omijałem tą dyskietkę...), ale wyłuskałem coś takiego:

Jak masz plik .elf to aby dostać .lss należy użyć komendę:
avr-objdump -h -S Bootloader.elf >"Bootloader.lss"

Możesz to zrobić samodzielnie z linii poleceń lub dodać do Makefile

--
Pozdrawiam,
Robert

------------------------ [ Dodano po: 26 minutach ]

Czy testujesz na podanym na początku procesorze ATmega1284?

------------------------ [ Dodano po: 31 minutach ]


Według mnie to lss powinien zostać u Ciebie utworzony. Makefile od mkBootloader ma zapisy by go tworzyć:

No widzisz. A mój nie ma - ver. 2.0.0 build 10, a na drugim komp. nowszy.

Będę w domu, to skompiluję jeszcze raz z .lss.

Nie wytrzymałem i pogrzebałem;) Wygrzebałem z mojego lss takie coś:


Nie jest to w prawdzie dokładnie ten sam kod, z którego korzystam w domu, ale fragment dot. watchdoga testowany przeze mnie z marnym skutkiem.

------------------------ [ Dodano po: 3 minutach ]

I teraz zauważyłem jedną, ciekawą rzecz - brakuje klamry zamykającej funkcję. A w kodzie C jest... Czyżby coś było zamieszane z klamerkami w całym kodzie?

Powiem tak. Jak pisałem 10 lat temu swój bootloader na atmega128, to byłem przekonany, że opcja z fuse bit WDTON włącza na stałe watchdoga i nie ma możliwości wyłączenia go softwarowo. Dlatego mam w nim zawarte cykliczne resetowanie timera watchdoga (aby nie mieć problemów z resetem procesora to na początku ustawiam dużą wartość timera watchdoga).
Jakiś czas temu jak doszedłem do etapu aby spróbować przeportować swój kod bootloadera z asemblera na C (co z braku czasu do tej pory nie udało mi się), to pod wpływem różnych informacji nabrałem przekonania, że jednak odpowiednia sekwencja ma możliwość wyłączenia watchdoga.
Ale teraz po Twoich problemach przejrzałem datasheeta i znowu wracam do swojego starego przekonania, że jak ustawisz watchdog always on (fuse bit WDTON) to nie możesz go w żaden sposób wyłączyć. Aż dzisiaj wieczorem to sprawdzę.

--
Pozdrawiam,
Robert

Ale spójrz proszę jeszcze raz na moje testy:


Na początku programu robię to:


Więc jednak programowo da się wyłączyć watchdog mimo ustawionego bitu WDTON.

A czy w programie nie masz cyklicznego zerowania watchdoga i dzięki temu działa?
Zaraz wygrzebię płytkę z atmegą128 i posprawdzam u siebie.

--
Pozdrawiam,
Robert

Hmmmmm... Zasiałeś ziarno niepewności. Wyłączam na początku watchdoga, żeby spokojnie odczytać MCUSR, potem wykonuję cykl operacji zajmujących kilka sekund, a watchdoga resetuję w pętli while. Ale teraz nie jestem pewny czy przypadkiem nie przełączam licznika na 8 sekund...
Sprawdzę.
Notabene bardzo trzeźwo myślisz.

Sprawdziłem u siebie na ATmega128 i nie da się programowo wyłączyć watchdoga jak jest on włączony poprzez fuse bit WDTON.
Czyli jest tak jak kiedyś myślałem i zrobiłem u siebie w bootloaderze. W datasheet od Atmega128 watchdog jest czytelniej opisany i czytając go nie ma się wrażenia sugerowania możliwości wyłączenia programowego przy włączeniu go poprzez fuse bit WDTON. W datasheet od Atmega1284 już jest bardziej pomieszane, bo być może autor chciał za dużo przekazać w krótkich słowach a sam watchdog w tym procesorze jest bardziej skomplikowany, bo obsługuje dodatkowo tryb z przerwaniem timera watchdoga.
Tak więc według mnie jak jest ustawiony watchdog do trybu always on poprzez fuse bit WDTON, to nie można go wyłączyć programowo i bootloader musi zostać zmieniony. Wystarczy zrobić drobną zmianę i pozbywamy się problemu

W Mirkowym bootloaderze dla procesorów z watchdogiem w trybie always on należy zamienić kod w dwóch miejscach:
1. zmienić w static void __init3( void ) próbę wyłączenia watchdoga na zmianę timera wachdoga na długi czas np. (choć w niektórych procesorach można jeszcze wydłużyć poprzez dodanie bitu WDP3):


2. dodanie resetowania timera watchdoga __watchdog_reset(); w funkcji czekającej na obiór z RS232 np. na początku pętli do w funkcji static uint16_t _UART_RX_Wait( uint16_t Timeout ):


Przy ustawionym długim czasie timera watchdoga chyba wszystkie inne procedury zdążą się wykonać i nie trzeba dodawać nigdzie więcej rozkazu zerowania timera watchdoga. Ale to dobrze byłoby jeszcze przeanalizować.

--
Pozdrawiam,
Robert

Niestety masz rację. Usunąłem z kodu wszystkie makra resetujące watchdog i z włączonym bitem WDTON procek się restartuje co 15 ms.

Ale całe to zamieszanie wynika z mojej totalnej niewiedzy. Byłem przekonany, że WDTON jest potrzebny, by móc po resecie odczytywać bajt MCUSR - w przeciwnym razie zostaje on zerowany, a informacja tracona Teraz dopiero doczytałem, że włączenie bitu WDTON wymusza pracę watchdoga w trybie System Reset, co oznacza tyle, że uC jest resetowany z każdym przepełnieniem licznika, a przerwanie jest wyłączone. Dodatkowo nota podaje, że do poprawnej pracy uC w takim trybie konieczne jest okresowe resetowanie watchdoga i zmiana parametrów licznika (wydłużenie czasu), co podsumowane jest przykładem kodu realizującego te zadania.

Wniosek jest też taki, że informacja na stronie Atnela trochę myli.

------------------------ [ Dodano po: 28 minutach ]



Mała poprawka: wdt_reset(); - przynajmniej to się u mnie kompiluje i tak jest w wdt.h

Tam są poprawne, tylko niepełne informacje, bo nie przewidują Twojego przypadku z włączeniem watchdoga fuse bitem WDTON w tryb "always on". Dlatego należy uderzyć do Mirka by dodał w swoim bootloaderze także obsługę takiej opcji działania watchdoga.

Testowałeś czy po wprowadzeniu zaproponowanych zmian w bootloaderze działa już on z WDTON=0?

--
Pozdrawiam,
Robert

------------------------ [ Dodano po: 4 minutach ]


Tak. Zgadza się. __watchdog_reset(); pochodził z datasheeta i pewnie zaczerpnięty został z IARa.

Niestety po wprowadzeniu tych zmian nawet z WDTON=1 bootloader nie działa. W prawdzie zgłasza się prawidłowo, ale nie wczytuje wsadu - po kilku sekundach pojawia się komunikat:
Błąd podczas programowania ! err: [OK] timeout=301
Usunąłem "wdt_reset();" i nadal to samo - nawet nie próbuje wgrywać. Będę kombinował dalej.

------------------------ [ Dodano po: 7 minutach ]

Ok, już mam. Twoja propozycja ustawiała w mega1284p licznik na 2 s, zmieniłem na 8 sekund i ruszyło

------------------------ [ Dodano po: 12 minutach ]

I działa z WDTON=0

Obszedłeś problem przez zwiększenie timera. Ale porządniej oraz uniwersalnie, bo nie każdy procesor ma czasy dłuższe niż 2 sekundy (np. ATmega128 nie ma), jest poprawienie tego błędu
A można to zrobić poprzez dodanie jeszcze w jednym miejscu resetowanie timera watchdoga (wdt_reset()).
Jak na szybko przeglądałem kod by zaproponować poprawki, to nie zauważyłem jeszcze jednej długiej pętli, a że u siebie robię inaczej, to nie pomyślałem o tym.
W Mirkowym bootloaderze przed wgrywaniem nowego wsadu kasowana jest na początku cała pamięć (ja u siebie robię kasowanie tylko tej strony którą w danym momencie wgrywam). A to zajmuje kilka sekund. Dlatego trzeba jeszcze zmienić:


Możesz sprawdzić czy teraz bootloader będzie już dział poprawnie?

Ja u siebie używam timera dla wachdoga o wartości 1 sekunda (ustawiam tylko bity WDP2 i WDP1) i jest on na ATmega128 wystarczający.

--
Pozdrawiam,
Robert

------------------------ [ Dodano po: 23 minutach ]

Reset przy kasowaniu całej pamięci spowodowany był minimalnym nie zmieszczeniem się w 2 sekundach
Według datasheeta czasy wyglądają następująco:


Co przy BL od 0x1FC00 powoduje konieczność skasowania 508 stron, czyli wymaga czasu w przedziale od 1.8796 do 2.2860 sekund.

Można jeszcze przerobić poprawkę by mieć "wash and go"
Zamiast zmieniać na:

można zmienić na :

co wyłączy watchdoga, gdy nie ma go włączonego na stałe poprzez fuse bit WDTON. A dla włączonego na stałe, zmieni timer watchdoga na 2 sekundy.
Oczywiście muszą zostać dodane podawane wcześniej 2 rozkazy wdt_reset().
W sumie zmiany zwiększają rozmiar bootloadera o 2 rozkazy (4 bajty).