Adresa slave I2C nu este confirmată (uneori)

Încerc să comunic cu un FRAM conectat de la distanță (FM24C04 de la Ramtron) prin I2C. Această memorie este încorporată într-un card care poate fi introdus și eliminat din sistem în orice moment (comunicarea este terminată corect înainte ca memoria să fie îndepărtată).

Problema este: Imediat după introducerea cardului care conține FRAM, adresa uneori neconfirmat.

Măsurători de semnal

Am măsurat semnalele pentru a vedea ce s-a întâmplat și se pare că momentele sunt bune în ambele cazuri (funcționează și nu funcționează).

Comunicare I2C corectă (3 octeți citiți):

adresa

Adresa I2C FRAM nu este confirmată (adresa slave este trimisă corect):

Măsuri luate deja pentru rezolvarea acestei probleme (nereușite)

  • S-a adăugat întârzierea după introducerea cardului cu FRAM încorporat pentru a asigura respectarea secvenței de alimentare.
  • I2C nu mai generează după recunoașterea unei adrese slave care nu este recunoscută

Configurarea magistralei I2C

  • Un master (microcontroler STM32F205 de la ST)
  • Trei sclavi (EEPROM 24AA1025 de la Microchip, RTC DS1339C de la Maxim IC și telecomanda FRAM FM24C04 de la Ramtron
  • Un schimbător de nivel I2C (MAX3373E de la Maxim IC) permite comunicarea între master și FRAM
  • Frecvența autobuzului este setată la 100 kHz

EDITAT (17.04.2013)

În primul rând, vă mulțumesc foarte mult pentru comentarii.

Deoarece există multe sugestii, iată descrierea cercetării pe care am făcut-o.

Sistem

Următoarea figură prezintă o schemă simplificată a magistralei I2C:

Semnalele I2C_SDA și I2C_SCL sunt conectate direct la microcontroler, iar semnalele FRAM_SDA și FRAM_SCL sunt conectate la FRAM. Rețineți că semnalele SDA și SCL conectate la FRAM sunt filtrate folosind ferite Murata BLM18.

FRAM este conectat după cum urmează:

  • NC (pinul 1) -> nu este conectat
  • A1 (pinul 2) -> GND
  • A2 (pinul 3) -> GND
  • VSS (pinul 4) -> GND
  • SDA (pinul 5) -> FRAM_SDA
  • SCL (pinul 6) -> FRAM_SCL
  • WP (Pin 7) -> GND (nu este protejat la scriere)
  • VDD (pinul 8) -> + 5V

Descrierea cardului FRAM

Acest card este un card „de tip ISA” în care este încorporat doar FRAM.

Investigații

Încetiniți frecvența

Am efectuat teste cu o frecvență SCL de 50kHz și 10kHz. Am măsurat semnalul SCL cu un osciloscop pentru a mă asigura că este la frecvența așteptată.

Aceste modificări nu au rezolvat problema. Am verificat calendarele și acestea se încadrează în specificațiile fișei tehnice FRAM.

Asigurarea secvenței curente

  1. Schimbatorul de nivel I2C este plasat în modul cu trei stări înainte de introducerea cardului în care este încorporat FRAM. Semnalele FRAM_SDA și FRAM_SCL sunt reduse.
  2. După introducerea „cardului FRAM”, se adaugă o întârziere de 100 ms pentru a se asigura că sursa de alimentare este stabilizată (necesară cel puțin 11 ms înainte de prima condiție de pornire conform fișei tehnice).
  3. Schimbatorul de nivel I2C este activat.
  4. Se adaugă o întârziere de 1 ms pentru a se asigura că schimbătorul de nivel I2C este activat și că liniile sunt trase în sus (

4us este necesar conform fișei tehnice). Se obțin semnale FRAM_SDA și FRAM_SCL.

  • FRAM este accesat.

    • Semnalele FRAM_SDA și FRAM_SCL au fost măsurate după fiecare pas.

    Problema apare încă.

    Condiție de oprire/pornire în loc de pornire repetată

    Am încercat să mă opresc înainte de a reporni în timpul transferului de octeți. Am măsurat transferul de octeți cu osciloscopul: starea STOP urmată de starea START este OK.

    Din păcate, această soluție nu rezolvă problema.

    gânduri

    Această problemă apare numai după ce cardul încorporat în FRAM a fost conectat. Am efectuat câteva mii de accesări de citire reușite (adresarea și citirea sclavilor) după ce „cardul FRAM” a fost introdus și corect adresat.

    Mi se pare din ce în ce mai mult ca o problemă hardware. Cu toate acestea, nu știu dacă acest lucru ar putea fi legat de schimbătorul de nivel I2C sau de ceilalți sclavi de pe magistrala I2C.

    Aveți alte idei sau sugestii?

    EDITAT (18.04.2013)

    Problema pare a fi rezolvată

    Am schimbat conectorul modulului FRAM și am găsit o modalitate de a face măsurători direct pe FRAM. Se pare că totul funcționează bine cu acest nou conector.

    Voi face mai multe teste pentru a mă asigura că problema se datorează unei asociații proaste.

    Deși spun că comunicațiile dvs. au fost închise corect înainte de a fi introduse sau eliminate, această soluție ar merita încercată, deoarece magistrala I2C poate provoca probleme la unul dintre dispozitivele de pe autobuz după o resetare.

    Înainte de inițializarea hardware-ului master I2C, setați SDA ca intrare și testați dacă SDA este scăzut.

    Dacă este scăzut, setați pinul SCL la înălțime.

    Apoi comutați pinul SCL în jos și în sus până când SDA crește (de exemplu, ștergeți orice biți rămași pe care perifericele ar putea încă să încerce să îi trimită). Acest lucru nu poate dura mai mult de 8 cicluri de ceas. Dacă da, există o altă problemă.

    Nu pot garanta că acest lucru va rezolva problema dvs., dar a rezolvat-o pe a mea!

    • Mai întâi conectați GND și Vcc.
    • Apoi asigurați-vă că A1, A2 și WP sunt la nivelul corect.
    • Abia atunci se conectează pinii de date.

    Conectarea pinilor diferiți de sursa de alimentare înainte de a porni cipul poate cauza probleme.

    10k pare cam mare pentru pull-up-urile dvs., iar marginile din față arată lent. Reduceți rezistențele la aproximativ 3k și vedeți dacă acest lucru vă ajută.

    De ce tensiunea de oprire derivă în timp?

    Există vreo șansă ca altceva să încerce să discute cu acest forum? Am avut o astfel de problemă odată; Aș putea primi o confirmare 60% din timp, dar nu-mi amintesc să fi văzut vreodată o coliziune. Bănuiesc că i2c furnizat mie mi-a fost cumva izolat de autobuzul intern real. Aș putea să-l rulez continuu și ar șterge doar 30% din mesaje. Problema a dispărut în momentul în care am vorbit direct cu dispozitivul (o sursă de alimentare) fără „panoul de fundal” între ele.

    Nicio secvență de oprire nu va fi afișată după eroarea dvs. NAK. Bănuiesc că aveți un punct de întrerupere care oprește programul în acel moment?

    Dacă credeți că sunteți singurul din autobuz, puteți încerca, de asemenea, să înlocuiți pornirea repetată cu o oprire/pornire. Am văzut dispozitive (în special FPGA personalizate) care nu știau exact cum să gestioneze RS.

    [Răspunde la comentariu]: Există multe lucruri pe care nu le-ai spus despre cardul FRAM, de exemplu, dacă este vorba doar de memorie sau de un subsistem întreg. Dar dacă puteți pune luneta direct pe cablurile dispozitivului i2c care vă provoacă probleme și puteți vedea totuși ce este imaginat, aș exclude interferențele. I2C este atât de simplu încât, cu excepția cazului în care aveți o problemă internă, cipul ar trebui să ruleze corect dacă vedeți semnalele corecte pe intrare.

    În special, doriți să accesați pagina FRAM a acestui schimbător de nivel. O întrerupere a semnalului este mai probabilă decât ceva care este privit în mod normal ca o coliziune.

    Voi sublinia că un ciclu NAK nu se distinge de un cip care pur și simplu nu există. EEPROM fac acest lucru pentru a indica faptul că sunt ocupați. Am căutat timpul de scriere pe FRAM și este mai rapid decât un singur bit de date i2c. deci nu este o problemă.

    Deoarece problema de redare este o eroare persistentă care poate fi rezolvată doar prin îndepărtarea și reintroducerea dispozitivului, este unul dintre cele două lucruri: dispozitivul se află într-o stare proastă, din care se recuperează numai când este oprit și pornit . sau există un contact slab.

    Dacă dispozitivul intră într-o stare proastă pe care o recuperează atunci când este oprit și pornit, atunci puteți avea circuite suplimentare pe care MCU-ul dvs. le poate folosi pentru a opri dispozitivul. Firmware-ul, după ce nu primește o confirmare de pe dispozitiv, poate efectua apoi un proces de recuperare în care oprește cipul pentru o perioadă de timp, îl pornește din nou și apoi încearcă din nou.

    Dacă contactul este rău, poate fi necesar să verificați fiabilitatea conectorului și să găsiți ceva mai bun. Utilizarea aceluiași conector pentru a face mai multe dintre aceste carduri poate cauza probleme pe teren. În ambele cazuri, poate exista un proces uman pentru a face față situației. Operatorul care lucrează cu dispozitivul trebuie să fie conștient de problema potențială cu introducerea cardului și poate fi necesar să fie reintrodus pentru a funcționa corect.

    Unitatea principală poate declanșa o alarmă care indică faptul că nu poate vorbi cu FRAM: un LED de „eroare” pe un panou de control și/sau un semnal sonor sau orice altceva. Sau invers: O lumină care se aprinde și oferă utilizatorului feedback că FRAM a fost acceptat și că comunicarea a fost stabilită. Dacă FRAM este departe de dispozitivul master, lumina poate fi pe modulul FRAM: un alt cip I2C care acționează un LED.

    Natura sporadică a problemei sugerează că ar putea fi o problemă de sincronizare.

    Fișa tehnică conține două serii temporale, una pentru „modul standard” și una pentru „modul rapid”. Din măsurătorile dvs. se poate observa că sunteți la un pas de „modul standard”. Din foaia tehnică nu pot spune cum este pus exact cipul într-unul dintre cele două moduri.

    Nu aș presupune că dispozitivul dvs. este în modul rapid. Dacă puteți reduce temporizările cu un factor de 2-4, asigurați-vă că vă aflați în intervalele de timp standard pentru Start Status Hold Time, Clock High Period și Clock Low Period și vedeți dacă această problemă persistă?

    Aveți un 24c04a, b sau c? Dacă este un c04a, a fost un design robust. Partea b este sensibilă la rampele de alimentare. Ce decuplare aveți la Pin8? Am vrut să spun ceva despre nivelurile de semnal, dar văd că utilizați un traducător de niveluri. Poate doriți să verificați dacă nu primiți o eroare cu SCL pe care cipul ar interpreta-o ca un ceas suplimentar.