Ne znam, mislim da mi promaklo nesto usljed brisanja. Ali vezano, za post o booloader-u. Nisam upucen, tako da neznam jel to kod atmelovog bl-a bila greska ili je jednostavno bio tako koncipiran. Ako je bio tako koncipiran onda je greska jedino u tome sto atmel nije upozorio da je wdt omogucen i da cucka treba udarati u korisnickom softveru ili ga onemoguciti ako je to moguce (kod PIC16 ne, kod PIC18 da, AVR ?).
Mislim da spomenuti atmel kontroler ima drugcije koncipiran bl od onog sto smo ja/mi navikli na PIC-u: bl pocinje na adresi 0x000 i od tamo obicno skace na kraj memorije. Znaci, po resetu uvijek u bl, pa u user app. Bulk Erase kontrolera brise i bl naravno. Imam dojam da za atmelov kontroler to radi na malo drugcijem principu, ali ovo je za drugu raspravu u nekom drugom podforumu (AVR mi pada na pamet).
Tvorci bl-a isticu da neki registri po ulasku u user app nece imati defaultno stanje nakon reseta (skroz jasno). U tom slucaju 100% posto se slazem s tobom/vama, incicijalizacija je obavezna.
Drago mi je da si spomenuo bl, jer on definitivno dovodi u pitanje "nepostojecu rutinu". Jer sada uz to sto ne mozes skociti na adresu 0x000 od bilo kuda (PIC16), ne mozes i bilo kuda. Obazlozenje: Na to nekoj adresi se mogu nalaziti ostaci neke predhodne "overvrajtane" aplikacije. Kod PIC-a bl brise samo "sektor" koji namjerava reprogramirati.
Nisi me ulovio. To je bilo retoricko pitanje, a fraza "Il' si mrtav il' si nisi mrtav." je trebala docarati moj sarkazam. Ispricavat se ne mislim.Samo me pitao razlog zbog kojeg na adesi 0 postoji rušenje HEX-a i preživljavanje HEX-a...
Ali evo jedno normalno pitanje.
HARD RESET termin, na sto se tocno odnosi? Zanima me cisto radi povlacenja paralela s PIC-om. Kod njega reset na pin, por, bor, wdt reset, (instrukcijski, stack overflow/underflow kod PIC18 serije) imaju isti efekt ne racunajuci eventulana kasnjenja (PowerUp Timer kod POR-a za primjer).