Uszkodzenie firmware we flash

To nie takie calkiem bzdury - wyglada dosc regularnie, z cyklem 8 bajtow/64 bit. Fat64 chyba nie ma - a jak wygląda exFAT?

A moze jakas tabela adresow z programu/biblioteki?

Jesli ten Flash wykorzystywany jest jeszcze jako "dysk", to sprawa wydaje się prosta - dane nie trafiły tam gdzie trzeba. Przyczyny mogą być różne.

A moze to jakis Flash z naprawą błędów, i ujawniła sie tablica relokacji?

J.

W międzyczasie reanimowałem jeszcze jeden rejestrator do kamer - wg relacji świadków padł podczas burzy - z resztą nagrania to potwierdzają. Wygląda na to, że wszystko przeżyło oprócz... oprogramowania we flash. Co ciekawe raz na jakiś czas potrafił się zbootować poprawnie, ale częściej bootloader zgłaszał błąd sumy kontrolnej.

Dziś natomiast coś stało się z plikiem na karcie w Raspberry Pi - to jest taki odtwarzacz filmów, który ciągnie z ftp i odtwarza w kółko. I właśnie zaczął utykać na jednym filmie - z ciekawości porównałem ten plik z pierwowzorem i okazuje się, że niewielkie obszary są wypełnione zerami: od 1B31:2400 do 1B34:9FFF i od 1B34:A600 do 1B3A:6FFF Reszta danych jest na swoim miejscu. Plik nie ma śladu modyfikacji - data jest z marca tak samo jak pierwowzór. Reszta plików jest OK, system też cały czas działa i nic się nie sypie. Hmm... gdyby poleciał jakiś blok pamięci. to powinien być jeden ciągły obszar albo jakaś regularna sieczka w kilku plikach... ale dwa kawałki tylko w jednym pliku?

W dniu 06.11.2023 o 22:46, Mirek pisze:

Zaorać/format Nachuj ci filmy historyczne bez wskazań na właściwe?

W moich sterownikach, pracujących polowo zazwyczaj zasilanych z paneli pv ( atmega 2561 ) pada czasem firmware w sytuacjach częstego załączenia/wyłączenia na skutek zanikania i pojawiania się zasilania właśnie ( zimą zazwyczaj, jak się akumulatory nie ładują dostatecznie ).

Przy czym zazwyczaj nie są to wielkie awarie pamięci, tylko pojedyncze błędy we flashu wyłapywane przez CRC przy automatycznych restartach, które są co parę godzin. W 90% przypadków wgranie poprawnego firmware stawia urządzenie na lata.

W ogóle takich przypadków miałem kilka na kilkaset urządzeń.

Raz mi się to zdarzyło po uderzeniu pioruna w pobliżu ( jakieś 50m ).

W czasie burzy wszystko może sie zdarzyć :-)

Rozumiem, ze plik był dobry, i nie jest to wina FTP?

Skasowana karta ma raczej FF, wygląda to na celowy zapis zer przez system. Tzn celowy z punktu widzenia karty, a nie całości systemu. Coś sie temu linuxu pomyliło i zapisał nie tam, gdzie trzeba :-)

Hm, a czy możliwe, ze np karta postanowiła przepisac/przeniesc blok danych, i urwało sie gdzies w połowie? Ae znów - to chyba nie zera powinny nbyć w reszcie ..

A nie zacinał sie wczesniej? Moze to tak co pare dni cos zerowało.

Były inne odtwarzane pliki, czy tylko ten jeden w kólko ?

J.

W dniu 07.11.2023 o 01:26, sundayman pisze:

Ja takie zaniki miałem w przypadku MSP430F169. Po X cyklach on/off w postaci odłączania kabla zasilającego - firmware przestawał się podnosić.

W firmwarze nie było ani jednego zapisu do flasha jako pamięci danych a mimo to coś tam znikało czasem.

Po ponownym zaprogramowaniu - problem znikał.

Zgrany firmware miał czasem bzdury, czasem 0xff.

Nie znalazłem na to wtedy żadnego rozwiązania.

Pozdrawiam

Adam Górski

Plik był dobry - w sensie z dziurami ale normalnie go zgrałem przez scp z Raspberry. Na ftp była dobra wersja (bez dziur z zerami).

To działa tak, że skrypt łączy się z ftp raz na dobę i porównuje katalogi: to co ma - nie rusza, to czego nie ma - sciąga, to co ma, a nie ma już na ftp - usuwa. Ten plik był dosyć stary (jeden z najstarszych - z marca), data modyfikacji jest zgodna.

Nie, nic się nie działo. Dostałem telefon, że nie działa, a po probie resetu zatrzymał się dokładnie w tym samym miejscu (stopklatka).

Są oczywiście inne i działają. Tamten plik po zgraniu i potwierdzeniu, że jest uszkodzony po prostu usunąłem - zaciągnął się od nowa i jak na razie działa.

W dniu 2023-11-07 o 01:26, sundayman pisze:

Kiedyś dawno (ubiegły wiek) zauważyliśmy, że procesor nie zawsze dobrze się resetuje przy włączaniu napięcia. Włączanie było poprzez złapanie chwytakiem za drucik. Nie mieliśmy możliwości dokładne3go obejrzenia co się dzieje z napięciem w momencie włączania. Nasza hipoteza była, że chwytak na chwilę podłącza napięcie - procesor zaczyna pracować a potem jest chwilowa przerwa na tyle długa, że napięcie na kondensatorze spadnie tak, że procek głupieje ale nie na tyle aby układ resetu ponownie zrobił mu reset i jak napięcie już się ustabilizuje prawidłowe to on nie mając resetu robi nie wiadomo co. Wtedy modyfikacja firmware nie była w zasięgu tego procka, ale gdyby była to może po takim zgłupieniu firmware byłby przez procek uszkadzany.

Odkryliśmy w ten sposób potrzebę układów brown-out i po dołożeniu takiego scalaka problem całkowicie zniknął.

Praktycznie każdy włącznik ma jakieś drgania styków. Jak włączanie/wyłączanie prowadzi do jakichś problemów to najpierw bym podejrzewał źle ustawiony brown-out. Jak procesor zgłupieje, a ma hardwareową możliwość modyfikowania firmware to nie można wykluczyć, że czegoś tam nie namiesza. P.G.