Eu acho que encontrei a resposta. Acontece que este é um problema conhecido, mas só descobri que depois de ter decidido onde estava o problema e procurado por ele!
Aqui está o processo pelo qual passei, para que você possa segui-lo (e, se necessário, poderá adaptar sua investigação se encontrar resultados diferentes das minhas suposições). A conclusão é que parece haver uma incompatibilidade entre (pelo menos alguns) o comportamento do MSP430 I²C e o comportamento necessário do I²C pelo dispositivo que você suspeita ser o escravo do I²C, o IDT ZSC31014 . Ter a folha de dados desse dispositivo é essencial para entender isso, então obrigado por encontrá-lo.
A boa notícia é que existem (pelo menos) duas soluções alternativas para esse problema, que explicarei no final.
O gráfico engrossa, parece que a conexão de um osciloscópio diferente não faz o circuito funcionar corretamente e pode ser visto que a única diferença é que um ACK não está sendo transmitido.
Os novos traços são úteis, obrigado, embora eu os interprete um pouco diferente.
(O sinal inferior do sinal SCL, que me preocupou no rastreamento inicial, ainda está presente no rastreamento mais recente. É interessante que o sinal secundário no SCL pareça maior que o sinal secundário no SDA, especialmente considerando as diferentes escalas verticais entre os sinais SCL e SDA no Ainda sugeriria investigar a subida do SCL eventualmente, mas não acredito que esteja relacionada ao problema principal.)
Existem essas duas "falhas" no SDA:
Uma falha imediatamente antes ou logo após o pulso do ACK não é incomum, quando um mestre do I²C libera o controle do SDA para permitir que um escravo execute o ACK e, em seguida, o mestre pode re-dirigir o SDA novamente. Portanto, eu estou ignorando esse.
É a falha inicial do SDA, antes do primeiro pulso do SCL, o que é mais incomum. A partir da amplitude dessa falha inicial do SDA (veja mais adiante) e do fato de ocorrer apenas antes do primeiro pulso do SCL (rotulado como 0), mas não ocorre antes dos pulsos do SCL posteriores, onde poderíamos ver uma falha no SDA (como o SCL pulsos rotulados como 4, 5, 6 ou 7), sabemos que não é um artefato de medição nem um acoplamento do SCL (por exemplo).
(Para referência posterior, a falha inicial do SDA se parece com pelo menos 2V no rastreamento mais recente, portanto, com Vdd a 3,6V de comentários anteriores, isso torna a amplitude da falha do SDA pelo menos (2 / 3,6) = 0,55 x Vdd. Compare isso com os limites relevantes do nível lógico I2C discutidos posteriormente.)
Ignorando a diferença do ACK, acredito que vejo outra diferença entre os dois conjuntos de rastreamentos na segunda captura de tela. A amplitude dessa falha inicial do SDA parece um pouco diferente, comparando os principais traços do SDA rotuladosC1 (amarelo-ish?) E o segundo traço SDA marcado M3(azul). Agora, acredito que as diferenças na amplitude dessa falha inicial da SDA é o que pode fazer com que seu problema apareça ou desapareça, como explico abaixo.
Uma resolução ainda mais específica sobre a falha ajudaria (esse é um dos problemas ao tentar solucionar problemas "remotamente" - eu mesmo não posso operar o 'escopo!). Presumo que, quando você aumenta o zoom, parece o início de uma lógica I²C normal "1" (ou seja, uma curva RC na borda ascendente, especialmente se você temporariamente tornar as flexões mais fracas, por exemplo, 10k), exceto que isso não acontece ' t atinja a tensão positiva total antes de retornar a uma lógica "0". É o que é mostrado em outra página da web vinculada posteriormente. Se você vir uma forma diferente da sua falha, minha análise posterior poderá não se aplicar.
O I²C Master está no controle do barramento no ponto dessa falha, entre o I²C Start e o primeiro pulso de clock do SCL (que você rotulou como "0", embora seja o MSbit). Isso me fez suspeitar do comportamento do MSP430, embora com o SCL baixo naquele momento, uma falha no SDA não deva afetar os dispositivos compatíveis com I²C, pois eles aguardam o SCL subir alto antes de lerem o estado do SDA.
Então, esse I²C Slave é realmente compatível com I²C? Acontece que o ZSC31014 é " exigente " e menos tolerante do que alguns outros dispositivos I²C, exatamente no momento em que acredito que o MSP430 está produzindo essa falha!
A folha de dados do ZSC31014 lista 3 áreas em que eles admitem que o comportamento de I²C do dispositivo é "diferente". Você também pode ser afetado pelos dois primeiros nesta lista em outros momentos (que não fazem parte desta análise), mas é o terceiro ponto que marquei abaixo em vermelho, que está relacionado a essa falha inicial do SDA:
A amplitude dessa falha inicial da SDA é crítica . Se essa falha não se elevar o suficiente para ser reconhecida pelo ZSC31014 como uma lógica "1" antes de cair novamente, você estará bem - o dispositivo precisa ver uma queda no SDA para quebrar essa "regra" e só pode ser uma borda descendente se já tiver sido reconhecida como uma lógica "1".
Qualquer coisa que afete a amplitude dessa falha SDA, como a carga adicional de um analisador de escopo ou lógico no sinal SDA, pode ser suficiente para impedir que a falha seja reconhecida pelo ZSC31014 como atingindo a lógica "1" e, portanto, não "caindo" SDA edge ", terceiro ponto da lista, pode ocorrer (em um dia bom, dependendo de tensões, temperaturas etc.). No entanto, como você descobriu, a variação entre diferentes osciloscópios é suficiente para significar que alguns deles adicionam carga suficiente para parar o problema e outros não. Essa configuração deve ser muito marginal!
Isso confirma minha preocupação de que seus lotes de sensores "funcionais" anteriores possam estar "apenas" funcionando, pois os MCUs MSP430 nessas configurações "funcionais" provavelmente também estarão produzindo falhas no SDA. Minha teoria sobre uma possível diferença entre lotes de sensores, que poderia explicar o comportamento diferente que você relatou (lote "funcionando" vs. lote "não operacional") é explicada a seguir.
Curiosamente, o ZSC31014 é diferente do padrão I²C em outra área que não é mencionada nessa lista pelo fabricante, e isso pode explicar por que você parece notar uma diferença entre lotes de sensores.
Os limites lógicos padrão de I²C são (simplificados) - abaixo de 0,3 x Vdd para a lógica "0" e acima de 0,7 x Vdd para a lógica "1", como mostrado na especificação de I²C :
No entanto, o ZSC31014 possui limites diferentes , 0,2 x Vdd e 0,8 x Vdd, o que significa que sua "região indefinida" entre esses limites é maior que os dispositivos I²C típicos:
Essa "região indefinida" maior aumenta a chance de a falha entrar na área de nível de tensão indefinida, onde pode ser reconhecida como uma lógica "1" (lembre-se, qualquer coisa acima de 0,2 x Vdd pode ser reconhecida pelo ZSC31014 como uma lógica "1" , já que na região indefinida, tudo é permitido - é apenas acima de 0,8 x Vdd quando deve ser reconhecido como uma lógica "1"). E, como explicado anteriormente, se a falha for reconhecida pelo ZSC31014 como tendo atingido a lógica "1", quando ela cair novamente para a lógica "0", você quebrou a "regra" marcada em vermelho para o comportamento de I²C necessário pelo ZSC31014.
Como o reconhecimento dos níveis lógicos nessa região de tensão "indefinida" não é especificado, o fabricante do sensor não está quebrando a especificação se criar um lote que reconheça a lógica "1" somente quando atingir 0,7 x Vdd, mas fizer outro lote que reconheça uma lógica "1" tão baixa quanto 0,4 x Vdd, por exemplo. Esse segundo lote hipotético teria mais chances de ver a falha do SDA como uma vantagem decrescente do SDA, violando o terceiro ponto da lista, mas não quebrando suas especificações.
(Muitos dos problemas em que trabalhei, ao longo dos anos, foram assim: existem dois dispositivos, nenhum dos quais está quebrando individualmente uma especificação que possui brechas - mas um é exigente e menos tolerante, em um ponto em que o outro precisa que os dispositivos conectados sejam mais tolerantes por causa de seu comportamento obscuro! Cada um desses dispositivos faz uma boa interface com a maioria dos outros dispositivos, mas não é confiável (ou falha completamente) quando conectados um ao outro.)
Então o que você pode fazer? Pensei em duas opções:
Não use um MSP430 - use outro MCU que não crie essa falha inicial do SDA. No entanto, espero que você tenha investido muito tempo no software e não queira portar o código para outro MCU, se isso puder ser evitado.
"Bit-bang" o protocolo I²C no MSP430, em vez de usar seu módulo de hardware interno I²C. Dessa forma, você está no controle total dos sinais I²C e pode impedir que essa falha ocorra. No entanto, obviamente seria um pouco trabalhoso criar suas próprias rotinas I²C, depurá-las e o código resultante pode ser maior do que quando se usa o módulo de hardware MSP430 I²C, o que por si só pode ser um problema se você estiver com pouco espaço em Flash.
Depois, procurei problemas no MSP430 I²C e descobri que essa combinação do MSP430 + ZSC31014 é um problema conhecido, devido a essa falha no SDA do MSP430! Veja esta discussão no fórum TI E2E MSP430:
Fórum TI E2E: pulsos de falha do MSP430 I2C causando problemas para o chip periférico I2C
A solução mencionado lá, é para alterar o endereço ZSC31014 I²C para que SDA é alto no momento em que a falha positiva poderia ocorrer, e desde SDA é feita de alta, em seguida, de qualquer maneira, não há real falha em SDA:
Nossa solução alternativa é configurar o chip ZSC para ter um endereço com o bit 6 definido (por exemplo, agora estamos usando 0x42) - isso transforma o pulso de falha em um bit "alto" limpo e agradável para a duração do bit 6 do endereço, o que se livra da vantagem problemática.
A mesma solução alternativa é efetivamente o inverso da sugestão na folha de dados do ZSC31014, na caixa vermelha que eu marquei. Eles dizem que uma falha no SDA deve ser evitada se o primeiro bit (que é o MSbit) do endereço ZSC31014 I²C for 0 -, portanto, não torne o MSbit do endereço I²C um "0", faça um "1", ou seja, defina o bit 6 no endereço I²C de 7 bits!
Como o encadeamento do fórum TI E2E e a folha de dados do ZSC31014 estão focados no endereço I²C, talvez a falha do SDA não ocorra ou não seja um problema se ocorrer durante o envio de outros dados no barramento. Você precisará investigar isso.
Portanto, ignorando a primeira solução alternativa do uso de um MCU diferente, as duas soluções (mais práticas) são:
- Faça um bit-bang no barramento MSP430 I²C escrevendo seu próprio código, para que você não crie essa falha no SDA, ou
- Altere o endereço ZSC31014 I²C para que o bit 6 de seu endereço de 7 bits seja definido, o que significa que o SDA já está alto quando a falha ocorreria, para que nenhuma falha real ocorra no SDA quando o ZSC31014 é endereçado (supondo que uma falha SDA não ocorre após outros eventos I²C Start durante a transferência de dados ou, se houver, que o ZSC31014 não fique "chateado").
Espero que ajude!
