W dniu 2014-10-14 01:05, sundayman pisze:
> Zapodane na elce, powielam tutaj, licząc na życzliwąpomoc kolegów;
>
> Chodzi o atmegę128.
> Fusy 3F D4 FF (lata na kwarcu 14Mhz).
> Do tego jest bootloader 1kb na wejściu (przerobiony MCS bootloader do
> bascoma), no i sam program "główny" w bascomie.
>
> "normalna" procedura wygrywania softu jest taka:
>
> Za pomocą AVRDRAGON, spod Atmel Studio ustawiam sobie fusy.
> Następnie wgrywam plik HEX bootloadera. Wgrywa się OK, weryfikacja OK (z
> ISP clock 2Mhz) - bootloader działa poprawnie.
>
> Potem, spod bascoma , już z użyciem bootloadera, przez RS232 wgrywam
> "główny" program. No i gitara - wszystko hula.
>
> No i dalej zaczynają się cuda;
> Chciałbym zrobić sobie "zrzut" całego flasha, żeby go potem wgrywać "w
> całości".
> Zatem znowu z użyciem AVRDRAGONA odczytuję sobie zawartość flasha. Dla
> pewności z wolniejszym ISP clock - np. 250 kHz.
>
> Odczytuje się ok, zapisuje mi pliczek.
>
> Jednak próba weryfikacji już nie jest OK :
> "Verifying Flash...Failed! address=0x0000 expected=0xff actual=0x0c"
>
> Kiedy to samo robię z pamięcią EEPROM - problemu nie ma. Dane odczytane
> się poprawnie weryfikują. Nawet przy ISP clock 2 Mhz.
> Czyli nie jest to problem z programatorem raczej.
>
> Aha, oczywiście lockbity są powyłączane...
>
> Żeby było śmieszniej, to pod adresem 0x0000 POWINNO być 0C.
> Kiedy zaglądam do pilku hex - tak właśnie jest zarówno w pliku wynikowym
> z bascoma, jak i w pliku odczytanym z flasha. Oczywiście plik z "samym
> programem głównym" jest krótszy niż plik odczytany z MCU już z
> bootloaderem.
>
> Ale akurat początki są oczywiście takie same - i w obu plikach jest pod
> adresem 0000 wartość 0C.
>
> Zatem skąd on bierze to "expected=0xff" podczas weryfikacji ??

No i prawidłowo twierdzi. Ładujesz bootloader, dogrywasz bootloaderem
właściwy program. Atmel Studio weryfikuje zawartość względem samego
bootloadera. 0xff - pusty flash, 0x0c to kawałek opcodu jmp'a