Dahili EEPROM'u Ne Şekilde Kullanıyorsunuz?

[Tagli]

Ayrıca bazı algoritmalar ile bir bitlik veri bozulmaları telafi edilebiliyor.

Konudan biraz uzaklaşmış olacağız ama buna bir örnek vermek istedim: STM32G serilerinin flash'larında böyle bir güvenlik önlemi var. Emin değilim ama galiba bunlar F serilerindeki gibi NOR flash değil, NAND flash kullanıyorlar ve bunun doğası gereği bozuk bit barındırma ihtimali daha yüksek. Bu sebeple flash bellek her 64 bit için ek olarak bir 8 bit daha ECC (error correction code) içeriyor. Flash üzerindeki okuma ve yazma işlemleri 72 bit (8 byte + ECC) şeklinde yapılıyor. 1 bitlik hatalar otomatik düzeltiliyor ve istenirse kesme oluşturuluyor. 2 bit hatalarda ise işlemci NMI'a (non-maskable interrupt) düşüyor - sanırım pek sık olmuyordur bu.

[yas]

@yas'ın belirttiği durum komponente göre çok fark ediyor. Mesela 24AA65 ürünü için datasheet: "Data Retention > 200 years" demiş.

Anlatmaya çalıştıklarım yanlış anlaşılmasın. Ben bit tutucuları ifade etmeye çalışırken sadece mosfet transistör örneğinden yola çıkarak anlatım yaptım. Bu mekanizmalarda mosfet kullanılıyor gibi bir idaam yok. Anlatımı kısa tutabilmek için çok basit anlatmaya çalıştım. Yoksa hafıza birimlerinin çok daha gelişmiş mekanizmalar barındırdığı aşikar.

[Erol YILMAZ]

...Emin değilim ama galiba bunlar F serilerindeki gibi NOR flash değil, NAND flash kullanıyorlar ve bunun doğası gereği bozuk bit barındırma ihtimali daha yüksek. Bu sebeple flash bellek her 64 bit için ek olarak bir 8 bit daha ECC (error correction code) içeriyor. Flash üzerindeki okuma ve yazma işlemleri 72 bit (8 byte + ECC) şeklinde yapılıyor. 1 bitlik hatalar otomatik düzeltiliyor ve istenirse kesme oluşturuluyor. 2 bit hatalarda ise işlemci NMI'a (non-maskable interrupt) düşüyor - sanırım pek sık olmuyordur bu.

NAND flash dedin, kalbimizi kıracaktın az kalsın...

STM32G serisinin Flash tipi NAND değil; embedded Flash / eFlash'tır.
STM32G0 90 nm node üzerinde, STM32G4 için kamuya açık bilgi 90 nm eFlash Generic TSMC yönünde.
Bu bellek sistem davranışı olarak NOR-like program Flash'tır:
memory-mapped okunur, CPU kod çalıştırır, page/bank erase ve double-word programlama yapılır,
ECC/ART/prefetch gibi MCU Flash controller özellikleri vardır.

[Tagli]

eFlash'ı duymamıştım daha önce. Metin yapay zeka cevabına benziyor. O mesajı yazdığım dönemde soracak YZ'miz yoktu. ECC eklemiş olmaları, flash'ta üretim hataları olabileceğini düşündürdü. Bu da bildiğim kadarıyla NAND'ların karakteri, NOR'ların değil. NOR'larda üretim hatası olmuyor diye biliyorum. Ama tabi ECC'yi başka bir sebeple eklemiş de olabilirler. Belki bazı güvenlik standartlarına uyması için gerekiyordur, functional safety için falan...

[RaMu]

Yazılanların tamamını okudum, iki yıl olmuş @Tagli peki kısaca nasıl kullananıyorsunuz şu an eepromu?
Bende eeprom işi için kendi kütüphanemi yazayım diye düşünüyordum bir ara sonra vazgeçtim.

[Tagli]

Projelerimde biraz da ihtiyaçlara bağlı olarak tarihsel süreç şöyle gelişti:

1) Önceki mesajlarımda bahsettiğim key-value mantığı ile çalışan flash belleğe özgü bir yapım zaten vardı.

2) Aradan geçen 4 yıllık süreçte bu flash kütüphanesini sanırım 1-2 kez yeniden yapılandırdım ve backend diyebileceğimiz yapıyı bir donanım soyutlama katmanı ile ana mantıktan ayırdım.

3) Üzerinde çalıştığım proje bir motor sürücü idi. İşlemci STM32F446. Dahili EEPROM yok. Flash dual bank değil. Motor çalışırken kayıt sebebiyle işlemcinin kısa süreli olarak bile donmasına izin veremezdim. Motor çalışırken parametre kaydına izin vermemek de yazılımı fazla karıştıracaktı. Harici EEPROM kullanmaya karar verdim.

4) Flash için olan kütüphaneye EEPROM backend'i ekledim. Yani EERPOM'un bağımsız yazılabilme avantajını kullanmadım, sanki bir flash gibi eriştim ona da. Ama donanım soyutlaması sayesinde harici EEPROM'a kayıt yapılırken veya page'ler arasında veri taşınırken bile işlemcinin normal çalışmasına devam etmesini sağladım. Bu tabi ki kendi geliştirdiğim olay tabanlı bir framework sayesinde mümkün oldu.

