logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Test pamieci SRAM i EEPROM w AVR.

anacocito 04 Gru 2010 18:51 6556 38
  • #1 8825565
    anacocito
    Poziom 10  
    Witam,

    Czy ktoś próbował programowo testować testować pamieć SRAM w AVRach? Założenie jest takie ze przy re/starcie uP wykonuje test pamięci programu (suma kontrolna crc), test EEPROM i SRAM (coś na kształt POST). Czy znacie jakieś sposoby na przeprowadzenie takich testów(EEPROM i SRAM) dedykowane dla uP? Ze stron traktujących o testach RAM w PC zaczerpnąłem pomysł żeby najpierw zapisać SRAM samymi zerami następnie odczytać i sprawdzić czy odczytane zostały same 0, w ten sam sposób z 1, oraz zapisać do każdej komórki pamięci jej adres następnie jej odczytać i porównać. Nie wiem czy test EEPROM podobnym sposobem jest dobrym rozwiązaniem, czy stosować sumę CRC czy coś innego. Nie proszę tu o kod programu tylko o samą ideę w jaki sposób można do tego problemu podejść i o wskazówki na co zwrócić uwagę. Na forum nie znalazłem podobnego tematu.

    Pozdrawiam.
  • #2 8825723
    mirekk36
    Poziom 42  
    anacocito napisał:
    Na forum nie znalazłem podobnego tematu.


    No trochę się nie dziwię, że nie znalazłeś za to bardzo się dziwię po co to? tylko tak dla IDEI ??? czy o co chodzi??? (tak z czystej ciekawości pytam)

    W PC to można wymienić RAM gdy jest uszkodzony - a w procku ??? chyba coś "nieteges" - podobnie EEPROM. Uszkodzenie RAM o ile coś takiego następuje w ogóle jednoznacznie dyskfalifikuje procka a każdorazowe testowanie przy starcie wydaje się być hmmm jakby bez sensu ... ale może czegoś nie wiem , tzn jaki tobie tu cel przyświeca.
  • #3 8825839
    bolek
    Poziom 35  
    Podtekst pachnie też sprawdzaniem poprawności danych w tej pamięci. Fakt faktem, testowanie RAMu w procku jest przynajmniej bezcelowe. Chyba że pracuje to na orbicie i ciężko pamięć wymienić.
    Możliwości sprawdzenia jest wiele. Najprościej to chyba dodać do siebie wszystkie użyte komórki i wynik porównać z osobno zapisaną wartością (np ich suma obliczona przy zapisie strony). Trzeba się jeszcze zabezpieczyć na wypadek odczytania zera lub samych jedynek.
  • #4 8825993
    Konto nie istnieje
    Konto nie istnieje  
  • #5 8826044
    anacocito
    Poziom 10  
    "W PC to można wymienić RAM gdy jest uszkodzony - a w procku ???" Wymienić nie można ale można sprawdzić czy RAM nie jest uszkodzony i czy nie bierze lub nie zapisuje jakichś śmieci i to mnie interesuje. Nie pytam tylko dla idei ale to do czego potrzebuje tej informacji nie ma znaczenia, potrzebuje zrobić komparator bezpieczny dla systemów srk i uznałem ze test integralności danych programu, i pamięci jest dobrym pomysłem. I dlatego pytam czy ktoś ma doświadczenie z tymi zagadnieniami i w jaki sposób sprawdzić te pamięci. "Najprościej to chyba dodać do siebie wszystkie użyte komórki i wynik porównać z osobno zapisaną wartością (np ich suma obliczona przy zapisie strony)" Jak rozumiem to tyczy się EEPROM?
  • #6 8826458
    bolek
    Poziom 35  
    Tak, tyczy się te eeproma i prawdziwości jego danych. Co do ramu to tak jak Mirek wspomniał- testujesz zapisz każdego bitu. Dawno temu takie bajery się robiło z egzotycznymi kostkami wydobytymi z czegoś (dodatkowa pamięć), w tedy bardziej opłacało się zaznaczyć jakiś adres jako martwy. Dziś...
  • #8 8826532
    bolek
    Poziom 35  
    Zrobi co uważa. Choć test danych w eep nie uważam za bezsensowny, a wręcz za niezbędny.
  • #9 8826620
    mirekk36
    Poziom 42  
    xury napisał:
    Idąc dalej tym torem to nalałoby testować jeszcze rejestry i porty I/O.


    hyhyhy o! tu kolega słusznie zwrócił uwagę ;) ... jak robić test integralności w czymś co jest tak zintegrowane jak mikrokontroler to od razu portów I/O no bo przecież one znajdują się w obszarze adresowym RAM :)
  • #11 8826666
    mirekk36
    Poziom 42  
    Żabek napisał:
    Nawet jeśli test SRAMu z dużym przymrużeniem oka ma jakiś głębszy sens, to taki test EEPROMu już sensu pozbawiony jest zupełnie.
    1. W EEPROMie przechowuje się dane konfiguracyjne, jakieś flagi, ustawienia, kalibracje itp a testując je przez zapis czegokolwiek innego na zawsze wymaże te dane z pamięci;

    Nie nu to troszkę za daleko posunięty wniosek bo przecież można skopiować badaną część do bufora w RAM (o ile oczywiście wcześniej okazało się, że jest sprawny naturalnie bo inaczej .... hmmm właśnie co ...) .... no ale wtedy zbadać poprzez zapisy i odczyty do i z EEPROM czy i on zachowuje pełną integralność prawda no i ...


    Żabek napisał:
    2. EEPROM ma ograniczoną ilość zapisów a tak traktując tą pamięć zaorasz ją bardzo szybko... No chyba, że budujesz urządzenie komercyjne z gwarancją 1 rok a pamięć ma paść po 1 roku i 1 dniu ;)
    Dla EEPROMu jak coś to bajery na kształt CRC, CRC16, coś na kształt MD5, test SRAMu zupełnie bezcelowy bo jego uszkodzenie==uszkodzenie uC.


    .... no i tu ZUPEŁNA RACJA ... - można tylko po co ?

    Bo bez EEPROM już procek może działać tylko co ??? jak się okaże, że uszkodzony to w cudowny sposób dokleimy na pająka zewnętrzną pamięć EEPROM przeprogramowując procka żeby teraz z niej korzystał ??? to jakiś absurd - to już lepiej od początku założyć że będziemy korzystali z zewnętrznego EEPROM ... a jak się nadal tak strasznie boimy o integralność zewnętrznego EEPROM'a to może jakiś bardziej niezawodny FRAM ???? ..... w takim przypadku już się o wiele trudniej je "zajeździ" ciągłymi prawda testami integralności bo i ilość cykli jak ktoś sobie porówna z EEPROM jest o kilka rzędów większa. A EEPROM jak pisze kolega wyżej już po roku jak nie wcześniej lub troszkę później dostanie "w łeb" po takich "cudownych" testach. A testowanie EEPROM bez pełnych cykli zapis/odczyt to już byłaby totalna parodia.

    Dodano po 2 [minuty]:

    xury napisał:
    No i następne pytanie - jak przetestować obszar pamięci na stos ? Przecież jak coś tam zapiszemy to tester pójdzie w maliny :)


    To akurat dałoby radę zrobić bez najmniejszego problemu gdyby się uprzeć dla tej IDEI, bo po restarcie gdy na stos jeszcze nic nie zostało odłożone można spokojnie w prostej pętli dokonać testu całej pamięci RAM wymazując i kasując ją doszczętnie - tylko bez stosowania poleceń, które odkładają coś na stosie czyli bez żadnych skoków typu call, przerwań itp.
  • #12 8826682
    gaskoin
    Poziom 38  
    POST w przypadku µC jest o tyle bez sensu, że na płycie głównej komputera PC masz jednostkę, która ten test przeprowadza, ale ona sama nie jest w stanie przeprowadzić testu samego siebie. Jak nie działa, to nie działa nic. Do AVR musiałbyś podpiąć urządzenie zewnętrzne, które stwierdzi poprawność działania samego AVR (chociaż nie mam pomysłu niby jak by się to miało odbywać). No i drugi problem to taki, że w komputerze PC nie ma mikrokontrolera w którym wszystko jest upakowane w jedną kość, tylko peryferia stanowią odrębne jednostki, które przetestować jest łatwo.
  • #13 8826730
    Konto nie istnieje
    Konto nie istnieje  
  • #14 8826867
    tmf
    VIP Zasłużony dla elektroda
    IMHO testy pamięci EEPROM są bez sensu. Można co najwyżej sprawdzać integralność zapisanych w niej danych, ale to nie to samo. A bezsens testowania EEPROM wynika z fizyki jej uszkodzeń.
    Co do SRAM - szansa na jej uszkodzenie jest podobna jak szansa uszkodzenia innych bloków procesora, co czyni ten test raczej bezsensownym. Same rejestry procesora są fizycznie realizowane jako pamięć SRAM, więc jak tu przeprowadzać test? Aby coś takiego było wiarygodne, procesor musiałby najpierw realizować jakiś algorytm wykorzystujący jego różne bloki funkcyjne, wystawiać wynik na jakimś porcie, gdzie inny układ uzyskane wektory testowe porównywałby z wzorcowymi i decydować czy procesor może działać czy nie. Ale to znowu zakłada, że prawdopodobieństwo uszkodzenia procesora jest wielokrotnie wyższe niż tego kontrolującego go układu.
    Stąd też wniosek jest prosty - jeśli pytający ma istotnie taką aplikację dla której tego typu problemy są absolutnie krytyczne to przede wszystkim powinien zmienić rodzinę procesorów. Nawet Atmel oferuje podzespoły dla systemów krytycznych (lotnictwo, medycyna). I takie właśnie elementy przede wszystkim należałoby stosować.
  • #15 8826951
    mirekk36
    Poziom 42  
    albertb napisał:
    mirekk36 napisał:

    .... no i tu ZUPEŁNA RACJA ... - można tylko po co ?


    Wszyscy skupili sie na pytaniu po co?


    I dobrze, bo równie dobrze może zabić jeśli ów test pamięci wykaże błąd. Więcej może nawet nie wykazać błędu bo wcześniej poleci np obszar pamięci odpowiedzialny za porty I/O ....

    albertb napisał:
    A banalna odpowiedź, że jak źle zadziała to może kogoś zabić nie wystarczy?


    Nie wystarczy, bo lepiej nakierować autora albo dać mu wskazówki, że jeśli już miałby w ogóle robić coś od czego zależy ludzkie życie (w co wątpię na tym etapie pytań na forum) .... ale załóżmy że przygotowuje się do takich zagadnień to lepiej żeby wiedział w jakim kierunku iść. Inaczej dobiera się w takich sytuacjach zarówno mikrokontrolery jak i same sposoby zabezpieczeń a niejednokrotnie zabezpieczeń wielopoziomowych. Nijak się zatem ma testowanie pamięci RAM w typowych prockach AVR do urządzeń służących do ratowania życia ludzkiego, więc nie przesadzajmy.
  • #16 8826994
    Konto nie istnieje
    Konto nie istnieje  
  • #17 8827064
    tmf
    VIP Zasłużony dla elektroda
    albertb - nie bzdura, Mirek ma rację. Jak procesor może przetestować fragment nierozerwalnie związany ze swoim działaniem? Jeśli doszłoby do uszkodzenia SRAM to cały procesor będzie działał nieprzewidywalnie, testowanie niczego więc nie zmieni. To mniej więcej tak, jakbyć załadował losowy ciąg bajtów licząc, że stworzy on funkcjonalny program. Takie systemy jak pisze Mirek realizuje się poprzez niezależne, wzajemnie kontrolujące się podsystemy.
  • #18 8827103
    mirekk36
    Poziom 42  
    albertb napisał:
    mirekk36 napisał:

    I dobrze, bo równie dobrze może zabić jeśli ów test pamięci wykaże błąd.

    Bzdura. Jak testu nie przejdzie nie włączy układu wykonaczego. KPW?


    A myślałem że już ci przeszły te denne odzywki na forum. Tak więc swoje skróty typu KPW, HGW, KGB czy inne pozostaw dla swoich kolegów z podwórka i tam się nimi posługuj - tyle NORMA (o którą się dopominasz) .

    Odpowiadając na twoje jakże inteligentne zaprzeczenie "Bzdura", zapytam cię inaczej, chociaż rozumiem, że wg ciebie zadawanie pytań jest niestosowne i lepiej odsyłać do norm ale to uczyniłem już przed chwilą wyżej. Zatem jeśli się uszkodzi w nietypowy sposób pamięć RAM to może to równie dobrze zdarzyć się to w obaszarze rejestrów roboczych a to już może na amen wyłożyć twoje sprawdzanie integralności RAM. A w przypadku awarii RAM może to skutkować niekoniecznie prawidłowym wyłączeniem urządzenia. Może oczywiście spowodować "zwiechę" ale równie dobrze może spowodować wystawianie co chwilę na przypadkowe porty przypadkowych wartości.

    Poza tym są to rozważania tak czysto teoretyczne, i jeśli ktoś sobie pozwala podyskutować luźno i zadać pytania to nie po to żeby wpadał taki mało kulturalny jegomość jak ty i rzucał swoimi skrótami z podwórka. To że ty nie potrafisz zadawać pytań i korzystać z odpowiedzi nie oznacza że wszyscy mają taką samą wadę/usterkę. A zadawaniem pytań nie raz można kogoś naprowadzić na pewne pomysły i rozwiązania.

    Przejaskrawiając nieco sytuację, jeśli ciebie na forum ktoś zapytałby: "jak odrąbać sobie nogę?" - to oczywiście ty udzieliłbyś mu rzeczowej odpowiedzi jak to zrobić..... widzisz - a ja zadałbym pytanie "po co? dlaczego? chce sobie odrąbać nogę??" ... taka jest różnica i może chociaż to do ciebie dotrze?

    albertb napisał:
    mirekk36 napisał:

    Nie wystarczy, bo lepiej nakierować autora albo dać mu wskazówki, że jeśli już miałby w ogóle robić coś od czego zależy ludzkie życie (w co wątpię na tym etapie pytań na forum) .... ale załóżmy że przygotowuje się do takich zagadnień to lepiej żeby wiedział w jakim kierunku iść. Inaczej dobiera się w takich sytuacjach zarówno mikrokontrolery jak i same sposoby zabezpieczeń a niejednokrotnie zabezpieczeń wielopoziomowych. Nijak się zatem ma testowanie pamięci RAM w typowych prockach AVR do urządzeń służących do ratowania życia ludzkiego, więc nie przesadzajmy.

    Więc chyba lepiej skierować go do norm niż pytać po co sprawdza RAM?


    Na to już ci odpowiedziałem kulturalnie wyżej. Jeśli nie rozumiesz albo przerasta cię to, to nie bierz udziału w dyskusji. Swoje prawdy i hasła idź wykrzyczeć w Hyde Park'u - tam wszystko dozwolone.
  • #19 8827130
    Konto nie istnieje
    Konto nie istnieje  
  • #20 8827182
    michalko12
    Specjalista - Mikrokontrolery
    Wszelakie testy tego typu są do 4 liter. Zbyt dużo czynników może mieć wpływ na jakość takiego testu np. temperatura, pola EM i inne zakłócenia. W PC te testy też rzadko kiedy coś wykazują, test OK a po paru minutach zwiecha albo bluescreen. Jeśli od jakiegoś urządzenia ma zależeć bezpieczeństwo to powinno się stosować szereg zabezpieczeń od siebie niezależnych.
  • #21 8827198
    Konto nie istnieje
    Konto nie istnieje  
  • #22 8827430
    anacocito
    Poziom 10  
    Zacznę od postu Żabka

    Cytat:
    W EEPROMie przechowuje się dane konfiguracyjne, jakieś flagi, ustawienia, kalibracje itp a testując je przez zapis czegokolwiek innego na zawsze wymaże te dane z pamięci

    Te dane, flagi, ustawienia, itd nie zajmą całej pamięci, myślałem o tym żeby testować ją blokami, kopiując dane do wcześniej sprawdzonego bloku.
    Ptk. 2 rozumiem że pamieć przez ciągłe zapisywanie zużyje się szybko, jak ktoś napisał można użyć FRAM, pytałem czy takie testowanie ma sens. Inna możliwość to jakaś suma kontrolna obliczona na podstawie tego co się w niej znajduje i powtórzenie kluczowych wartości w różnych komórkach i przyjęcie poprawności na podstawie głosowania np. jeżeli 4 z 5 danych są takie same przyjmujemy że te 4 komórki zawierają poprawną wartość.

    Cytat:
    test SRAMu zupełnie bezcelowy bo jego uszkodzenie==uszkodzenie uC.

    Właśnie o to mi chodzi, żeby wiedzieć czy SRAM jest uszkodzony i w takim wypadku układ nie próbował niczego robić. Niekoniecznie uszkodzeniu ulega cała pamięć, a na przykład tylko jej fragment. I czy test o którym myślałem jest wstanie to stwierdzić. Jeśli nie to jak inaczej do tego podejść.

    Co do postu Xury to jak najbardziej o tym myślałem ale nie mam pomysłu jak.

    Post Mirkak36

    Myślałem o podobnym sposobie jak Twoja odpowiedź na ptk.1, rozumiem że jeśli chcę testować EEPROM to tylko w pełnych cyklach zapis odczyt, a nie blokami tylko nie wiem z jakiego powodu.

    Ciągłe testy zmniejszą żywotność pamięci i jej niezawodność. Czy z koleji suma kontrolna i powtórzenie danych w różnych komórkach jest wystarczającym sposobem zabezpieczenia zabezpieczenia. Czy sens miało by połączenie tych dwóch opcji: testy w sensownych odstępach czasu oraz suma kontrolna i powtórzenie danych.

    Albertb

    Cytat:
    A banalna odpowiedź, że jak źle zadziała to może kogoś zabić nie wystarczy?

    No tak, o to właściwie chodzi.

    Jeśli chodzi o normy to wiem że są en-pn 50126 50128 50159, niestety biblioteki agh i pk ich nie posiadają, inne biblioteki w krakowie które sprawdzałem też nie, firmy nie udostępnią, a ich koszt to jakieś 800zł. Ale i tak staram się do nich dostać.

    Tmf

    Cytat:
    Nawet Atmel oferuje podzespoły dla systemów krytycznych (lotnictwo, medycyna). I takie właśnie elementy przede wszystkim należałoby stosować.

    Jaka to rodzina uP?

    I odnośnie kolejnego posta Mirka i Tmf.
    Czyli jeśli już chciałbym testować SRAM jakiegoś uP to jedynie za pomocą kolejnego układu?
    Gdzie zatem szukać informacji jak zbudowane są takie układy, na jakie zagadnienia zwrócić uwagę, do jakiej literatury sięgnąć?

    Odnośnie postu Alberta to układ nie miałby wysterować urządzenia poprzez wystawienie na jednym porcie określonego stanu lecz poprzez ściśle określone, zsynchronizowane sygnały dynamiczne pochodzące z 2 różnych uP z dwoma różnymi ale równoważnymi programami.

    Michalko12

    Cytat:
    Zbyt dużo czynników może mieć wpływ na jakość takiego testu np. temperatura, pola EM i inne zakłócenia

    A jeśli warunki byłyby sprzyjające, dobre chłodzenie, ekranowanie od pola EM itd to czy to dalej nie miało by sensu?

    Rozumiem że to to złożone zagadnienie, moje pytanie to czy testy pamięci w celu podniesienia bezpieczeństwa są sensowne i jak je przeprowadzić. Czy też są one zupełnie zbędne.
  • #23 8827457
    dondu
    Moderator na urlopie...
    Panowie, każdy z Was ma rację. Ale weźcie pod uwagę, że każde zabezpieczenie w jakimś stopniu zwiększa bezpieczeństwo tak samo zwiększa je test pamięci itp. "Grosz do grosza ...". Oczywiście nigdy nie ma pewności, że kontroler jest sprawny w 100%, bo może się popsuć w czasie działania.

    Do tego dochodzi jeszcze czynnik ludzki o którym przekonała się moja mama gdy technik naprawiający solarium coś sknocił, to wylądowała w szpitalu z poparzeniami i leżała 3 tygodnie.
  • #24 8827876
    tmf
    VIP Zasłużony dla elektroda
    anacocito napisał:
    Zacznę od postu Żabka

    Cytat:
    W EEPROMie przechowuje się dane konfiguracyjne, jakieś flagi, ustawienia, kalibracje itp a testując je przez zapis czegokolwiek innego na zawsze wymaże te dane z pamięci

    Te dane, flagi, ustawienia, itd nie zajmą całej pamięci, myślałem o tym żeby testować ją blokami, kopiując dane do wcześniej sprawdzonego bloku.
    Ptk. 2 rozumiem że pamieć przez ciągłe zapisywanie zużyje się szybko, jak ktoś napisał można użyć FRAM, pytałem czy takie testowanie ma sens. Inna możliwość to jakaś suma kontrolna obliczona na podstawie tego co się w niej znajduje i powtórzenie kluczowych wartości w różnych komórkach i przyjęcie poprawności na podstawie głosowania np. jeżeli 4 z 5 danych są takie same przyjmujemy że te 4 komórki zawierają poprawną wartość.


    Jak pisałem, ze względu na fizyczny mechanizm uszkadzania się komórki pamięci EEPROM wszelkie testy zapisu nie maja najmniejszego sensu. Pierwszym objawem uszkodzenia komórki jest skrócenie czasu retencji danych. W efekcie odczytana tuż po zapisie informacja jest poprawna, ale niekoniecznie taka będzie następnego dnia. Jeśli komórki nie da się zapisać to znaczy, że była ona już wcześniej zupełnie uszkodzona. Jedynym sensownym rozwiązaniem jest liczenie CRC. Teraz znając prawdopodobieństwo uszkodzenia komórki, algorytm CRC i ilość bitów CRC możesz wyliczyć dokładnie prawdopodobieństwo złej interpretacji danych (czyli, że dane uszkodzone zostaną potraktowane jako prawidłowe). Jak się domyślasz to prawdopodobieństwo można sprowadzić do dowolnie małej, ale różnej od zera wartości.

    anacocito napisał:
    Cytat:
    test SRAMu zupełnie bezcelowy bo jego uszkodzenie==uszkodzenie uC.

    Właśnie o to mi chodzi, żeby wiedzieć czy SRAM jest uszkodzony i w takim wypadku układ nie próbował niczego robić. Niekoniecznie uszkodzeniu ulega cała pamięć, a na przykład tylko jej fragment. I czy test o którym myślałem jest wstanie to stwierdzić. Jeśli nie to jak inaczej do tego podejść.


    Problem w tym, że nie wiesz co uległo uszkodzeniu. To może być jakiś obszar pamięci, albo np. komórka przechowująca rejestr procesora (fizycznie w aVR to jest to samo). Więc jak stwierdzić uszkodzenie za pomocą potencjalnie uszkodzonego przyrządu? W dodatku zły algorytm w takiej sytuacji może nic nie wykryć, ponieważ ilość potencjalnych uszkodzeń jest spora, trudno jest sobie więc wyobrazić algorytm niewrażliwy na nie. Stąd prościej jest zdublować system w taki sposób aby jeden testował drugi, albo np. ztriplikować i zrobić majority voting. To oczywiście komplikuje mocno całość, no ale takie systemy przecież nie muszą być tanie.


    anacocito napisał:
    Cytat:
    Nawet Atmel oferuje podzespoły dla systemów krytycznych (lotnictwo, medycyna). I takie właśnie elementy przede wszystkim należałoby stosować.

    Jaka to rodzina uP?


    Tu musisz się skontaktować z Atmelem. Informacje o chipach do zastosowań specjalnych dostaniesz po podpisaniu non-disclosure agreement. W każdym razie jest to jest urządzenie od którego zależy życie to nawet nie wolno ci stosować zwykłych chipów - zobacz umowę z Atmelem, wyrażnie zastrzegają, że ich procesory nie są przeznaczone do tego typu zastosowań. Co jednoznacznie kończy ten temat.

    anacocito napisał:
    I odnośnie kolejnego posta Mirka i Tmf.
    Czyli jeśli już chciałbym testować SRAM jakiegoś uP to jedynie za pomocą kolejnego układu?
    Gdzie zatem szukać informacji jak zbudowane są takie układy, na jakie zagadnienia zwrócić uwagę, do jakiej literatury sięgnąć?


    Zasadniczo tak. To nie musi być oczywiście procesor, chociaż tak jest stosunkowo wygodnie. Ale to nie tylko kwestia testów, cały układ elektrycznie musi być tak zaprojektowany, aby w każdej sytuacji można było przewidzieć jego zachowanie. Co do informacji - temat jest tak specjalistyczny, że na twoim miejscu znalazłbym dobrego fachowca od tego na jakiejś uczelni. Literatury na ten temat też trochę jest. Może warto by też pojechać na jakiś zjazd poświęcony tej tematyce, to sobie zbierzesz różne informacje, a pewnie i porządną literaturę kupisz. Swego czasu na pl.misc.elektronika pisywał człowiek projektujący układy dla medycyny i aerospace, odszukaj jego posty i się z nim skontaktuj, pewnie powie ci więcej.

    anacocito napisał:
    Rozumiem że to to złożone zagadnienie, moje pytanie to czy testy pamięci w celu podniesienia bezpieczeństwa są sensowne i jak je przeprowadzić. Czy też są one zupełnie zbędne.


    Przeprowadzić je możesz, zawsze w jakimś nikłym odsetku to coś wykryje. A czy są sensowne to widać po teście POST na PC. On praktycznie wykrywa tylko sytuacje typu pamięć jest lub jej nie ma :) Lepsze wyniki osiągają wielogodzinne testy pamięci, ale to z przyczyn oczywistych nie wchodzi w grę. Także myślę, że nie tędy droga.
  • #25 8828720
    Konto nie istnieje
    Konto nie istnieje  
  • #26 8828769
    mirekk36
    Poziom 42  
    anacocito napisał:
    Jaka to rodzina uP?.


    Jak zapuściłem googla w temacie dedykowanych rozwiązań dla medycyny jeśli chodzi o procki to znalazłem fajne i ciekawe opisy pewnych rozwiązań w niektórych procesorach typu cortex , które właśnie ze względu m.in na takie zastosowania jak w medycynie ale nie tylko mają wbudowane wewnętrzne specjalne mechanizmy sprzętowe do badania integralności pamięci i innych modułów. W tym także pamięci Flash a zaopatrzone są w tym celu we własny kawałek specjalnej pamięci ROM z programem który to nadzoruje. Nie wchodziłem w szczegóły jaki to konkretnie procek bo takimi się nie zajmuję ale gdybym miał próbować robić to co ty - to właśnie bym szedł w takim kerunku gdzie już na etapie produkcji procka występują dedykowane zabezpieczenia itp

    albo jak pisze tmf - bo na pewno jest wiele innych rodzin procków i rozwiązań, które mają specjalne fiuczersy w tym kierunku.

    poczytaj sobie może takie tematy:

    http://www.ti.com/ww/pl/apps_medical.html?DCM...Header_Tracking&HQS=Other+OT+pl_hdr_a_medical
  • #27 8829723
    anacocito
    Poziom 10  
    Cytat:
    Oczywiście nigdy nie ma pewności, że kontroler jest sprawny w 100%, bo może się popsuć w czasie działania.

    Dlatego uznałem że testy sprawdzające sam uP jednymi z kluczowych aspektów. Po odpowiedziach wnoszę że test SRAM wydaje się być chybionym pomysłem, ale samo sprawdzanie poprawności działania i tak zostaje tylko realizowane w inny sposób.

    Cytat:
    Jedynym sensownym rozwiązaniem jest liczenie CRC. Teraz znając prawdopodobieństwo uszkodzenia komórki, algorytm CRC i ilość bitów CRC możesz wyliczyć dokładnie prawdopodobieństwo złej interpretacji danych (czyli, że dane uszkodzone zostaną potraktowane jako prawidłowe). Jak się domyślasz to prawdopodobieństwo można sprowadzić do dowolnie małej, ale różnej od zera wartości.

    Jedynym sensownym z uwagi na żywotność pamięci EEPROM. Tu już własciwie nie ma o czym więcej pisać, jedynym sposobem na upewnienie się czy dane zapisane tam nie zostały uszkodzone jest suma kontrolna.
    Z koleji test SRAM wypada zastąpić lub uzupełnić innym/i testami. Tylko teraz nasuwa się pytanie jakimi?

    Cytat:
    Zasadniczo tak. To nie musi być oczywiście procesor, chociaż tak jest stosunkowo wygodnie. Ale to nie tylko kwestia testów, cały układ elektrycznie musi być tak zaprojektowany, aby w każdej sytuacji można było przewidzieć jego zachowanie. Co do informacji - temat jest tak specjalistyczny, że na twoim miejscu znalazłbym dobrego fachowca od tego na jakiejś uczelni. Literatury na ten temat też trochę jest. Może warto by też pojechać na jakiś zjazd poświęcony tej tematyce, to sobie zbierzesz różne informacje, a pewnie i porządną literaturę kupisz. Swego czasu na pl.misc.elektronika pisywał człowiek projektujący układy dla medycyny i aerospace, odszukaj jego posty i się z nim skontaktuj, pewnie powie ci więcej.

    Tak się składa że temat pracy dyplomowej, i mój pomysł z testami uP przy starcie i periodycznie w trakcie pracy promotor uznał za dobry. Chociaż to było luźno rzucone stwierdzenie które teraz próbuje zglebić. Co do literatury to usłyszałem dokładnie na odwrót, że jest jej bardzo mało. Jeśli znasz jakieś tytuły byłbym wdzięczny, mogą być angielskojęzyczne.

    Dzięki za linka może tam znajdę przydatne informacje i podpatrzę jakieś rozwiązania.

    I jeszcze pytanie odnośnie sprawdzenia poprawności pamięci programu za pomocą sumy kontrolnej, czy coś takiego ma sens?
  • #28 8832316
    Nawigator
    Poziom 33  
    Komplet odpowiedzi na zadany temat wraz z kodami źródłowymi znajdziesz w notach Atmela:

    AVR998: Guide to IEC60730 Class B compliance with AVR Microcontrollers
    http://www.atmel.com/dyn/resources/prod_documents/doc7715.pdf
    http://www.atmel.com/dyn/resources/prod_documents/AVR998_rev_1_1.zip

    AVR236: CRC check of Program Memory on tinyAVR and megaAVR devices with LPM instruction
    http://www.atmel.com/dyn/resources/prod_documents/doc1143.pdf
    http://www.atmel.com/dyn/resources/prod_documents/AVR236.zip

    Osobiście w notach aplikacyjnych Atmela znalazłem odpowiedzi na wiele nurtujących mnie pytań i od nich zawsze zaczynam poszukiwania.
    N.
  • #29 8832581
    tmf
    VIP Zasłużony dla elektroda
    Niekoniecznie znajdzie.
    Zauważ, że ta nota nie dotyczy urządzeń od których zależy życie, a o takie pyta autor. Atmel proponuje różne testy, ale nawet nie pokazuje żadnych statystyk co do wykrywalności awarii, więc te informacje IMHO są częściowo nieprzydatne. Jeśli robię np. test EEPROM to niezwykle istotna jest wiedza w jakim stopniu wykrywa on różne błędy i jak to wpływa na wykrywalność uszkodzeń danych. Bez tego to przypomina homeopatię - wszyscy w to wierzą, ale nikt nie ma dowodów, że działa. Jednak zabezpieczenia urządzeń od których zależy życie są inne, tu podstawą jest redundancja. Z drugiej strony część testów, typu CRC FLASH, EEPROM z pewnością warto, a nawet należy robić. Testowanie SRAM jest IMHO wątpliwe, co pokazują testy na PC. Stosowanie masek 0x55 i 0xAA, czyli naprzemiennych 0 i 1 wykrywa praktycznie tylko błędy typu zwarcie linii danych do 0 lub 1. A linie adresowe? IMHO sensowniejszy test samego procesora to np. zewnętrzny WD, który można zablokować tylko wpisując wyliczoną przez program wartość, do której wyliczenia wykorzystujemy maksimum zasobów. W takiej sytuacji wynik jest poprawny tylko wtedy, kiedy wszystkie bloku funkcyjne procesora zaangażowane w wyliczenie wyniku działają poprawnie. Takie podejście uniezależnia nas zupełnie od tego czy procesor w ogóle działa - szansa, że wystawi do WD poprawne dane w przypadku uszkodzenia może być dowolnie mała (o ile nie popełnimy jakiegoś błędu systematycznego).
  • #30 8833438
    Nawigator
    Poziom 33  
    >>tmf
    cyt: "Niekoniecznie znajdzie.
    Zauważ, że ta nota nie dotyczy urządzeń od których zależy życie, a o takie pyta autor."

    Autor pytał o testy pamięci w AVR. Gdyby pytał o urządzenia ratujące życie to od razu by dostał odpowiedź ze AVR się do tego nie nadają bo nie może urządzenie podlegające testowi samo się sprawdzać przy pomocy tych samych zasobów sprzętowych.
    W w/w nocie jest proponowany test przy pomocy drugiego AVR-a i jest to już jakieś rozwiązanie choć ja bym sugerował użycie do tego celu np. PIC-a (inna konstrukcja ma inną odporność na zakłócenia).
    Class B w w/w normach dotyczy sprzętu gospodarstwa domowego a więc o podwyższonym stopniu bezpieczeństwa.
    Gdzieś czytałem że we współczesnych samolotach systemy komputerowe są dublowane przez sprzęt z różnych, niezależnych firm i oprogramowanie pisane przez oddzielne, nieznające się wzajemnie, zespoły programistów.


    N.

    PS. A póki co to nie ma co testować bo atmeli brak na rynku... A trafiające się malowane podróbki i tak nie zadziałają.
REKLAMA