Indirizzo slave I2C non riconosciuto (a volte)

Sto cercando di comunicare con una FRAM connessa in remoto (FM24C04 da Ramtron) utilizzando I2C. Questa memoria è incorporata su una scheda che può essere inserita e rimossa in qualsiasi momento al / dal sistema (la comunicazione viene terminata correttamente prima che la memoria venga rimossa).

Il problema è: subito dopo aver inserito la scheda che contiene la FRAM, a volte , non riconosce l'indirizzo.

Misure dei segnali

Ho misurato i segnali per vedere cosa sta succedendo e sembra che i tempi siano OK in entrambi i casi (funzionante e non funzionante).

Comunicazione I2C corretta (lettura di 3 byte):

Indirizzo FRAM I2C non riconosciuto (indirizzo slave inviato correttamente):

Azioni già intraprese per risolvere questo problema (senza successo)

• Ritardo aggiunto dopo l'inserimento della scheda con FRAM incorporata per garantire il rispetto della sequenza di potenza.
• I2C interrompe la generazione dopo il rilevamento di un indirizzo slave non confermato

Configurazione bus I2C

• Un master (microcontrollore STM32F205 di ST)
• Tre slave (EEPROM 24AA1025 di Microchip, RTC DS1339C di Maxim IC e la FRAM remota FM24C04 di Ramtron
• Un cambio di livello I2C (MAX3373E da Maxim IC) viene utilizzato per consentire la comunicazione tra il master e la FRAM
• Frequenza bus impostata su 100 kHz

EDITED (17-04-2013)

Innanzitutto, grazie a tutti per i vostri commenti.

Dato che ci sono molti suggerimenti, ecco la descrizione delle indagini che ho fatto.

Schematico

L'immagine seguente mostra uno schema semplificato del bus I2C:

I segnali I2C_SDA e I2C_SCL sono direttamente collegati al microcontrollore e i segnali FRAM_SDA e FRAM_SCL sono collegati alla FRAM. Si noti che i segnali SDA e SCL collegati alla FRAM vengono filtrati utilizzando i ferriti BLM18 di Murata.

La FRAM è collegata come segue:

• NC (pin 1) -> non collegato
• A1 (pin 2) -> GND
• A2 (pin 3) -> GND
• VSS (pin 4) -> GND
• SDA (pin 5) -> FRAM_SDA
• SCL (pin 6) -> FRAM_SCL
• WP (pin 7) -> GND (non protetto da scrittura)
• VDD (pin 8) -> + 5V

Descrizione della scheda FRAM

Questa carta è una carta "ISA like" che incorpora solo la FRAM.

indagini

Rallentando la frequenza

Ho eseguito i test con la frequenza SCL impostata su 50kHz e 10kHz. Ho misurato il segnale SCL con un oscilloscopio per assicurarmi che fosse alla frequenza prevista.

Queste modifiche non hanno risolto il problema. Ho controllato i tempi e rientrano nelle specifiche della scheda tecnica FRAM.

Garantire la sequenza di potenza

@jippie.

1. Il cambio di livello I2C viene messo in modalità tre stati prima di inserire la scheda che incorpora la FRAM. I segnali FRAM_SDA e FRAM_SCL sono abbassati.
2. Dopo aver inserito la "scheda FRAM", viene aggiunto un ritardo di 100 ms per garantire che l'alimentazione sia stabilizzata (almeno 11 ms richiesti prima della prima condizione di avvio in base al foglio dati).
3. Il cambio di livello I2C è attivato.
4. Un ritardo di 1 ms viene aggiunto per garantire che il cambio di livello I2C sia attivato e che le linee siano tirate su (~ 4us richiesto dal foglio dati). I segnali FRAM_SDA e FRAM_SCL vengono richiamati.
5. Si accede alla FRAM.

I segnali FRAM_SDA e FRAM_SCL sono stati misurati dopo ogni passaggio.

Il problema si verifica ancora.

Condizione di arresto / avvio anziché avvio ripetuto

@gbarry.

Ho provato a mettere un arresto prima dell'inizio ripetuto durante il trasferimento di byte. Ho misurato il trasferimento di byte con l'oscilloscopio: la condizione STOP seguita dalla condizione START è OK.

Sfortunatamente, questa soluzione non risolve il problema.

Pensieri

Questo problema si verifica solo dopo aver collegato la scheda che incorpora la FRAM. Ho eseguito alcune migliaia di accessi in lettura riusciti (indirizzamento e lettura slave) dopo che la "scheda FRAM" è stata inserita e indirizzata correttamente.

Mi sembra sempre più un problema hardware. Ma non so se potrebbe essere correlato al cambio di livello I2C o agli altri slave sul bus I2C.

Hai altre idee o suggerimenti?

EDITED (18-04-2013)

Il problema sembra risolto

Ho sostituito il connettore del modulo FRAM e ho trovato un modo per eseguire misurazioni direttamente sulla FRAM. Sembra che tutto funzioni bene con questo nuovo connettore.

Farò altri test per essere sicuro che il problema provenga da una cattiva connessione.

Sebbene si dica che le comunicazioni siano terminate correttamente prima dell'inserimento o della rimozione, potrebbe valere la pena provare questa soluzione, poiché esiste una situazione in cui il bus I2C può dare problemi dopo un reset di uno solo dei dispositivi sul bus.

Prima di inizializzare l'hardware Master I2C, impostare SDA come input e testare SDA basso.

Se è basso, impostare il pin SCL alto.

Quindi attiva e disattiva il pin SCL fino a quando SDA diventa alto (ovvero fai fuori i bit rimanenti che le periferiche potrebbero ancora provare a inviare). Questo non può richiedere più di 8 cicli di clock - se lo fa, c'è qualche altro problema.

Non posso garantire che questo risolva il tuo problema, ma ha risolto il mio!

Per la FRAM:

• collegare prima GND e Vcc;
• quindi assicurarsi che A1, A2 e WP abbiano il livello corretto;
• solo allora collegare i pin dei dati.

Il collegamento di pin diversi dall'alimentatore prima dell'accensione del chip può causare problemi.

10k sembra un po 'grande per i tuoi pullup e i tuoi bordi iniziali sembrano lenti. Ridurre i resistori a circa 3k e vedere se questo aiuta.

Inoltre, perché la tensione di fuoriuscita va alla deriva nel tempo?

C'è qualche possibilità che ci sia qualcos'altro che sta cercando di parlare con quel consiglio? Ho avuto un problema del genere una volta; Potrei ottenere un 60% delle volte, ma non ricordo di essere mai stato in grado di vedere una collisione. Sospetto che l'i2c che mi è stato fornito fosse in qualche modo isolato dal vero bus interno. Potrei eseguirlo continuamente e farebbe cadere il 30% dei messaggi. Il problema è svanito nel momento in cui abbiamo iniziato a parlare direttamente con il dispositivo (un alimentatore) senza intervenire sul "backplane".

Non vedo una sequenza di stop dopo il tuo errore NAK. Immagino tu abbia un breakpoint che interrompe il programma a quel punto?

Infine, se pensi di essere l'unico sul bus, puoi anche provare a sostituire la ripetuta partenza con una fermata / partenza. Ho visto dispositivi (in particolare FPGA personalizzati) che non sapevano come gestire la RS.

[In risposta al commento]: C'è molto che non hai detto sulla scheda FRAM, ad esempio se si tratta solo di memoria o di un intero sottosistema. Ma se riesci a mettere l'ambito proprio sui cavi del dispositivo i2c che ti dà problemi e vedi ancora cosa è raffigurato, quindi escluderei l'interferenza. I2C è abbastanza semplice che se vedi i segnali giusti sull'ingresso, il chip dovrebbe funzionare correttamente a meno che non abbia un problema interno.

In particolare, vuoi salire sul lato FRAM di quel cambio di livello. Un'interruzione del segnale è più probabile di qualcosa che si verificherebbe normalmente come una collisione.

Sottolineerò che un ciclo NAK è indistinguibile da un chip che semplicemente non c'è. Le EEPROM lo faranno per indicare che sono occupate. Ho cercato il tempo di scrittura su FRAM ed è più veloce di un singolo bit di dati i2c ... quindi non è un problema.

Poiché il problema, quando si riproduce, è un errore permanente che viene eliminato solo rimuovendo e reinserendo il dispositivo, si tratta di una delle due cose: il dispositivo si trova in uno stato non corretto dal quale si ripristina solo durante un ciclo di accensione, o c'è scarso contatto.

Se il dispositivo passa in uno stato non corretto dal quale si ripristina durante un ciclo di alimentazione, è possibile disporre di un circuito aggiuntivo che consente all'MCU di spegnere il dispositivo. Il firmware, quindi, non ricevendo alcun riconoscimento dal dispositivo, può eseguire una procedura di ripristino in base alla quale si spegne il chip per un po 'di tempo, lo riaccende e quindi riprova.

Se si tratta di un contatto scadente, allora forse devi guardare l'affidabilità del connettore e trovare qualcosa di meglio. Se si utilizza lo stesso connettore per rendere più di queste schede, potrebbero esserci problemi sul campo. In ogni caso, può esserci una procedura umana per gestire la situazione. L'operatore che lavora con il dispositivo deve essere consapevole del potenziale problema con l'inserimento della scheda e potrebbe essere necessario riposizionarlo per funzionare correttamente.

Il dispositivo principale potrebbe avere un modo per generare un allarme che indica che non può comunicare con la FRAM: un LED di "guasto" su un pannello e / o segnale acustico o altro. O il contrario: un po 'di luce che si accende, dando all'utente il feedback che la FRAM è stata accettata e che la comunicazione è stata stabilita. Se la FRAM è lontana dal dispositivo master, la luce può essere posizionata sul modulo FRAM: un altro chip I2C che guida un LED.

La natura sporadica del problema suggerisce che potrebbe essere un problema di temporizzazione.

Il foglio dati elenca due serie di tempi, uno per "Modalità standard" e uno per "Modalità rapida". Dalle tue misurazioni sembra che tu sia al limite dei tempi della "Modalità standard". Non riesco a capire dall'esame del foglio dati come esattamente il chip viene messo in entrambe le modalità.

Non presumo che il tuo dispositivo sia in modalità veloce. Puoi ridurre i tempi di un fattore 2-4, assicurarti di essere nei tempi della modalità standard per il tempo di mantenimento delle condizioni di inizio, il periodo di alta frequenza e il periodo di bassa frequenza e vedere se il problema persiste?

Hai un 24c04a, b o c? Se è un c04a, era un design robusto. La parte b è sensibile alle rampe di alimentazione. Che disaccoppiamento hai su pin8 in gnd? Stavo per dire qualcosa sui livelli del segnale ma vedo che usi un traduttore di livello. Potresti voler verificare che non si verifichi un problema tecnico su SCL che il chip interpreterebbe come un orologio extra.