Używam popularnego procesora 328P. Próbowałem zabezpieczyć procesor (używając MKAVRKalkulator) czyli zmienić wartość LockBit z HFF na HC0 a tu wpisało się H33 czyli procesor stoi praktycznie otworem. O co chodzi? Błąd czy celowe działanie? Jakie? Dla mnie zabezpieczenie to ma być zabezpieczenie.

A czy przy odczycie zaznaczasz Lock bity?

z Niebieskim pozdRowieniem,
Doman89

Robię zapis, weryfikację i następnie blokadę. Ma być wpisane HC0 a kalkulator wylicza mi wartość H33 i taką usiłuje wpisać. Przecież nie o to chodzi.

Ok robisz zapis i wpisuje Ci Twoją wartość.

Ale jak sprawdzasz czy dobrze się zapisały?

Odczyt z zaptaszkowanym Lock bity? Czy tylko klikasz Sprawdź podłączony AVR?

z Niebieskim pozdRowieniem,
Doman89

Z tego co wiem, to wartość H3C zabezpiecza wsad w układzie przed odczytywaniem.

_________________
http://leszczamiga.ppa.pl/

Poczytałem od nowa nt. lock bitów, pobawiłem się programem i dopiero teraz mam problem. Do czasu objaśnienia przez kolegę Mirka odwieszam MKkalkulator na kołek. A szkoda bo taki zgrabny użyteczny program.

Panie Mirku, jak to właściwie jest z tymi LockBitami i kalkulatorem bo nadal mam wątpliwości.

Odpowiem krótko - na takie pytania nie udzielam odpowiedzi ... i nie włączam się do dyskusji. Proponuję przy takim podejściu zrobić to:


to będzie najlepsze wyjście - i skorzystanie z tylu innych programów - jest ich pełno na świecie. Polecam np program "Pony Prog".

_________________
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 co te nerwy? Przecież mam wielki szacunek dla Pana i tego co Pan robi. Przy każdej okazji staram się to podkreślać. Nie chce mi się szukać cytatu, ale było wyraźnie powiedziane, że w przypadku wątpliwości proszę pytać. My tu na forum wyjaśnimy. No więc mam wątpliwości i pytam. Nie do konca zgadzają mi się LockBity z Kalkulatora i Karty katalogowej. Może jest w tym jakiś zamysł, którego nie rozumiem. Proszę o spokojne wyjaśnienie sprawy.
Pozdrawiam i pozostaje z najwyższym szacunkiem.
Zenowi

ok załóżmy, że źle zrozumiałem intencje ... (być może - to przepraszam)

więc tak .... na początek kwestia dwóch najstarszych bitów .... to nie jest kwestia MkAvrCalculatora tylko AVRDUDE. Dwa najstarsze bity w całym bajcie Lockbitów są nie używane - co widać w nocie PDF (dla tego procka) więc czy będziemy widzieli w pierwszej STARSZEJ połówce tego bajtu wartość

3

czy

F

to nie ma znaczenia ok ? zatem jeśli chcesz ustawić wartość na FF to nie ma co się dziwić że MkAvrCalc pokazuje nagle

3x

zamiast

Fx

podobnie z wartością C0 .... zamieni się ona na

0x

tyle że tak by było gdyby się chciało ustawić jedno PODSTAWOWE zabezpieczenie :



i zapewniam cię, że jeśli nie korzystasz z rozbudowanego BOOTLOADERA w procku, który ma możliwości odczytywania na żądanie zarówno pamięci FLASH jak i EEPROM i to jeszcze spod wskazanych przez załóżmy operatora adresów konkretnych - to TO żadna inna z tych widocznych opcji jest niepotrzebna ....

dlatego REASUMUJĄC, jeśli potrzebne jest tobie ustawienie 0xC0 to spokojnie możesz ustawić 0x00 co oznacza, że zerujesz (ustawiasz) WSZYSTKIE możliwe bity zabezpieczeń i to działa przecież, tylko mówię wpisz tam 00 zamiast C0


ale ok ... to nie o to chodzi przecież żeby nie można było skorzystać z innych opcji wg uznania .... tylko że ... jak widać ani ja nie używałem tych opcji ani chyba dotąd nikt inny .... więc wcześniej nie odkryłem że jest jednak pewien błąd .... tyle że on ujawnia się w momencie gdy chcemy ręcznie ustawić wszystkie zabezpieczenia z tych rozwijanych pól myszką a nie ręcznie wpisując na górze wartość.

