Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Computer Controls
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Jak przechować 200 bajtów przez 15 lat ?

07 Kwi 2012 13:39 2090 20
  • Poziom 9  
    Projektuję urządzenie które musi przechować 200 bajtów danych przez minimum 15 lat przy jak najmniejszych gabarytach. Zastanawiam się nad PCF8583 i baterią CR2032 ( 225mAh )
    Z noty PCF8583 wynika że w trybie "data retention" pobiera 2uA przy VCC 1.0V czyli przy baterii 3V to będzie 6uA.
    To wystarczy jedynie na około 5 lat.
    Zastosowanie baterii CR2450 ( 610 mAh ) wydłuża czas pracy do 11 lat. Wciąż za mało.
    Macie jakies pomysły ?
  • Computer Controls
  • Computer Controls
  • Poziom 38  
    200 bajtów, to nie tak dużo, przepisać "na kartkę" , (w kodzie binarnym, lub szesnastkowym) jeżeli mają być tylko przechowane, i do sejfu :D .
  • Poziom 9  
    robokop napisał:
    Pamięć nieulotna? Bo 15 lat dla baterii to sporo.

    To nie może być np. FLASH.
    Zawartość pamięci musi być skasowana przy próbie otwarcia urządzenia.

    Bateria litowa ma bardzo mały współczynnik samorozładowania 1-3% rocznie więc wytrzyma i 20 lat problem jest "tylko" z poborem prądu.
    Dla przykładu RTCC PCF8563 potrzebuje do podtrzymania zegara 250nA przy baterii CR2032 daje to ponad 30 lat pracy.

    Dodano po 1 [minuty]:

    Qbuś napisał:
    200 bajtów, to nie tak dużo, przepisać "na kartkę" , (w kodzie binarnym, lub szesnastkowym) jeżeli mają być tylko przechowane, i do sejfu :D .


    Wszystko się zgadza poza gabarytami sejfu :D
  • Poziom 9  
    witek_34 napisał:
    FRAM chyba odpada z tych samych względów co flash, ale może coś z tego:
    http://ww1.microchip.com/downloads/en/DeviceDoc/22127a.pdf

    To rozwiązanie jest ciekawe. Pobiera 1uA w trybie podtrzymania co przy CR2032 daje już 20 lat. :D
    witek_34 napisał:

    Ew. dedykowany układ do autoryzacji:
    http://www.atmel.com/Images/doc8558.pdf

    Ten układ byłby OK tylko że on przechowuje max. 256 bitów a ja potrzebuję 200 bajtów.
  • Poziom 33  
    A jakieś ROM-y, czy inne GAL-e?
    Zaprogramować i zapomnieć - i nie potrzeba zasilania...
  • Poziom 33  
    tdziki napisał:

    Pomysł ciekawy. Poza tym że kompletnie nie znam 8051 :cry:


    Inne rodziny też mają tzw. serie Pico Power. Druga sprawa to taka że ściągając zasilanie z pamięci RAM nie oznacza jej skasowania. Wykorzystując mikrokontroler można po otwarciu urządzania skasować wszystko ważne dane.
  • Poziom 36  
    AVE...

    1. Jakiś mały PIC12F z wbudowanym EEPROMem, gdzie dane będą przechowywane.
    2. Otwarcie pojemnika bez wcześniejszej autoryzacji podłączy układ do baterii, a program w nim zaszyty dane usunie.
    3. Zasilanie z ogniwa LiION lub LiPo o pojemności 2200mAh, to starczy na więcej niż 20 lat.
    4. Alternatywą jest mały układ EEPROM lub FlashROM podłączony do baterii akumulatorków o napięciu znacznie przekraczającym dopuszczalne. W razie otwarcia pojemnika bez autoryzacji bateria zostanie podłączona do układu i przepali strukturę wewnątrz...
  • Poziom 9  
    Urgon napisał:
    AVE...

    1. Jakiś mały PIC12F z wbudowanym EEPROMem, gdzie dane będą przechowywane.
    2. Otwarcie pojemnika bez wcześniejszej autoryzacji podłączy układ do baterii, a program w nim zaszyty dane usunie.
    3. Zasilanie z ogniwa LiION lub LiPo o pojemności 2200mAh, to starczy na więcej niż 20 lat.
    4. Alternatywą jest mały układ EEPROM lub FlashROM podłączony do baterii akumulatorków o napięciu znacznie przekraczającym dopuszczalne. W razie otwarcia pojemnika bez autoryzacji bateria zostanie podłączona do układu i przepali strukturę wewnątrz...

    Jak piszę że MUSI byc RAM to znaczy że MUSI.

    Zdecydowałem się na użycie PIC16F1827. W trybie SLEEP+RTC pobiera 800nA.
    PIC musi zareagować na otwarcie obudowy ( przerwanie połaczenia przez microswitch ). Zastanawiam się jak to zrobić z głową.

    Jeżeli podłączę jedno z wejść do VCC ( baterii ) przez microswitch jego otwarcie rozłączy obwód i na wejściu będzie stan nieustalony. Z kolei podciągnięcie linii do GND spowoduje jednak ciągły upływ prądu a my tu walczymy o nano ampery :(
  • Poziom 36  
    AVE...

    Dlaczego, na Bora Wszechlistnego, musi to być RAM? Komplikujesz sobie tylko życie w ten sposób. A jeśli bateria okaże się wadliwa lub słaba, to stracisz te dane dużo wcześniej i bez otwarcia pojemnika. Daj powód, dlaczego chcesz to robić w tak idiotyczny sposób...
  • Poziom 9  
    Urgon napisał:
    AVE...
    Dlaczego, na Bora Wszechlistnego, musi to być RAM? Komplikujesz sobie tylko życie w ten sposób. A jeśli bateria okaże się wadliwa lub słaba, to stracisz te dane dużo wcześniej i bez otwarcia pojemnika. Daj powód, dlaczego chcesz to robić w tak idiotyczny sposób...

    Niektórym nie przetłumaczysz :D
    Jest to wymóg zewnętrznej specyfikacji urządzenia. Klucz RSA MUSI byc przechowywany w ulotnej pamięci RAM kasowanej w momencie otwarcia urządzenia. Ja tego nie wymyśliłem. TAK MUSI BYĆ i zakończymy juz dyskusję nad sensem stosowania RAM-u. Też mi to nie pasuje.
  • Poziom 36  
    AVE...

    Podciągasz linię MCLR do plusa przez rezystor, i spinasz do masy kondensatorem. Równolegle z nim łączysz jakiś czujnik, który zostanie zwarty w chwili otwarcia obudowy. Choćby dwie blaszki z paskiem cienkiego plastiku między nimi. Zwarcie linii MCLR do masy w tej konfiguracji zresetuje układ kasując też zawartość wewnętrznej pamięci RAM i rejestrów. Starczy krótki impuls, który rozładuje kondensator. To samo w sumie się stanie, jeśli skonfigurujesz tak pin VCC i zewrzesz go z masą. Co do zasilania, to wziąłbym kilka bateryjek równolegle. Minimum dwie. Do tego zaleciłbym od czasu do czasu podpinać urządzenie do zasilania...
  • Poziom 9  
    Propozycja jest OK ale mój problem jest bardziej skomplikowany.
    PIC16 będzie jednoczesnie pełnił funkcję zegara RTC. Otwarcie obudowy ma go wybudzic z trybu SLEEP i następnie programowo skasować RAM. PIC musi wciąż działac jako RTC więc reset przy pomocy pinu MCLR odpada.
    Myślę jak to połaczyć żeby otwarcie obudowy ( przerwanie lub zwarcie obwodu ) zainicjowało przerwanie w PIC które wybudzi go z SLEEP-a i jednocześnie to połączenie nie powodowało niepotrzebnego upływu prądu.
  • Poziom 36  
    AVE...

    W takim razie nie ma sensu bawić się w trzymanie klucza w RAMie, skoro i tak musisz go programowo kasować. Ponadto jeszcze RTC w tych układach nie jest zbyt stabilny na dłuższą metę, więc i tak będziesz musiał dodać odbiornik sygnału czasowego bo inaczej stracisz synchronizację. Lub uwzględnić synchronizację z urządzeniem zabezpieczanym...
  • Poziom 9  
    Urgon napisał:
    W takim razie nie ma sensu bawić się w trzymanie klucza w RAMie, skoro i tak musisz go programowo kasować.

    Kwestia zabezpieczenia. Ma to zapobiegać wyjęciu układu na zewnątrz i próbie odczytu klucza z pamięci nieulotnej.
    Urgon napisał:
    Ponadto jeszcze RTC w tych układach nie jest zbyt stabilny na dłuższą metę, więc i tak będziesz musiał dodać odbiornik sygnału czasowego bo inaczej stracisz synchronizację. Lub uwzględnić synchronizację z urządzeniem zabezpieczanym...

    Ten RTC będzie dość często synchronizowany z odbiornikiem GPS.
  • Poziom 36  
    AVE...

    Umieszczasz seed w EEPROMie, pośród losowych danych. Po otwarciu obudowy urządzenia układ nadpisuje komórki pamięci z seedem innymi danymi, a potem nadpisuje fragment kodu odpowiedzialny za pierwsze nadpisanie. Zajmie to pewno z 400-500 cykli programu. Ustawić tylko musisz układ tak, by w razie kłopotów przełączył się na wewnętrzny oscylator 32MHz. Układ może wtedy wykonać osiem milionów instrukcji na sekundę - nikt nie wyjmie ani układu, ni baterii na czas. Tak były robione pierwsze modele RSA SecureID. Najnowsze nie psują się po wyjęciu z obudowy. Trzymanie seedu w RAMie ze względu na "bezpieczeństwo" jest bezsensowną stratą zasobów. Komercyjne tokeny SecureID funkcjonują średnio trzy lata, bo więcej nie potrzebują, i tyle zachowuje ważność seed RSA...
    Jeśli naprawdę koniecznie chcesz trzymać to w RAMie, to będziesz potrzebował czegoś więcej, niż jedna bateryjka CR. I będziesz pewno musiał to podładowywać co jakiś czas, bo te nanowaty nie zawsze są zgodne z prawdą. Bez miernika w rodzaju µCurrent tego nie zmierzysz...
  • Poziom 9  
    Urgon napisał:
    AVE...
    Umieszczasz seed w EEPROMie, pośród losowych danych. Po otwarciu obudowy urządzenia układ nadpisuje komórki pamięci z seedem innymi danymi, a potem nadpisuje fragment kodu odpowiedzialny za pierwsze nadpisanie. Zajmie to pewno z 400-500 cykli programu. Ustawić tylko musisz układ tak, by w razie kłopotów przełączył się na wewnętrzny oscylator 32MHz. Układ może wtedy wykonać osiem milionów instrukcji na sekundę - nikt nie wyjmie ani układu, ni baterii na czas. Tak były robione pierwsze modele RSA SecureID. Najnowsze nie psują się po wyjęciu z obudowy. Trzymanie seedu w RAMie ze względu na "bezpieczeństwo" jest bezsensowną stratą zasobów. Komercyjne tokeny SecureID funkcjonują średnio trzy lata, bo więcej nie potrzebują, i tyle zachowuje ważność seed RSA...
    Jeśli naprawdę koniecznie chcesz trzymać to w RAMie, to będziesz potrzebował czegoś więcej, niż jedna bateryjka CR. I będziesz pewno musiał to podładowywać co jakiś czas, bo te nanowaty nie zawsze są zgodne z prawdą. Bez miernika w rodzaju µCurrent tego nie zmierzysz...

    To ja się tylko powtórzę:
    Cytat:
    Jest to wymóg zewnętrznej specyfikacji urządzenia. Klucz RSA MUSI byc przechowywany w ulotnej pamięci RAM kasowanej w momencie otwarcia urządzenia. Ja tego nie wymyśliłem. TAK MUSI BYĆ i zakończymy juz dyskusję nad sensem stosowania RAM-u. Też mi to nie pasuje.
  • Poziom 31  
    tdziki napisał:

    To ja się tylko powtórzę:
    Cytat:
    Jest to wymóg zewnętrznej specyfikacji urządzenia. Klucz RSA MUSI byc przechowywany w ulotnej pamięci RAM kasowanej w momencie otwarcia urządzenia. Ja tego nie wymyśliłem. TAK MUSI BYĆ i zakończymy juz dyskusję nad sensem stosowania RAM-u. Też mi to nie pasuje.


    MAXIM i jego MAXQ1010 twoim przyjacielem jest:
    http://www.maxim-ic.com/datasheet/index.mvp/id/6450

    Cytat:
    An additional 128B secure key storage SRAM is instantly erased when a self-destruct input is triggered.


    Albo MAXQ1050: http://www.maxim-ic.com/datasheet/index.mvp/id/7277
    Cytat:
    The 256B of battery-backed NV SRAM can be used for key storage and other critical data. The 256B memory can be erased in less than 1µs using a single pulse ("rapid zeroization"), even in battery-backed mode.


    Zamawiaj sample i problem rozwiązany ;)