ATNEL tech-forum

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-12-18T02:35:48+01:00

Można jeszcze przerobić poprawkę by mieć "wash and go"
Zamiast zmieniać na:
[syntax=c]_WD_CONTROL_REG = (1 << _WD_CHANGE_BIT) | (1 << WDE);
_WD_CONTROL_REG = (1 << WDP2) | (1 << WDP1) | (1 << WDP0) | (1 << WDE);[/syntax]
można zmienić na :
[syntax=c]_WD_CONTROL_REG = (1 << _WD_CHANGE_BIT) | (1 << WDE);
_WD_CONTROL_REG = (1 << WDP2) | (1 << WDP1) | (1 << WDP0);[/syntax]
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).

Statystyki: Napisane przez rskup — 18 gru 2015, o 02:35

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-12-18T01:33:58+01:00

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ć:
[syntax=c]/* kasowanie całej pamięci programu */
for ( uint32_t Page_Address = 0; Page_Address < BLS_START;
Page_Address += SPM_PAGESIZE )
{
wdt_reset();
/* skasowanie strony pamięci */
boot_page_erase( Page_Address );
boot_spm_busy_wait();
}[/syntax]

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.

Statystyki: Napisane przez rskup — 18 gru 2015, o 01:33

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-12-18T00:03:38+01:00

rskup napisał(a):

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

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

Statystyki: Napisane przez new_old_man — 18 gru 2015, o 00:03

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-12-17T23:41:06+01:00

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 ]

Quote:

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

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

Statystyki: Napisane przez rskup — 17 gru 2015, o 23:41

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-12-17T23:02:43+01:00

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 ]

rskup napisał(a):

2. dodanie resetowania timera watchdoga __watchdog_reset();

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

Statystyki: Napisane przez new_old_man — 17 gru 2015, o 23:02

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-12-17T23:46:12+01:00

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):
[syntax=c]_WD_CONTROL_REG = (1 << _WD_CHANGE_BIT) | (1 << WDE);
_WD_CONTROL_REG = (1 << WDP2) | (1 << WDP1) | (1 << WDP0) | (1 << WDE);[/syntax]

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 ):
[syntax=c]do
{
wdt_reset();
if ( UCSRA & 1 << RXC )[/syntax]

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

Statystyki: Napisane przez rskup — 17 gru 2015, o 15:33

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-12-17T12:54:56+01:00

rskup napisał(a):

Quote:

Brak bootloadera; WDTON=0 - reset programowy działa prawidłowo.

A czy w programie nie masz cyklicznego zerowania watchdoga i dzięki temu działa?

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.

Statystyki: Napisane przez new_old_man — 17 gru 2015, o 12:54

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-12-16T21:56:43+01:00

Quote:

Brak bootloadera; WDTON=0 - reset programowy działa prawidłowo.

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

Statystyki: Napisane przez rskup — 16 gru 2015, o 21:56

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-12-16T19:26:44+01:00

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

new_old_man napisał(a):

1. Brak bootloadera; WDTON=1 - reset programowy* działa prawidłowo.
2. Brak bootloadera; WDTON=0 - reset programowy działa prawidłowo.

Na początku programu robię to:

[syntax=c]void watchdog_get_mcusr(void)
{
mcusr_mirror = MCUSR;
MCUSR = 0;
wdt_disable();
}[/syntax]
Więc jednak programowo da się wyłączyć watchdog mimo ustawionego bitu WDTON.

Statystyki: Napisane przez new_old_man — 16 gru 2015, o 19:26

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-12-16T14:48:14+01:00

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

Statystyki: Napisane przez rskup — 16 gru 2015, o 14:48

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-12-16T13:50:10+01:00

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

[syntax=asm]0001fc38 <__init3>:
static void __init3(void)
{
/* wyłączenie watchdoga (w tych mikrokontrolerach, w których watchdog
* ma możliwość generowania przerwania pozostaje on też aktywny po
* resecie) */
MCUSR = 0;
1fc38:14 be out0x34, r1; 52
_WD_CONTROL_REG = 1 << _WD_CHANGE_BIT | 1 << WDE;
1fc3a:e0 e6 ldir30, 0x60; 96
1fc3c:f0 e0 ldir31, 0x00; 0
1fc3e:88 e1 ldir24, 0x18; 24
1fc40:80 83 stZ, r24
_WD_CONTROL_REG = 0;
1fc42:10 82 stZ, r1[/syntax]
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?

Statystyki: Napisane przez new_old_man — 16 gru 2015, o 13:50

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-12-16T10:49:33+01:00

Quote:

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.

Statystyki: Napisane przez new_old_man — 16 gru 2015, o 10:49

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-12-15T23:43:20+01:00

Quote:

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

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 ]

Quote:

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

Według mnie to lss powinien zostać u Ciebie utworzony. Makefile od mkBootloader ma zapisy by go tworzyć:
[syntax=c]# Default target.
all: begin sizebefore build sizeafter end

# Change the build target to build a HEX file or a library.
build: elf hex lss sym
#build: lib

burn: fuse program lock

elf: $(TARGET).elf
hex: $(TARGET).hex
lss: $(TARGET).lss

...

# Create extended listing file from ELF output file.
%.lss: %.elf
@echo
@echo Creating Extended Listing: $@
$(OBJDUMP) -h -S -z $< > $@[/syntax]

Statystyki: Napisane przez rskup — 15 gru 2015, o 23:43

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-12-15T22:46:49+01:00

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:

[syntax=asm]145 /* epilogue start */
231:main.c **** #define WDIF
146 .loc 1 231 0
147 /* #NOAPP */
148 .cfi_endproc
149 .LFE8:
151 .section.init3,"ax",@progbits
153 __init3:
154 .LFB9:
240:main.c **** /* wy31czenie watchdoga (w tych mikrokontrolerach, w których watchdog
155 .loc 1 240 0
156 .cfi_startproc
157 /* prologue: naked */
158 /* frame size = 0 */
159 /* stack size = 0 */
160 .L__stack_usage = 0
244:main.c **** _WD_CONTROL_REG = 1 << _WD_CHANGE_BIT | 1 << WDE;
161 .loc 1 244 0
162 0000 14BE out 0x34,__zero_reg__
245:main.c **** _WD_CONTROL_REG = 0;
163 .loc 1 245 0
164 0002 E0E6 ldi r30,lo8(96)
165 0004 F0E0 ldi r31,0
166 0006 88E1 ldi r24,lo8(24)
167 0008 8083 st Z,r24
246:main.c **** }
168 .loc 1 246 0
169 000a 1082 st Z,__zero_reg__
170 /* epilogue start */
247:main.c **** #endif[/syntax]

