Endereço escravo I2C não reconhecido (algumas vezes)

Estou tentando me comunicar com uma FRAM conectada remotamente (FM24C04 da Ramtron) usando o I2C. Essa memória é incorporada em uma placa que pode ser inserida e removida a qualquer momento para / do sistema (a comunicação é finalizada corretamente antes da remoção da memória).

O problema é: logo após inserir o cartão que contém a FRAM, às vezes ele não reconhece o endereço.

Medições de sinais

Eu medi os sinais para ver o que está acontecendo e parece que os horários estão corretos nos dois casos (funcionando e não funcionando).

Comunicação I2C correta (leitura de 3 bytes):

Endereço I2C FRAM não reconhecido (o endereço escravo é enviado corretamente):

Ações já realizadas para solucionar esse problema (sem êxito)

• Atraso adicionado após a inserção do cartão com a FRAM incorporada para garantir que a sequência de energia seja respeitada.
• I2C interrompe a geração após a detecção de um endereço escravo sem reconhecimento

Configuração de barramento I2C

• Um mestre (microcontrolador STM32F205 da ST)
• Três escravos (EEPROM 24AA1025 da Microchip, RTC DS1339C da Maxim IC e a remota FRAM FM24C04 de Ramtron
• Um deslocador de nível I2C (MAX3373E da Maxim IC) é usado para permitir a comunicação entre o mestre e a FRAM
• Frequência de barramento definida para 100 kHz

EDITADO (17-04-2013)

Em primeiro lugar, obrigado a todos por seus comentários.

Como há muitas sugestões, aqui está a descrição das investigações que eu fiz.

Esquemas

A figura a seguir mostra um esquema simplificado do barramento I2C:

Os sinais I2C_SDA e I2C_SCL são conectados diretamente ao microcontrolador e os sinais FRAM_SDA e FRAM_SCL são conectados ao FRAM. Observe que os sinais SDA e SCL conectados à FRAM são filtrados usando ferritas BLM18 de Murata.

A FRAM está conectada da seguinte maneira:

• NC (pino 1) -> não conectado
• A1 (pino 2) -> GND
• A2 (pino 3) -> GND
• VSS (pino 4) -> GND
• SDA (pino 5) -> FRAM_SDA
• SCL (pino 6) -> FRAM_SCL
• WP (pino 7) -> GND (não protegido contra gravação)
• VDD (pino 8) -> + 5V

Descrição do cartão FRAM

Este cartão é um cartão "semelhante ao ISA" que incorpora apenas a FRAM.

Investigações

Diminuindo a frequência

Fiz testes com a frequência do SCL definida em 50kHz e 10kHz. Eu medi o sinal SCL com um osciloscópio para garantir que ele estivesse na frequência esperada.

Essas modificações não resolveram o problema. Verifiquei os horários e eles estão dentro das especificações da folha de dados do FRAM.

Garantindo a sequência de potência

@jippie.

1. O deslocador de nível I2C é colocado no modo de três estados antes da inserção do cartão que incorpora a FRAM. Os sinais FRAM_SDA e FRAM_SCL estão baixos.
2. Após a inserção do "cartão FRAM", é adicionado um atraso de 100 ms para garantir que a fonte de alimentação seja estabilizada (pelo menos 11 ms antes da primeira condição de partida, de acordo com a folha de dados).
3. O comutador de nível I2C está ativado.
4. É adicionado um atraso de 1 ms para garantir que o comutador de nível I2C seja ativado e que as linhas sejam puxadas para cima (~ 4us exigido pela folha de dados). Os sinais FRAM_SDA e FRAM_SCL são puxados para cima.
5. A FRAM é acessada.

Os sinais FRAM_SDA e FRAM_SCL foram medidos após cada etapa.

O problema ainda ocorre.

Condição de parada / partida em vez de partida repetida

@gbarry.

Eu tentei parar antes do início repetido durante a transferência de bytes. Medi a transferência de bytes com o osciloscópio: a condição STOP seguida pela condição START está OK.

Infelizmente, esta solução não resolve o problema.

Pensamentos

Esse problema ocorre apenas após a conexão do cartão que incorpora a FRAM. Corri alguns milhares de acessos de leitura bem-sucedidos (endereçamento e leitura de escravos) depois que o "cartão FRAM" foi inserido e endereçado corretamente.

Parece-me cada vez mais um problema de hardware. Mas não sei se isso pode estar relacionado ao comutador de nível I2C ou aos outros escravos no barramento I2C.

Você tem outras idéias ou sugestões?

EDITADO (18/04/2013)

O problema parece estar resolvido

Substituí o conector do módulo FRAM e encontro uma maneira de fazer medições diretamente no FRAM. Parece que tudo está funcionando bem com este novo conector.

Farei mais testes para ter certeza de que o problema veio de uma conexão ruim.

Embora você diga que suas comunicações foram finalizadas corretamente antes da inserção ou remoção, pode valer a pena tentar esta solução, pois existe uma situação em que o barramento I2C pode causar problemas após a redefinição de apenas um dos dispositivos no barramento.

Antes de inicializar o hardware do Master I2C, configure o SDA como uma entrada e teste se o SDA está baixo.

Se estiver baixo, ajuste o pino do SCL alto.

Em seguida, alterne o pino do SCL para baixo e alto até o SDA ficar alto (ou seja, regule os bits restantes que os periféricos ainda estejam tentando enviar). Isso não pode levar mais de oito ciclos de relógio - se isso acontecer, há algum outro problema.

Não posso garantir que isso resolverá seu problema, mas resolveu o meu!

Para a FRAM:

• primeiro conecte GND e Vcc;
• verifique se A1, A2 e WP estão com o nível correto;
• somente então conecte os pinos de dados.

Conectar outros pinos que não sejam a fonte de alimentação antes da inicialização do chip pode causar problemas.

10k parece um pouco grande para seus pullups, e suas bordas principais parecem lentas. Reduza os resistores para cerca de 3k e veja se isso ajuda.

Além disso, por que a tensão desligada está flutuando com o tempo?

Alguma chance de haver algo mais tentando conversar com esse quadro? Eu tive um problema assim uma vez; Eu conseguia ack 60% das vezes, mas não me lembro de ter visto uma colisão. Eu suspeito que o i2c que eu recebi foi de alguma forma isolado do barramento interno real. Eu poderia executá-lo continuamente e isso eliminaria apenas 30% das mensagens. O problema desapareceu no momento em que começamos a conversar diretamente com o dispositivo (uma fonte de alimentação) sem o "backplane" intermediário.

Não vejo uma sequência de interrupção após o erro do NAK. Acho que você tem um ponto de interrupção que interrompe o programa nesse momento?

Por fim, se você acha que é o único no ônibus, tente substituir a partida repetida por uma parada / partida. Eu já vi dispositivos (especialmente FPGAs personalizados) que não sabiam como lidar com o RS.

[Em resposta ao comentário]: Há muita coisa que você não disse sobre a placa FRAM, como se é apenas memória ou um subsistema inteiro. Mas se você puder colocar o escopo direto nos terminais do dispositivo i2c que está causando problemas e ainda assim ver o que é retratado, excluiria a interferência. O I2C é simples o suficiente para que, se você vir os sinais corretos na entrada, o chip funcione corretamente, a menos que haja um problema interno.

Em particular, você deseja entrar no lado da FRAM desse deslocador de nível. Uma interrupção no sinal é mais provável do que algo que normalmente seria considerado uma colisão.

Vou apontar que um ciclo NAK é indistinguível de um chip que simplesmente não existe. As EEPROMs farão isso para indicar que estão ocupadas. Procurei o tempo de gravação no FRAM e é mais rápido que um único bit de dados i2c ... então isso não é um problema.

Como o problema, quando reproduzido, é uma falha permanente que é resolvida apenas com a remoção e reinserção do dispositivo, é uma das duas coisas: o dispositivo está entrando em um estado ruim do qual se recupera apenas em um ciclo de energia, ou há mau contato.

Se o dispositivo entrar em um estado ruim a partir do qual se recupera em um ciclo de energia, você poderá ter um circuito adicional que permita ao seu MCU desligar o dispositivo. O firmware, então, sem receber reconhecimento do dispositivo, pode executar um procedimento de recuperação no qual ele desliga o chip por algum tempo, o liga novamente e tenta novamente.

Se o contato for ruim, talvez seja necessário verificar a confiabilidade do conector e encontrar algo melhor. Se você usar o mesmo conector para criar mais dessas placas, poderá haver problemas no campo. Em qualquer caso, pode haver um procedimento humano para lidar com a situação. O operador que trabalha com o dispositivo deve estar ciente do possível problema com a inserção do cartão e pode ser necessário recolocá-lo para funcionar corretamente.

Seu dispositivo principal pode ter uma maneira de acionar um alarme, indicando que ele não pode falar com a FRAM: um LED de "problema" em um painel e / ou bipe ou qualquer outra coisa. Ou o contrário: alguma luz acesa, dando ao usuário feedback de que a FRAM foi aceita e a comunicação foi estabelecida. Se a FRAM estiver longe do dispositivo principal, a luz poderá ser localizada no módulo FRAM: outro chip I2C que aciona um LED.

A natureza esporádica do problema sugere que poderia ser uma questão de tempo.

A folha de dados lista dois conjuntos de tempos, um para o "Modo padrão" e outro para o "Modo rápido". A partir de suas medições, parece que você está na fronteira dos tempos do "Modo padrão". Não consigo distinguir ao analisar a folha de dados como exatamente o chip é colocado nos dois modos.

Eu não assumiria que seu dispositivo está no modo rápido. Você pode reduzir os tempos em um fator de 2-4, verifique se está dentro dos tempos do modo padrão para tempo de espera da condição de início, período alto do relógio e período baixo do relógio e veja se esse problema ainda ocorre?

Você tem 24c04a, b ou c? Se é um c04a, era um design robusto. A parte b possui sensibilidade às rampas da fonte de alimentação. Que dissociação você uv no pino 8 para o gnd? Eu ia dizer algo sobre os níveis de sinal, mas vejo que você usa um tradutor de níveis. Você pode verificar se não há uma falha no SCL que o chip interpretaria como um relógio extra.