Wtedy niestety dziwnie zmieniają się te wartości Lockbitu - coś jest nie tak w moim programie i muszę to poprawić. Zauważyłem to można powiedzieć teraz ... I mam to wpisane na listę JAK NAJSZYBSZYCH poprawek.

----------------------------------------------------------

PODSUMOWUJĄC ostatecznie - to co chcesz uzyskać da radę zrobić w tej wersji tylko zamiast C0 wpisz 00 i taką też później po odczycie zobaczysz wartość. Tylko nie stosuj wtedy tych dwóch rozwijanych pól na dole.

To górne zawsze zadziała dobrze i też w pełni zabezpieczy procka jak pisałem na początku

Oczywiście gdyby coś jeszcze było niejasne z tego co napisałem to pytaj dalej .... jestem teraz w pracy i być może troszkę to chaotycznie opisałem za co przepraszam

_________________
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 ]

W uzupełnieniu:
Jednak Atmel wyraźnie zaleca 0xC0, bo (z atmelowego pedeefa):
For future compatibility it is also recommended to set bits 7 and 6 in R0 to “1” when writing the Lock bits Flash corruption can easily be avoided by following these design recommendations (one is sufficient):
1. If there is no need for a Boot Loader update in the system, program the Boot Loader Lock bits to prevent any Boot Loader software updates.

Ja się do tego odniosę tak jak mogę najlepiej:

1. to nie mój wymysł tylko twórców AVRDUDE
2. MkAvrCalculator to tylko nakładka na AVRDUDE
3. jeszcze nigdy w życiu się nie spotkałem żeby było coś nie tak używając AVRDUDE i Lockbitów a no hmmm nie chodzi o to żebym patrzył przez czubek własnego nosa i mówił że jak u mnie działa to u wszystkich też musi działać nie mniej jednak przepuściłem już setki i to różnych procków w których zabezpieczałem je przed odczytem Lockitami NO PROBLEMS

zresztą nawet nie chce mi się wnikać jak robi to AVRDUDE - bo to że np podaje userowi informacje że w tych bitach są zera to wcale nie oznacza że przy zapisie nie stosuje jedynek - nie wiem i szczerze mówiąc nawet nie za bardzo chce mi się już dalej w to wnikać. A można to zrobić spokojnie we własnym zakresie - tylko trzeba prześledzić sobie źródła AVRDUDE bo są otwarte

jako ciekawostkę podam że np w samym AVRDUDE są też pewne nieścisłości właśnie w podejściu do wizualizacji nieużywanych bitów i to nie tylko w Lockbitach ale także w Fusebitach. Prosty przykład:

dla procka ATmega8 można w AVRDUDE zrobić sobie VERIFY przy zapisie fusebitów i jest wszystko OK

ale już dla procka

ATmega88/168/328 przy próbie weryfikacji wyskakuje info że się coś nie zgadza - ło matko! sobie kiedyś pomyślałem czyżby coś było skopane w AVRDUDE ? ... zmuszony byłem to przeanalizować dogłębnie i okazało się (tak mi się wydaje) że np definicje procków robili różni ludzie w całym zespole tworzącym AVRDUDE. I jedni właśnie uznali żeby prezentować nieużywane bity jako zera a inni jako jedynki. Co gorsze - domyślnie zdaje się z tego co pamiętam - AVRDUDE traktuje tak jak atmel że powinny być zdaje się jedynki, ale ktoś kto robił definicje dla niektórych procków w pliku config podał to jako zera i wtedy przez to sam avedude głupieje czasem aby to obejść wystarczy WYŁĄCZYĆ werfyfikację fusebitów (głównie chodzi o fusebit EXTENDED) i wtedy wszystko śmiga dobrze - tzn avrdude nie "brzęczy" że coś jest nie tak po weryfikacji

owszem osoby, które patrzą w to napisał Atmel i są niepewne jak działa avrdude i boją się o swoje procki - po prostu mogą z niego nie korzystać. Ja korzystam i polecam bo pomimo takich małych niedociągnięć to bardzo fajny program ze sporymi możliwościami

mam nadzieję , że teraz już WSZYSTKO kompleksowo wyjaśniłem

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



Ze tego jasno wynika że WSZYSTKO zależy kto robi i jak projekt i ile daje możliwości i komu - to jest temat TAK rozległy - że próba toczenia sporu na tak wysokim poziomie abstrakcji bez odniesienia się już do super konkretnego przykładu NIC NIKOMU NIE DA I NIE WYJAŚNI

_________________
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 ]