Statystyki: Napisane przez new_old_man — 15 gru 2015, o 22:46

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-12-15T22:34:48+01:00

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

--
Pozdrawiam,
Robert

Statystyki: Napisane przez rskup — 15 gru 2015, o 22:34

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-12-15T22:27:09+01:00

rskup napisał(a):

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:
[syntax=c]{
wdt_enable(WDTO_15MS); // set watchdog
cli(); // disable interrupts
while(1); // wait for RESET
}[/syntax]

Statystyki: Napisane przez new_old_man — 15 gru 2015, o 22:27

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-12-15T18:18:10+01:00

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.

Statystyki: Napisane przez rskup — 15 gru 2015, o 18:18

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-12-15T17:34:53+01:00

rskup napisał(a):

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.

Statystyki: Napisane przez new_old_man — 15 gru 2015, o 17:34

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-12-15T11:40:53+01:00

Statystyki: Napisane przez rskup — 15 gru 2015, o 11:40

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-12-14T23:04:13+01:00

Grzegorz... napisał(a):

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.

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:

[syntax=c]#define WDIF /* dla pewnosci */

#ifdef WDIF
static void __init3(void) __attribute__ ((section(".init3"), naked, used));
static void __init3(void)
{
/* wy³¹czenie watchdoga (w tych mikrokontrolerach, w których watchdog
* ma mo¿liwoæ generowania przerwania pozostaje on te¿ aktywny po
* resecie) */
MCUSR = 0;
_WD_CONTROL_REG = 1 << _WD_CHANGE_BIT | 1 << WDE;
_WD_CONTROL_REG = 0;
}
#endif[/syntax]
który teoretycznie powinien mi wyłączać watchdoga jeszcze przed programem. Nie wiem, co jest grane.

Statystyki: Napisane przez new_old_man — 14 gru 2015, o 23:04

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-11-16T22:26:38+01:00

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...

Statystyki: Napisane przez Grzegorz... — 16 lis 2015, o 22:26

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-11-15T15:52:30+01:00

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:

rskup napisał(a):

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ć.

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;)

Statystyki: Napisane przez new_old_man — 15 lis 2015, o 15:52

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-11-15T13:09:12+01:00

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

Quote:

Bit 7 - WDIF: Watchdog Interrupt Flag
This bit is set when a time-out occurs in the Watchdog Timer and the Watchdog Timer is configured for interrupt. WDIF is cleared by hardware when executing the corresponding interrupt handling vector. Alternatively, WDIF is cleared by writing a logic one to the flag. When the I-bit in SREG and WDIE are set, the Watchdog Time-out Interrupt is executed.

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:

Quote:

To make use of the Reset Flags to identify a reset condition, the user should read and then Reset the MCUSR as early as possible in the program. If the register is cleared before another reset occurs, the source of the reset can be found by examining the Reset Flags.

--
Pozdrawiam,
Robert

Statystyki: Napisane przez rskup — 15 lis 2015, o 13:09

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-11-15T07:54:27+01:00

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?

Statystyki: Napisane przez new_old_man — 15 lis 2015, o 07:54

Re: Odczyt MCUSR, a bootloader - coś się gryzie:/

2015-11-15T00:33:30+01:00

new_old_man napisał(a):

Potrzebuje wiedzieć czy Mirkowy bootloader zeruje MCUSR

Oczywiście, że zeruje

new_old_man napisał(a):

to czy można to wyłączyć i jak.

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

Statystyki: Napisane przez mirekk36 — 15 lis 2015, o 00:33