Problemi di velocità del bus i2c

Aug 23 2020

Sto utilizzando un MSP430F6736A la periferica eUSCI_B0 i2c sul mio chip in modalità INTERRUPT per comunicare con un chip FRAM.

Sto cercando di capire perché devo abbassare il mio clock i2c a 130KHz per comunicare in modo "affidabile" con un chip Rohm FEDR44V100A fram 1Mb.

Per chiarire, quando imposto l'orologio i2c a 400 KHz, il chip FRAM `` a volte '' sembra restituire solo 0 (caso migliore, o caso peggiore dei dati casuali), ma quando imposto l'orologio i2c a 130 KHz, tutto funziona perfettamente. Suppongo che sia il chip FRAM che sta inviando dati errati e non la porta i2c che riceve dati errati poiché non posso riprodurre "costantemente" l'errore in modo da catturarlo su un analizzatore logico.

Dalla scheda tecnica FRAM, il chip può funzionare a velocità di clock fino a 1 MHz. Il mio MSP430 funziona a 16,77 MHz

il tempo di salita su SCL e SDA è inferiore a 200nS. le resistenze di pullup sul bus i2c sono 2K

la configurazione per i2c è:

UCB0CTLW0 |= UCMST | UCMODE_3 |  UCSSEL__SMCLK;
UCB0BRW_L = 128; .................this is for 130KHz
UCB0BRW_L = 40;....................this is for 400KHz
UCB0BRW_H = 0;
UCB0I2COA0 = 0; 
UCB0I2CSA = theSalveAddress;

i bit di interrupt di UCB0IE vengono impostati / azzerati nei momenti pertinenti.

Potrei sottolineare che non ho avuto alcun problema a comunicare con un chip EERAM Microchip 47L16 a 400KHz che indicherebbe che il problema risiede (100%) con il chip ROHM ... ma perché? Qualsiasi suggerimento su cosa potrei fare per provare e migliorare la velocità sarebbe apprezzato, così come qualsiasi suggerimento sul motivo per cui la comunicazione deve essere a questa bassa velocità.

Grazie in anticipo.

il circuito...

onda di clock a 129 KHz ..

onda di clock a 382 KHz ..

Risposte

2 moshejay Aug 25 2020 at 14:41

Ho trovato la soluzione al mio problema.

Quando ho usato il chip EERAM di Microchip, ho scoperto che dovevo inserire un byte fittizio in TxBUF immediatamente prima di impostare l'interrupt Tx, ovvero in questo modo:

UCB0TXBUF = 0x55; 
UCB0IE = UCTXIE0;

Se non l'ho fatto, il primo byte dell'indirizzo nel chip su cui volevo scrivere non è stato inviato.

Tuttavia , quella riga ha causato il problema con il chip FRAM poiché, a volte , lo 0x55 veniva effettivamente trasmesso come 1 ° byte per impostare l'indirizzo nel chip su cui volevo scrivere.

Non sono chiaro perché ciò sia accaduto solo a volte . È stato trovato utilizzando un analizzatore logico per acquisire ripetutamente 2 secondi di comunicazioni e ho notato lo 0x55 quando avrebbe dovuto essere trasmesso un valore diverso (oltre al fatto che sono stati trasmessi 3 byte per l'indirizzo e non solo 2).

Inoltre, nell'ISR avevo anche la linea UCB0TXBUF = 0xFF;immediatamente prima di cancellare l'interrupt Tx, ovvero in questo modo:

UCB0TXBUF = 0xff; // to prevent UCB0IFG from having TXBuf empty flag
UCB0IE &= ~UCTXIE0; // disable TX intr

Ora l'ho modificato e ora deseleziono l'impostazione IFG dopo aver disabilitato l'interrupt, ovvero in questo modo:

UCB0IE &= ~UCTXIE0; 
UCB0IFG &= ~UCTXIFG0;

Quindi grazie a tutti coloro che hanno cercato di aiutare, è molto apprezzato.

PS Ora sto comunicando con successo a 1 MHz.