Jaki może być typowy mechanizm takiego uszkodzenia?
W swojej praktyce spotkałem się z tym wielokrotnie, ale zwykle świeży
firmware wgrywam przez bootloader i nie mam sposobności porównania
zawartości pamięci przed i po.
Pierwsze co mi przychodzi do głowy to uszkodzenie pamięci... ale zwykle
urządzenia po takim zabiegu działają długo bezawaryjnie, więc to nie to.
Skasowanie się samoistne pamięci (utrata ładunku, jakaś cząstka alfa?) -
no powiedzmy do dziś tak myślałem, ale zobaczyłem to:
https://youtu.be/8srxtO58RFM?t=456
Tu nie wygląda jak skasowane, tylko wręcz zapisane bzdurami.

--
Mirek.

do góry

On Sun, 24 Sep 2023 23:16:09 +0200, Mirek wrote:
> Jaki może być typowy mechanizm takiego uszkodzenia?
> W swojej praktyce spotkałem się z tym wielokrotnie, ale zwykle świeży
> firmware wgrywam przez bootloader i nie mam sposobności porównania
> zawartości pamięci przed i po.
> Pierwsze co mi przychodzi do głowy to uszkodzenie pamięci... ale zwykle
> urządzenia po takim zabiegu działają długo bezawaryjnie, więc to nie to.
> Skasowanie się samoistne pamięci (utrata ładunku, jakaś cząstka alfa?) -
> no powiedzmy do dziś tak myślałem, ale zobaczyłem to:
> https://youtu.be/8srxtO58RFM?t=456
> Tu nie wygląda jak skasowane, tylko wręcz zapisane bzdurami.

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.

do góry

On 25.09.2023 12:03, J.F wrote:

> 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.
>
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?

--
Mirek.

do góry

W dniu 06.11.2023 o 22:46, Mirek pisze:

> tylko w jednym pliku?

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


--
LordBluzg(R)??
<<<?i? ć?d?? i Putina i ęjcaredefnoK>>>

do góry

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 ).

do góry

On Mon, 6 Nov 2023 22:46:54 +0100, Mirek wrote:
> On 25.09.2023 12:03, J.F wrote:
>> 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.
>>
> 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.

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

> 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.

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 ..

> 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?

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.

do góry

W dniu 07.11.2023 o 01:26, sundayman pisze:
> 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 ).
>

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

do góry

On 7.11.2023 12:11, J.F wrote:

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

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).

> 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 :-)
>

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.


> A nie zacinał sie wczesniej?
> Moze to tak co pare dni cos zerowało.
>
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).

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

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.

--
Mirek.

do góry

W dniu 2023-11-07 o 01:26, sundayman pisze:
> 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 ).

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.

do góry