problemas de velocidade do ônibus i2c

Question

Estou usando um MSP430F6736A, o periférico eUSCI_B0 i2c em meu chip no modo INTERROMPER para se comunicar com um chip FRAM.

Estou tentando descobrir por que tenho que diminuir meu clock i2c para 130KHz para me comunicar "de forma confiável" com um chip Rohm FEDR44V100A fram 1Mb.

Para esclarecer, quando eu defino o relógio i2c para 400KHz, o chip FRAM 'às vezes' parece retornar apenas 0s (melhor caso, ou pior caso de dados aleatórios), mas quando eu ajusto o relógio i2c para 130KHz, tudo funciona perfeitamente. Estou assumindo que é o chip FRAM que está enviando dados incorretos e não a porta i2c recebendo dados incorretos, pois não consigo reproduzir o erro de forma "consistente" para capturá-lo em um analisador lógico.

A partir da folha de dados do FRAM, o chip pode operar em velocidades de clock de até 1MHz. Meu MSP430 está operando a 16,77 MHz

o tempo de subida em SCL e SDA é inferior a 200 nS. os resistores pullup no barramento i2c são 2K

a configuração do 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;

os bits de interrupção do UCB0IE são definidos / apagados nos momentos relevantes.

Devo salientar que não tive problemas de comunicação com um chip Microchip 47L16 EERAM a 400 KHz, o que indicaria que o problema está (100%) no chip ROHM ... mas por quê? Quaisquer sugestões sobre o que eu poderia fazer para tentar e melhorar a velocidade seriam bem-vindas, assim como quaisquer sugestões sobre por que a comunicação tem que ser nessa velocidade baixa.

desde já, obrigado.

o circuito...

onda de clock em 129KHz ..

onda de clock em 382 KHz ..

Answer 1

Encontrei a solução para o meu problema.

Quando usei o chip Microchip EERAM, descobri que tinha que colocar um byte fictício no TxBUF imediatamente antes de definir a interrupção Tx, ou seja, assim:

UCB0TXBUF = 0x55; 
UCB0IE = UCTXIE0;

Se eu não fizesse isso, o primeiro byte do endereço no chip para o qual eu queria escrever não era enviado.

No entanto , essa linha causou o problema com o chip FRAM, pois, às vezes , o 0x55 era realmente transmitido como o primeiro byte para definir o endereço no chip que eu queria escrever.

Não estou claro por que isso só acontecia às vezes . Ele foi encontrado usando um analisador lógico para capturar repetidamente 2 segundos de comunicações e eu notei o 0x55 quando deveria ter sido um valor diferente transmitido (bem como o fato de que 3 bytes foram transmitidos para o endereço e não apenas 2).

Além disso, no ISR, eu também tinha a linha UCB0TXBUF = 0xFF;imediatamente antes de limpar a interrupção Tx, ou seja, assim:

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

Agora mudei isso e agora limpo a configuração IFG após desativar a interrupção, ou seja, assim:

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

Portanto, obrigado a todos que tentaram ajudar, é muito apreciado.

PS Agora estou me comunicando com sucesso a 1 MHz.