5) Daha sonra üstteki key-value arayüzünü dokunmadan, aynı kütüphanenin "lite" versiyonunu yaptım. Bu sadece EEPROM'da çalışabilecek basitleştirilmiş bir versiyon. Wear leveling'ten vazgeçtim. Ön tanımlı bir blok boyutu için CRC korumalı ve her kaydı iki blokta saklayan bir yapıya geçtim. Tek-çift gibi düşünün, her kaydın iki slotu var, bir ona bir buna yazılıyor. Yazım sırasında bir sorun çıkarsa eski kayıt diğer slottan sağlam bir şekilde okunabiliyor.

6) Arada bir noktada debug amaçlı olarak bir de yalancı RAM backend'i ekledim. Buraya yapılan kayıtlar RAM'de bilinen bir adrese düşüyor, ben de debugger ile bağlanıp RAM'i okuyarak algoritmanın doğru çalışıp çalışmadığını kontrol edebiliyorum. Özellikle flash kodundaki bug'ları çözerken faydalı oldu.

[RaMu]

Bende özellikle wear leveling ve encryption ile uğraşamayacağımı görünce vazgeçmiştim.

5) için: İki slota yazıp son yazılan slot hangi grup bilgisinide kayıt edip besleme-enerji kaybı olduğunda algılama ve koruma (kapasitör vs.) olmadan, kesintiden önceki son doğru kaydedilmiş veriye ulaşıyorsunuz anladığım kadarıyla, birçok proje için yeterli ve makul görünüyor.

[kimlenbu]

Stm32'lerde Eeprom emulation kütüphaneleri var, iki bank kullanıp birisine geçerli adres, diğerine veri yazıyor ama ben modlayıp her seferinde page erase yapmadan,her byte'ı bağımsız olarak kullandım.

Wear protection kullanmadım çünkü çıkış baudrate, çıkış tipi, çalışma tipi gibi neredeyse sadece cihaz kurulurken kullanılacak ayarları tutuyorlar, gidip devamlı veri yazacaksam ya harici eeprom ya da daha büyük log tutacaksam sd kart kullandım.

data güvenliği için de 2 farklı alana yazıp hem kullanmadan önce iki içeriği karşılaştırıyorum hem de değer istediğim aralıkta mı diye kontrol ediyorum, bugüne kadar sıkıntı yaşamadım.

tek kötü yanı geliştirme esnasında yeni program attığınızda, komple içeriği sildiği için bunun önlemini alıp veri blogunda olmaması gereken "0xFF" değeri görürse varsayılan ayarlara geri dönmesini sağlamak zaman kazandırıyor.

Tasarımda sonradan ortaya çıkan müşteri istekleri dışında da Eeprom emulation kullanmıyorum

[Erhan YILMAZ]

Yalan olmasın, ben çıraklık yaparken beko 298 marka yazarkasalarda vardı. 2200uf kondastörden önce sinyal giderdi mcuya. Elektrik gitti naparsan yap diye. O ara mcu gereken her şeyi yapardı. İşin içinde maliye falan vardı. Epromlar ziftin içindeydi. Kasayı açmak için mührü sökmek gerekiyordu..

[JKramer]

Stm32'lerde Eeprom emulation kütüphaneleri var, iki bank kullanıp birisine geçerli adres, diğerine veri yazıyor ama ben modlayıp her seferinde page erase yapmadan,her byte'ı bağımsız olarak kullandım.

O kütüphanede bir hata vardı, yıllarca düzeltmedi stm. Başkası yazmazsa bakarım yarın.

[Tagli]

tek kötü yanı geliştirme esnasında yeni program attığınızda, komple içeriği sildiği için bunun önlemini alıp

Bununla ilgili yaptığım 2 şey var:

1) EEPROM emülasyonu için kullanacağım bölgeyi linker script'te ayrı bir alan olarak tanımlıyorum. Derleyici bu adrese dokunmuyor. Programlayıcı yazılımlar da (STM32CubeProg falan) genelde sadece .elf ya da .hex içinde değinilen adreslerin banklarını silip programlayacak kadar zekiler. Komple flash'ı sil gibi bir komut verilmediği sürece EEPROM emülasyon bölgelerine (kalıcı bellek diyelim) bir şey olmuyor.

2) Bazen yazılım değişiklikleri kalıcı bellekteki key-value çiftlerini geçersiz kılıyor. Atıyorum, yazılımın eski versiyonunda 3 numaralı kayıt PID katsayıları iken, yeni versiyonda 3 numaralı kayıtta max sıcaklık vardır da PID katsayıları artık 4 numaralı kayıttadır. Bu konuda kütüphanenin bir sorumluluğu yok. Oraya bir şey eklemedim. Ama uygulama tarafında (client diyelim) bu tür kayıtlara bir de versiyon numarası ekliyorum. Bu kaydın anlamı değişmişse versiyon numarasını 1 arttırıyorum. Kalıcı bellekten okuduğum kaydın versiyon numarası, güncel firmware'deki ile tutmazsa o kaydı yok sayıp varsayılan değerleri kullanıyorum.

2. madde harici EEPROM kullanıldığı durumlar için de gerekli bu arada.

[JKramer]

O kütüphanede bir hata vardı, yıllarca düzeltmedi stm. Başkası yazmazsa bakarım yarın.

Sorun `EE_VerifyPageFullyErased` fonksiyonundaydı, lütfedip 2022 yılında düzeltmişler gibi görünüyor: https://github.com/STMicroelectronics/STM32CubeF1/issues/11