Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

[TM4C1231D5PM] Zużycie EEPROM

Pan Korsarz 24 Feb 2018 17:39 1179 23
  • #1
    Pan Korsarz
    Level 3  
    Witam,
    w chwili obecnej pracuje z układem Texas Instruments Tiva TM4C1231D5PM .
    Ma on wbudowany EEPROM 2 kB i chce w nim cyklicznie przechowywać dane, ale z racji tego że taka pamięć (jej komórka) ulega uszkodzeniu po określonej liczbie cykli zapisu to chciałem rozwiązać to softwarowo poprzez np. zmianę adresu komórki do której odbywa się zapis po np 10 tysiącach zapisów. Lecz podczas lektury noty katalogowej dostrzegłem wzmiankę "Built-in wear leveling" czy to oznacza że jest to w jakiś sposób już rozwiązane sprzętowo i nie muszę się tym martwić ?
    Wcześniej nie miałem styczności z EEPROM więc być może jest to dla niektórych oczywiste.
    [TM4C1231D5PM] Zużycie EEPROM

    Pozdrawiam.
  • #2
    BlueDraco
    MCUs specialist
    Dlaczego chcesz mordować pamięć taką liczbą zapisów? Większe dane (np. konfigurację) zapisuje się rzadko. Mniejsze, np. jakieś liczniki , wystarczy zapisać podczas wyłączania zasilania albo po jakimś czasie od ostatniej zmiany.
  • #3
    Pan Korsarz
    Level 3  
    Takie są założenia projektu, system nie będzie posiadał UPS ani nic z systemów utrzymania jego pracy po zaniku zasilania, więc gdy zabraknie prądu nie zdąży zapisać informacji.
    Chodzi mi tylko o zarządzanie pamięcią.
  • #4
    tmf
    Moderator of Microcontroller designs
    Zapis do EEPROM to pojedyncze ms, aby podtrzymać MCU na tak krótki czas wystarczy niewielki kondensator + układ detekcji awarii zasilania (np. wbudowany w MCU komparator, jeśli jest).
    BTW, sądząc z kolejnych punktów to bouild-in wear leveling to raczej nie to o czym myślisz - wygląda jak marketing. Szczegóły pewnie są opisane w dalszych sekcjach noty o EEPROM.
  • #5
    Pan Korsarz
    Level 3  
    Nie ma właśnie nic więcej wspomniane o tym, przewija się raz jeszcze na początku ta fraza, ale żadnego objaśnienia, może być tak jak mówisz - to marketing.
  • #6
    BlueDraco
    MCUs specialist
    To zupełnie tak, jak Twoje pytania... ;) ścieżkę masz już wskazaną. Wątpię, by istniała realna potrzeba zarzynania pamięci. 5 czy 10 słów zapiszesz do EEPROM czy Flash po wykryciu obniżenia napięcia zasilania bez żadnych dodatkowych układów w stosunku do tego, co i tak na 100% masz na płytce.
  • Helpful post
    #7
    User removed account
    User removed account  
  • Helpful post
    #8
    rb401
    Level 38  
    Pan Korsarz wrote:
    Nie ma właśnie nic więcej wspomniane o tym, przewija się raz jeszcze na początku ta fraza, ale żadnego objaśnienia


    Jest w DS objaśnienie (koło strony 500, "Theory of Operation" )

    Quote:
    The EEPROM operates using a traditional Flash bank model which implements EEPROM-type cells, but uses sector erase. Additionally, words are replicated in the pages to allow 500K+ erase cycles when needed, which means that each word has a latest version.


    Czyli ten EEPROM nie jest żadnym klasycznym EEPROMem a jest to jest zwykła pamięć flash ale połączona ze sprzętową emulacją EEPROM. I można się domyślać że ten zwrot "Built-in wear leveling" dotyczy w istocie tylko tej użytej pamięci flash i algorytmu emulacji, zwiększając ilość cykli zapisów komórki z 100000 jaki ma flash w tym uC, do 500000 charakteryzującą ten emulowany EEPROM.

    I tu osobiście dostrzegam pewien problem. Jeśli byś na tą emulację, która jakoś tam działa, nałożył swój algorytm "chodzenia po adresach" to i tak nie można by mieć gwarancji że znacząco zwiększy się wytrzymałość pamięci, w stopniu takim jakby chodziło o prawdziwy EEPROM gdzie wytrzymałość dotyczy każdej komórki z osobna.

    Jeśli te 500000 to zbyt niską wartość na wymogi projektu, to można użyć własnego algorytmu emulacji i stosować w tej roli normalną pamięć flash w tm uC. STM dostarcza takiej emulacji do swoich STM32, gdzie w zależności ile informacji się zapisuje i ile poświęci obszaru flash, można uzyskać bardzo dużą ilość zapisów.
    Ale nie powiem Ci w tej chwili czy da się to łatwo przepisać na Tiva.

    Ale tak by się nie narobić a spać spokojnie, to chyba najlepiej dołączyć EEPROM z zewnątrz w wersji FRAM (nielimitowana ilość cykli zapisu), przykładowo FM24CL64.
  • #9
    User removed account
    User removed account  
  • #10
    rb401
    Level 38  
    AnicoZ wrote:
    A mnie sie wydaje, ze limit jest. Jak będziesz zapisywał FRAM 10000 razy na sekundę na ile wystarczy?


    Jest limit, ale raczej to limit cierpliwości.
    Producent podaje w DS przykładowo że robiąc zapisy do FRAM 9330 razy na sekundę, kres jej wytrzymałości wypadnie zaledwie po 340 latach 8-O (dane dla wersji z SPI, bo po I2c maksymalna ilość zapisów na sekundę będzie niestety z 10 razy mniejsza, ale czas wydłuży się x10).


    AnicoZ wrote:
    Problem żywotności eeprom i konieczności bardzo częstych zapisów, rozwiazywałem, zapisując eeprom w chwili zaniku zasilania. Energię zapewniał superkondensator. Po zapisie usypiałem procka.


    Z uwagi na cechy FRAM j/w jeśli już coś dawać z zewnątrz, to chyba taka komplikacja (kondensator, obsługa programowa itp.) nie jest rozwiązaniem optymalnym na dzień dzisiejszy. Cenowo chyba również.
  • #11
    User removed account
    User removed account  
  • #12
    tmf
    Moderator of Microcontroller designs
    Superkondensator nie jest potrzebny. Odpowiednie podtrzymanie da zwykły kondensator 100 uF. A jeśli dobrze przemyśleć zasilacz, to żaden dodatkowy element nie jest potrzebny.
  • #13
    User removed account
    User removed account  
  • #14
    Pan Korsarz
    Level 3  
    Na wstępie chce przeprosić, że nie odpisywałem, ale mam dużo pracy.

    Chciałbym podsumować dyskusję, więc wynikaz niej, że ten EEPROM to:
    "Czyli ten EEPROM nie jest żadnym klasycznym EEPROMem a jest to jest zwykła pamięć flash ".
    Taka jest konkluzja końcowa ?
  • Helpful post
    #15
    rb401
    Level 38  
    Pan Korsarz wrote:
    Taka jest konkluzja końcowa ?


    To zależy od tego do czego potrzebna ta konkluzja, jakie uwarunkowania projektu itd. .

    Z jednej strony patrząc, jest niby w tym uC funkcjonalność pamięci EEPROM i od strony użytkownika może zupełnie nie być ważne, jak to producent wewnętrznie rozwiązał, że jest to akurat emulacja. Ważne tylko ile cykli zapisu deklaruje i czy to do wymogów projektu pasuje.

    Ale z drugiej strony, tak patrząc głębiej na parametry w DS, to sprawa wygląda moim zdaniem znacznie gorzej, bo w tej emulacji istnieje jeden poważny minus względem normalnej EEPROM (nie mówiąc już o FRAM).
    Konkretnie chodzi o to że ta emulowana EEPROM po pewnym czasie (ilości zapisów) wykazuje, moim zdaniem absurdalnie długie czasy zapisów pojedynczych słów (rzędu sekund 8-O ):

    [TM4C1231D5PM] Zużycie EEPROM

    Co raczej definitywnie kładzie opisywane tu na wątku koncepcje dotyczące zapisu do EEPROM np. w reakcji na zanik zasilania (podtrzymanie kondensatorem itd. ).
    Tym gorzej że ta progresja czasu zapisu następuje już na etapie dłuższej eksploatacji urządzenia i może nie być widoczna przy testach fabrycznych.

    Ale konkretnie czy do Twojego projektu, taka pamięć EEPROM z jej cechami się nada, to już zależy od szczegółów których tu nie przedstawiłeś. Tak że musisz ocenić sam.
  • #16
    User removed account
    User removed account  
  • Helpful post
    #17
    rb401
    Level 38  
    Piotrus_999 wrote:
    Robiąc poważny projekt, który ma pracować lata należy kupić eeprom za kilka centów i zapomnieć o problemach.


    Jak już, to raczej FRAM za trochę więcej centów.
    Ale osobiście raczej bym tak radykalnie nie stawiał sprawy wewnętrzny/zewnętrzny EEPROM. EEPROMy wbudowane w uC mają jakieś tam gwarantowane parametry i w zasadzie to od filozofii projektu (jakiego rodzaju są te dane zrzucane do EEPROM i kiedy) zależy czy urządzenie będzie niezawodne czy nie.
    A na przykład patrząc z drugiej strony, to dokładanie pamięci z zewnątrz, może zmniejszać niezawodność całości, mnożąc elementy.
    Tak że tu, mogę tylko podpowiedzieć, że zrzucanie jakiś zmiennych do EEPROMa w Tivii w reakcji na zanik zasilania to niezbyt szczęśliwy pomysł. Ale w innym zastosowaniu ta pamięć może być całkiem ok.
  • #18
    Pan Korsarz
    Level 3  
    Dobrze, że temat kondensatora mamy za sobą (długi czas zapisu przy większej eksploatacji pamięci) bo większość dyskusji nie była na temat tak jak zauważył Piotrus_999, choć rozumiem i doceniam chęć pomocy w sposób inny niż jest to przewidziane w temacie i projekcie. Dziękuje rb401 za zaangażowanie w temat.

    Wracając do dyskusji nie będzie to tak ekstremalne katowanie pamięci rzędu 9330 / sek. tak jak tu Panowie wspominali, będzie to ok. 50 zapisów dziennie.
    Jednak maszyna ta ma być projektowana na >10 lat. Z obliczeń wynika, że pamięć powinna to wytrzymać bez kombinowania, ale nie wiem czy pomimo to nie będzie wymogu stworzenia algorytmu "chodzenia" po adresach aby SOFTWAROWO zwiększyć liczbę możliwych zapisów.
    I teraz pytanie czy ten algorytm w przypadku tego procka ma w ogóle rację bytu bo tak jak wspomniał rb401:
    Quote:
    "I tu osobiście dostrzegam pewien problem. Jeśli byś na tą emulację, która jakoś tam działa, nałożył swój algorytm "chodzenia po adresach" to i tak nie można by mieć gwarancji że znacząco zwiększy się wytrzymałość pamięci, w stopniu takim jakby chodziło o prawdziwy EEPROM gdzie wytrzymałość dotyczy każdej komórki z osobna. "


    Bo w normalnym przypadku (gdyby ten EEPROM potraktować jak zwykły) wyglądało by to chyba tak, że: mój program zapisuje 2 zmienne uint32_t oraz 3 zmienne uint8_t (tylko jedna z nich nadpisywana jest te 50 razy reszta to konfiguracja) więc łącznie te zmienne zajmują 88 bajtów (2*32 + 3*8) więc zajmują 2 pierwsze bloki, bo jeden blok ma 64 bajty a adresowanie zaczynam od 0x0000.
    [TM4C1231D5PM] Zużycie EEPROM
    I po wykonaniu iluś tysięcy zapisów (bo odczytywać z EEPROM można ile się chce) zmieniłbym adresowanie, żeby zaczynało się od 3 bloku. (Poprawcie mnie jeśli się mylę, tak jak wspominałem nie pracowałem jeszcze z EEPROM).
    I ostatecznie, czy tu da się też zrobić taki manewr czy nie pozwoli na to wspomniana emulacja ?
  • #19
    rb401
    Level 38  
    Pan Korsarz wrote:
    będzie to ok. 50 zapisów dziennie.
    Jednak maszyna ta ma być projektowana na >10 lat. Z obliczeń wynika, że pamięć powinna to wytrzymać bez kombinowania, ale nie wiem czy pomimo to nie będzie wymogu stworzenia algorytmu "chodzenia" po adresach aby SOFTWAROWO zwiększyć liczbę możliwych zapisów.


    Czyli circa 180k zapisów, uwzględniając margines na niedoszacowania i fakt że nie zapisujesz tylko jednego słowa tylko ponad blok, to może być kiepsko.
    Zauważ że oznaczając ilość zapisów (te 500k) producent już stawia warunek cyrkulacji po stronach ("Endurance of 500K writes when writing at fixed offset in every alternate page in circular fashion"). A zapis w to samo fizycznie miejsce na stronie skutkuje tym że po każdych 7 zapisach w tą samą komórkę, cała strona jest kopiowana do bufora, kasowana i odtwarzana z najnowszych wersji zmiennych. A właśnie ilość kasowań przekłada się na żywotność pamięci.
    A jeśli zapisujesz powyżej bloku, to na tyle co rozumiem tą dokumentację, jest ryzyko że limit zapisów takich porcji zmiennych ponad pojemność bloku, uwzględniając cyrkulację, będzie być może mniejszy niż te katalogowe 500k.
    Do tego dochodzi ewentualnie (zależy od filozofii projektu) jeszcze kwestia zachowania spójności danych, tzn. zabezpieczenia się przed sytuacją kiedy z jakiś powodów nie zostaje zapisany cały komplet danych tylko jego część i informacja odczytana później jest mieszanką ostatnio i przedostatnio zapisanych danych.
    Czasami może być to szkodliwe i by się tego ustrzec potrzebny jest pewien narzut danych (np. dodatkowe indeksy). Ale to osobne zagadnienie.



    Pan Korsarz wrote:
    I ostatecznie, czy tu da się też zrobić taki manewr czy nie pozwoli na to wspomniana emulacja ?

    Emulacja Ciebie nie limituje jak i gdzie chcesz zapisać. Po prostu wpisujesz do rejestrów (blok i offset) adres słowa i piszesz. Jedynie wisi nad głową jak ten miecz Damoklesa, problem endurance.



    Ale jest tu jeszcze dużo istotniejsza sprawa, wręcz niepokojąca. W erracie w kwestii EEPROM jest bardzo ważna uwaga o tym, że reset czy zanik zasilania podczas zapisu do EEPROM może nawet trwale uszkodzić uC, a w łagodnych wypadkach tylko zakłócić jej zawartość. Uwzględniając jeszcze fakt że z upływem czasu eksploatacji (ilości cykli zapisu) rośnie czas tej operacji osiągając w niekorzystnych przypadkach nawet do ok. dwóch sekund, jeśli zapisuje się stosunkowo często a urządzenie nie ma podtrzymania zasilania, to prawdopodobieństwo uszkodzenia uC staje się bardzo realne.
    Co prawda dotyczy to rewizji 6 krzemu, przedostatniej. Ale jeśli masz możliwość to sprawdź, jakie kostki będą montowane u Ciebie i jeśli to wersja 6, to w ogóle nie polecam zabawy z tym wewnętrznym EEPROMem bo to wręcz proszenie się o grube kłopoty.

    [TM4C1231D5PM] Zużycie EEPROM


    Bardzo ciekawe są zalecane przez ludzi z TI workarounds.
    A szczególnie czwarty punkt, który w ciemno zasugerował tu wyżej kolega Piotrus_999 :wink:

    Osobiście im bardziej się wczytuję w tą dokumentację TI, to tym bardziej przyznaje mu rację (oczywiście w stosunku do uC z TI). Owszem ten EEPROM jest bardzo fajny na przechowywanie mało zmienianych danych a szczególnie jeśli są to dane tajne, bo są mocne zabezpieczenia. Ale do częstych zapisów to jakoś nie bardzo.
  • #20
    Pan Korsarz
    Level 3  
    Quote:
    Emulacja Ciebie nie limituje jak i gdzie chcesz zapisać. Po prostu wpisujesz do rejestrów (blok i offset) adres słowa i piszesz. Jedynie wisi nad głową jak ten miecz Damoklesa, problem endurance.


    Więc nie ma gwarancji, że nawet jeśli wprowadzę w życie wspomniany algorytm to on wydłuży to czas działania tej pamięci, jak by to było w przypadku "normalnego" np. zewnętrznego EEPROMU ?
  • #21
    rb401
    Level 38  
    Pan Korsarz wrote:
    Więc nie ma gwarancji, że nawet jeśli wprowadzę w życie wspomniany algorytm to on wydłuży to czas działania tej pamięci,


    Jeśli będzie zgodny z filozofią tego EEPROM wyłożonej w dokumentacji, to jakoś wydłuży.

    Ale też zauważ że wprowadzając jakąś tam cyrkulację w pamięci, zwiększy się też ilość zapisywanych danych, bo musisz również w jakiś sposób zapamiętywać np. ilość użytych zapisów i/lub położenie w pamięci ostatnio wpisanych danych (jeśli cyrkulować przy każdym zapisie). Które to z kolei, jest dodatkowym sporym obciążeniem dla EEPROM, bo musisz tą informacje aktualizować za każdym razem jeśli zapisujesz jakiekolwiek dane. A tą informację np. licznik użytych cykli zapisu, także nie możesz trzymać w jednej i tej samej komórce, bo zamęczysz blok w którym się ona znajduje.
    Czyli, jednym słowem, pod górkę jest. Tym gorzej że to, czy koncepcja jaką się wybierze jest dobra, okaże się po latach.
  • #22
    User removed account
    User removed account  
  • #23
    Pan Korsarz
    Level 3  
    Quote:
    Po prostu wpisujesz do rejestrów (blok i offset) adres słowa i piszesz.

    Rozumiem że wprowadzam adres bloku do którego chcę zapisać, ale nie wiem dlaczego do tej procedury wymagany jest "offset" za co on jest odpowiedzialny?
  • #24
    rb401
    Level 38  
    Pan Korsarz wrote:
    adres bloku do którego chcę zapisać, ale nie wiem dlaczego do tej procedury wymagany jest "offset" za co on jest odpowiedzialny?


    Zauważ że odczytując czy zapisując konkretną komórkę (słowo 32b) musisz wybrać o którą (jedną z 512) Ci chodzi. Adres komórki, w tym przypadku 9bitowy jest z pewnych względów rozdzielony na dwa rejestry. Cztery najmłodsze bity adresu wpisuje się do EEOFFSET a pięć starszych do EEBLOCK.
    Nawet jeśli byś chciał hurtem czytać/zapisać cały blok od jego pierwszej komórki korzystając z mechanizmu autoinkrementacji adresu, to i tak na początku musisz wpisać do EEOFFSET zero. Pamiętając też że autoinkrementacja działa tylko na rejestr EEOFFSET. By używać jej do dłuższych niż blok seryjnych operacji i tak musisz "ręcznie" zmieniać EEBLOCK jeśli obrobiłeś ostatnią komórkę bloku.