W dniu 2023-02-16 o 13:54, heby pisze:
>> Już opanował wywoływanie funkcji po jej skopiowaniu do RAMu.
>
> Czytaj wątek z przed paru dni:
>
> "MCU - start programu z RAM"

Przesłałem bratu (on nie czyta Usenetu) wszystkie wiadomości z tamtego
wątku.
W czasie jak pisałem dalszą część tej wiadomości wstępnie powiedział, że
według niego nie ma tam tego co on szuka. Ale rozmawialiśmy tylko
zgrubnie (ja siedzę w swoim pokoju a on piętro niżej). Coś mówił o
sekcjach, ale że to... coś tam (nie dosłyszałem).
Też rzucę okiem, tylko, że tak właściwie nie mam na to czasu.

> Było to omawiane w tym wątku. Ogólnie, jesli ma to związek z
> programowaniem flasha, to boje się zapytać, czy jakoś się zabezpieczacie
> prze utratą zasilania w trakcie.

Chyba powinien się obrazić :)

Napisałeś tak, jakby przeprogramowywanie flasha było jakąś nadzwyczajną
czynnością, a to przecież chyba wszyscy robią.
Są jeszcze jakieś urządzenia bez upgrade?
Do tej pory używaliśmy AtXmega z EEROMem na pokładzie. O ile się
zorientowaliśmy to w ARM (które chyba dużo ludzi używa) EEPROM to jakaś
egzotyka. Stosowana jest emulacja EEPROM we flashu więc wszyscy, którzy
chcą EEPROMu wewnątrz procka muszą programować Flasha.

Od czasu jak tylko przenieśliśmy się z procesorów OTP na flash (jak
pojawiły się pierwsze Atmele) jesteśmy moim zdaniem dobrze zabezpieczeni.

Pierwsza linia obrony:
Nasze urządzenia zasilane są z zasilaczy z podtrzymaniem bateryjnym
(starczającym na kilka godzin). Dopóki nie ma tak długich przerw w
zasilaniu to zanik napięcia zasilania urządzenia praktycznie nie zdarza
się przez lata.

Druga linia obrony:
Jest czujnik napięcia na elektrolicie przed stabilizatorem VCC.
Od przerwania z tego czujnika do choćby drgnięcia w dół napięcia VCC
mija więcej czasu niż flash potrzebuje na dokończenie rozpoczętego
procesu programowania, czy kasowania strony - czyli (pod warunkiem, że
procesor po tym przerwaniu wyłączy wszelkie zbędne obciążenia) każda
rozpoczęta operacja na flashu zostanie dokończona w komfortowych
warunkach. Oczywiście po tym NMI następna operacja nie zostanie rozpoczęta.
To zabezpieczenie występuje tylko w urządzeniach, które przechowują we
flashu jakieś dane. Na przykład nie ma go w czytnikach RFID. Tam
uważamy, że pozostałe zabezpieczenia wystarczą bo tam chodzi tylko o
upgrade, a on się skutecznie broni sam.

Trzecia linia obrony:
Brown-out, który zadziała po tym wszystkim zabezpiecza przed zgłupieniem
procesora, który mógłby wtedy coś nabruździć we flashu.

Różne inne zabezpieczenia, którym trudno nadać kolejne numery:
- ważne informacje we flashu mają sumy kontrolne. Po resecie procesor je
sprawdza. Jak się nie zgadza to przyjmuje bezpieczne wartości default.
- informacja o każdym resecie trafia do rejestracji i serwer może po
resecie skontrolować całą zawartość urządzenia.
- produkujemy urządzenia przez 'upgrade' z programu testowego to
oznacza, że w każdym urządzeniu są praktycznie dwie kopie programu.
- po resecie bootloader sprawdza crc32 programu i jak jest błędne to
sprawdza crc32 upgrade'u i ewentualnie wykonuje upgrade.
- przesyłanie upgrade'u nie niszczy programu (on nadal normalnie działa)
więc przerwanie przesyłania upgrade'u w dowolnym momencie nie jest
problemem,
- dopiero jak przyjdą wszystkie strony upgrade'u jest sprawdzany jego
podpis i upgrade jest wykonywany - zakładamy, że jakby upgrade został
przerwany w tym trakcie to po resecie crc32 to wykryje i upgrade
rozpocznie się od nowa (nie przesyłanie a wykonywanie).

Dotychczas nie zauważyliśmy problemu, którego źródłem byłoby
niedokończenie zapisu flasha.
P.G.