Jste zde

Možné problémy při komunikaci s I2C EEPROM

Jak správně řešit rutinu pro čtení ze sériové EEPROM, aby zařízení odolalo i v reálných

průmyslových podmínkách.

    Shrnutí
    Při zápisu procesoru do EEPROM, pošle START BIT a poté CONTROL BYTE. Následuje ADRESA a zapisovaná DATA.  Komunikaci s pamětí ukončí procesor STOP BITem. 
    Při opačném toku dat, kdy procesor čte data pošle START BIT, CONTROL BYTE  a ADRESU poté START BIT, CONTROL BYTE a nyní generuje hodinové impulsy, protože očekává z EEPROM data. Jediný rozdíl mezi čtením a zápisem je tedy onen START BIT který vysílá procesor po vyslání adresy. 

    Tento způsob ovládání sériové EEPROM doporučují ve svých aplikačních listech přední výrobci. (například Microchip). 
    Problém nastává v okamžiku, kdy z nějakých důvodů nezachytí EEPROM onen START BIT. Důvodů může být mnoho, přeslech mezi dvěma vodiči na plošném spoji (ne všichni umisťují podobné vodiče do dostatečné vzdálenosti od adres a dat, případně napájecí části atd..) 

    Pokud tedy EEPROM "přeslechne" onen START BIT předpokládá, že se jedná o zápis a na paměťové místo do kterého jste chtěli číst zapíše FF. Sbohem nejčastěji čtené kalibrační parametry..

    Přitom existuje elegantní řešení

    • Sekvenci pro ovládání čtení z EEPROM stačí mírně upravit. Po odeslání START BITu, CONTROL BYTE a ADRESe nepoužít ihned START BIT jak doporučují výrobci, ale vygenerovat nejprve STOP BIT a po něm znovu START BIT. Pokud existuje výše zmíněné rušení a EEPROM nerozezná START BIT, byla komunikace korektně ukončena. V opačném případě vše funguje s malým zpožděním. 


      Je fakt, že při nerozpoznání START BITu načte procesor hodnotu FF. To však lze softwarově ošetřit a v takovém případě čtení zopakovat. 
      Tento odstavec bych právě očekával v aplikačním listu seriózního výrobce.
       

    • Jinou možností je používat I2C EEPROM s HW zablokovaným zápisem, například pomocí spec. Pinu z procesoru. Tím se problém nechtěného přepsání konstant ošetří takřka stoprocentně. 
       
    • Třetí a poslední možností je nepoužívat Philipsácké I2C které příliš nepočítá s reálnými podmínkami. SPI EEPROM však potřebují více pinů a to není vždy z hardwarového hlediska splnitelné. 
      Požadavek na více pinů samozřejmě neplatí, pokud spojíte DI a DO přes rezistor. SPI EEPROM se však běžně vyrábějí ve výrazně menších kapacitách oproti I2C 24xx. 25xx, které by kapacitní požadavky uspokojili je problém běžně koupit v přijatelných cenových relacích.
    Softwarové řešení výše popsaného problému spočívá v detekci popsané chyby. Například u EEPROM 24LC04 - čtení  z dolních 256B - vrátí výše popsaná chyba sekvenci : #A1, #FF,... (#A1 je control byte pro RD dolních 256 B z 24LC04).  Dobrých výsledků lze také dosáhnout použitím kontrolního mechanizmu například CRC.  V případě problémů pomůže samozřejmě snížení komunikační rychlosti z 400 kHz na cca 100 kHz a nahrazení odporů 4k7 menší hodnotou, například 2k2. 

    A na závěr ještě upozornění. Velmi dobře si všímejte rozdílů mezi jednotlivými I2C EEPROM různých výrobců. 24C256 od ATMELu má nastavitelnou adresu omezenou na rozsah 0-3, zatímco tentýž obvod od Microchipu je adresovatelný v rozsahu 0-7. 
    Jiným příkladem je 24C04 s Write Protect ochranou pro celý adresní prostor, 24C04A (Microchip) má však ochráněnou pouze horní polovinu. Existuje dokonce 24X04J který na Write Protect nebere vůbec zřetel…

    Doufám že tyto naše poznatky pomohou vysvětlit "záhadné" chyby v pamatování si I2C EEPROM  a programátorům pomohou vytvořit odolnější SW proti vnějším vlivům.
     
    Ing. Martin Kubecka
    NEKO spol. s r.o.
Hodnocení článku: