Az I2C slave címe nincs megerősítve (néha)

Próbálok kommunikálni egy távolról csatlakoztatott FRAM-mal (FM24C04 a Ramtrontól) az I2C-n keresztül. Ez a memória egy olyan kártyába van ágyazva, amely bármikor behelyezhető és eltávolítható a rendszerből (a memória eltávolítása előtt a kommunikáció megfelelően megszakad).

A probléma a következő: Közvetlenül a kártya behelyezése után, amely tartalmazza a FRAM-ot, a címet néha nem megerősített.

Jelmérések

Mértem a jeleket, hogy lássam, mi történt, és úgy tűnik, hogy az időzítés mindkét esetben rendben van (munka és nem munka).

Helyes I2C kommunikáció (3 bájt olvasás):

nincs

Az I2C FRAM cím nem lett megerősítve (a rabszolga címe helyesen lett elküldve):

A probléma megoldására már megtett intézkedések (sikertelenek)

  • Késleltetés a beágyazott FRAM-mal ellátott kártya behelyezése után az áramellátási sorrend betartásának biztosítása érdekében.
  • Az I2C abbahagyja a generálást, miután felismert egy nem szolga címet

I2C busz konfiguráció

  • Egy master (STM32F205 mikrovezérlő az ST-től)
  • Három rabszolga (EEPROM 24AA1025 a Microchip-től, RTC DS1339C a Maxim IC-től és a távoli FRAM FM24C04 a Ramtron-tól
  • Az I2C szintű váltó (MAX3373E a Maxim IC-től) lehetővé teszi a kommunikációt a master és a FRAM között
  • A busz frekvenciája 100 kHz-re van állítva

SZERKESZTETT (2013-04-17)

Először is, nagyon köszönöm a megjegyzéseket.

Mivel sok javaslat van, íme az általam végzett kutatás leírása.

Rendszer

A következő ábra az I2C busz egyszerűsített sémáját mutatja:

Az I2C_SDA és I2C_SCL jelek közvetlenül a mikrovezérlőhöz, a FRAM_SDA és FRAM_SCL jelek pedig a FRAM-hoz vannak csatlakoztatva. Ne feledje, hogy az FRAM-hoz csatlakoztatott SDA és SCL jeleket Murata BLM18 ferritek segítségével szűrik.

A FRAM az alábbiak szerint csatlakozik:

  • NC (1. érintkező) -> nincs csatlakoztatva
  • A1 (2. tű) -> GND
  • A2 (3. tű) -> GND
  • VSS (4. tű) -> GND
  • SDA (5. tű) -> FRAM_SDA
  • SCL (6. tű) -> FRAM_SCL
  • WP (7. tű) -> GND (nem írásvédett)
  • VDD (8. érintkező) -> + 5V

A FRAM kártya leírása

Ez a kártya egy "ISA-szerű" kártya, amelybe csak a FRAM van beágyazva.

Vizsgálatok

Lassítsa le a frekvenciát

Teszteket futtattam 50kHz és 10kHz SCL frekvenciával. Oszcilloszkóppal mértem az SCL jelet, hogy megbizonyosodjak arról, hogy a várt frekvencián van-e.

Ezek a változások nem oldották meg a problémát. Ellenőriztem az időzítéseket, és azok megfelelnek a FRAM adatlap specifikációinak.

Az aktuális sorrend biztosítása

  1. Az I2C szintű váltót háromállapotú üzemmódba helyezik, mielőtt behelyezik a kártyát, amelybe a FRAM be van ágyazva. A FRAM_SDA és a FRAM_SCL jelek alacsonyra vannak húzva.
  2. A "FRAM kártya" behelyezése után 100 ms késleltetés kerül hozzá, hogy az áramellátás stabilizálódjon (legalább 11 ms szükséges az első indítási feltétel előtt az adatlap szerint).
  3. Az I2C szintváltó be van kapcsolva.
  4. 1 ms késleltetés kerül hozzá annak biztosítására, hogy az I2C szint váltó engedélyezve legyen, és a vonalak magasra húzódjanak (

4us szükséges az adatlap szerint). FRAM_SDA és FRAM_SCL jeleket kapunk.

  • A FRAM elérése folyamatban van.

    • A FRAM_SDA és FRAM_SCL jeleket minden lépés után megmértük.

    A probléma továbbra is fennáll.

    Stop/start feltétel ismételt indítás helyett

    Megpróbáltam megállni, mielőtt újraindítottam volna a bájt átvitele során. Az oszcilloszkóppal mértem a bájtátvitelt: A STOP feltétel, majd a START feltétel rendben van.

    Sajnos ez a megoldás nem oldja meg a problémát.

    gondolatok

    Ez a probléma csak a FRAM-be ágyazott kártya csatlakoztatása után jelentkezik. Több ezer sikeres olvasási hozzáférést hajtottam végre (rabszolga címzés és olvasás), miután a "FRAM kártyát" behelyeztük és helyesen címeztem.

    Számomra egyre inkább hardveres problémának tűnik. Azt azonban nem tudom, hogy ez összefüggésben lehet-e az I2C szintváltóval vagy az I2C busz többi rabszolgájával.

    Van még valami ötleted vagy javaslatod?

    SZERKESZTETT (2013-04-18)

    Úgy tűnik, hogy a probléma megoldódott

    Cseréltem a FRAM modul csatlakozóját, és megtaláltam a módját, hogy közvetlenül a FRAM-on végezzek méréseket. Úgy tűnik, hogy minden jól működik ezzel az új csatlakozóval.

    Több tesztet végzek, hogy megbizonyosodjak arról, hogy a probléma egy rossz társulás miatt van.

    Bár azt mondják, hogy a kommunikációja megfelelően leállt a behelyezés vagy eltávolítás előtt, érdemes megoldani ezt a megoldást, mert az I2C busz csak a visszaállítás után okozhat problémákat a busz egyik eszközén.

    A master I2C hardver inicializálása előtt állítsa be az SDA-t bemenetként, és ellenőrizze, hogy alacsony-e az SDA.

    Ha alacsony, akkor állítsa magasra az SCL csapot.

    Ezután állítsa az SCL csapot alacsonyra és magasra, amíg az SDA magasra nem megy (azaz törölje ki a fennmaradó biteket, amelyeket a perifériák még mindig megpróbálnak elküldeni). Ez 8 óraciklusnál többet nem vehet igénybe. Ha igen, akkor van egy másik probléma.

    Nem tudom garantálni, hogy ez megoldja a problémáját, de az enyémet megoldotta!

    • Először csatlakoztassa a GND-t és a Vcc-t.
    • Ezután ellenőrizze, hogy A1, A2 és WP a megfelelő szinten vannak-e.
    • Csak ezután csatlakoznak az adatcsapok.

    A chip bekapcsolása előtt az áramellátástól eltérő csapok csatlakoztatása problémákat okozhat.

    A 10 ezer forint kissé nagynak tűnik a felhúzásokhoz, és a vezető élek lassan néznek ki. Csökkentse az ellenállást 3k körülire, és hátha ez segít.

    Miért sodródik a kikapcsolási feszültség az idő múlásával?

    Van valami esély arra, hogy valami más próbál beszélni ezzel a fórumon? Egyszer volt ilyen problémám; Az esetek 60% -ában nyugtát kaphattam, de nem emlékszem, hogy valaha is láttam volna ütközést. Gyanítom, hogy a rendelkezésemre bocsátott i2c valamilyen módon el volt szigetelve a valódi belső busztól. Folyamatosan futtathattam, és csak az üzenetek 30% -át törölte. A probléma eltűnt abban a pillanatban, amikor közvetlenül az eszközzel (tápegységgel) beszéltünk, anélkül, hogy a "háttérsík" közte lenne.

    A NAK hiba után nem jelenik meg leállítási sorrend. Gondolom, van egy töréspontja, amely megállítja a programot ezen a ponton?

    Ha úgy gondolja, hogy csak Ön jár a buszon, megpróbálhatja az ismételt rajtot megállással/indítással helyettesíteni. Olyan eszközöket (főleg egyedi FPGA-kat) láttam, amelyek nem tudták pontosan, hogyan kell kezelni az RS-t.

    [Válasz a megjegyzésre]: Nagyon sok mindent nem mondtál el a FRAM kártyáról, például arról, hogy ez csak memória vagy egy teljes alrendszer. De ha a puska hatótávolságát közvetlenül az i2c eszköz kábeleire helyezheti, ami problémákat okoz Önnek, és még mindig láthatja a képen látható képet, kizárnám az interferenciát. Az I2C olyan egyszerű, hogy ha nincs belső problémája, a chipnek megfelelően kell játszania, ha a bemeneten megfelelő jeleket lát.

    Különösen el akar jutni ennek a szintváltónak a FRAM oldalára. A jel megszakadása valószínűbb, mint valami, amelyet általában ütközésként tekintenek.

    Rámutatok, hogy egy NAK ciklus nem különböztethető meg egy chiptől, amely egyszerűen nincs ott. Az EEPROM-ok ezt jelzik, hogy elfoglaltak. Megnéztem az írási időt a FRAM-on, és gyorsabb, mint egyetlen i2c adatbit. szóval ez nem probléma.

    Mivel a lejátszási probléma állandó hiba, amelyet csak az eszköz eltávolításával és újbóli behelyezésével lehet kijavítani, ez két dolog egyike: az eszköz rossz állapotban van, amelyből csak kikapcsolt és bekapcsolt állapotban áll helyre. . vagy gyenge a kapcsolat.

    Ha az eszköz rossz állapotba kerül, amelyet a kikapcsolás és bekapcsolás után helyreáll, akkor további áramköröket kaphat, amelyeket az MCU használhat az eszköz kikapcsolására. Miután a firmware nem kapott megerősítést az eszközről, elvégezhet egy helyreállítási folyamatot, amelyben egy ideig leállítja a chipet, újra bekapcsolja, majd újra megpróbálja.

    Ha a kapcsolat rossz, akkor lehet, hogy ellenőriznie kell a csatlakozó megbízhatóságát, és találni valami jobbat. Ha ugyanazt a csatlakozót használja ezeknek a kártyáknak a készítéséhez, problémákat okozhat a terepen. Mindkét esetben emberi folyamat folyhat a helyzet kezelésére. Az eszközzel dolgozó kezelőnek tisztában kell lennie a kártya behelyezésével kapcsolatos potenciális problémával, és a megfelelő működés érdekében szükség lehet újratelepítésre.

    A fő egység riasztást indíthat, jelezve, hogy nem tud beszélni a FRAM-mal: "hiba" LED a központon és/vagy sípolás vagy bármi más. Vagy fordítva: Olyan fény, amely kigyullad és visszajelzést ad a felhasználónak arról, hogy az FRAM-ot elfogadták és a kommunikáció létrejött. Ha a FRAM messze van a mester eszköztől, akkor a lámpa felgyulladhat a FRAM modulon: egy másik I2C chip, amely LED-et hajt.

    A probléma szórványos jellege arra utal, hogy ez időzítési probléma lehet.

    Az adatlap két idősort tartalmaz, egyet a "normál üzemmódhoz", egyet a "gyors módhoz". A méréseiből látható, hogy a "normál módú" időzítés küszöbén áll. Az adatlapból nem tudom megmondani, hogy a chip pontosan hogyan kerül a két mód egyikébe.

    Nem feltételezném, hogy a készülék gyors módban van. Ha 2-4-szeresére csökkentheti az időzítést, győződjön meg arról, hogy a Start Mode Hold Time, Clock High Period és Clock Low Period normál módú időzítésein belül van, és ellenőrizze, hogy a probléma továbbra is fennáll-e?

    Van 24c04a, b vagy c? Ha ez egy c04a, akkor robusztus kialakítás volt. A b rész érzékeny az áramellátási rámpákra. Melyik leválasztásod van a Pin8-nál? Mondani akartam valamit a jelszintekről, de úgy látom, hogy szintfordítót használ. Érdemes ellenőrizni, hogy nem kap-e olyan hibát az SCL-lel, amelyet a chip kiegészítő órának értelmezne.