Je pense avoir trouvé la réponse. Il s'avère que c'est un problème connu, mais je n'ai découvert qu'après avoir décidé où était le problème et cherché cela!
Voici le processus que j'ai suivi, vous pouvez donc le suivre (et, si nécessaire, vous pouvez ensuite adapter votre enquête si vous voyez des résultats qui diffèrent de mes hypothèses). L'essentiel est qu'il semble y avoir une incompatibilité entre (au moins certains) le comportement MSP430 I²C et le comportement I²C requis par le périphérique que vous soupçonnez être l'esclave I²C, l' IDT ZSC31014 . Avoir la fiche technique de cet appareil est essentiel pour comprendre cela, alors merci de l'avoir trouvée.
La bonne nouvelle est qu'il existe (au moins) 2 solutions de contournement pour ce problème, que j'expliquerai à la fin.
Le tracé s'épaissit, il semble que la connexion d'un autre oscilloscope ne fasse pas fonctionner le circuit correctement, et on peut voir que la seule différence est qu'un ACK n'est pas transmis.
Les nouvelles traces sont utiles, merci, bien que je les interprète un peu différemment.
(Le sous-dépassement du signal SCL, qui me concernait sur la trace initiale, est toujours là sur la dernière trace. Il est intéressant de noter que le sous-dépassement sur SCL semble plus grand que le sous-dépassement sur SDA, en particulier compte tenu des différentes échelles verticales entre les signaux SCL et SDA sur le dernière trace. Je suggérerais toujours d'enquêter sur le sous-dépassement de SCL, mais je ne pense pas que cela soit lié au problème principal.)
Il y a ces deux "pépins" sur SDA:
Un problème juste avant ou juste après l'impulsion ACK n'est pas rare, lorsqu'un maître I²C relâche le contrôle de SDA pour permettre à un esclave d'effectuer l'ACK, puis le maître peut à nouveau piloter SDA. Par conséquent, j'ignore celui-là.
C'est le premier pépin SDA, avant la première impulsion SCL, qui est plus inhabituel. D'après l'amplitude de ce premier problème SDA (voir plus loin) et le fait qu'il se produit uniquement avant cette première impulsion SCL (étiquetée 0), mais ne se produit pas avant les impulsions SCL ultérieures où nous pourrions voir un problème sur SDA (comme SCL impulsions étiquetées 4, 5, 6 ou 7), on sait que ce n'est pas un artefact de mesure, ni un couplage de SCL (par exemple).
(Pour référence ultérieure, le premier pépin SDA ressemble à au moins 2 V dans la dernière trace, donc avec Vdd à 3,6 V des commentaires précédents, ce qui fait que l'amplitude du pépin SDA au moins (2 / 3,6) = 0,55 x Vdd. Comparez cela avec les seuils de niveau logique I2C pertinents discutés plus loin.)
Ignorant la différence ACK, je crois que je vois une autre différence entre les deux ensembles de traces dans cette deuxième capture d'écran. L'amplitude de ce petit problème SDA semble légèrement différente, comparant la trace SDA supérieure étiquetée C1(jaune-ish?) Et la deuxième trace SDA étiquetée M3(bleu). Je crois maintenant que les différences d'amplitude de ce premier problème SDA sont ce qui peut faire apparaître ou disparaître votre problème, comme je l'explique ci-dessous.
Une résolution encore plus précise sur le problème pourrait aider (c'est l'un des problèmes lorsque j'essaie de travailler sur des problèmes "à distance" - je ne peux pas utiliser le 'scope moi-même!). Je suppose que lorsque vous effectuez un zoom avant, cela ressemble au début d'une logique I²C normale "1" (c'est-à-dire une courbe RC sur le front montant, surtout si vous affaiblissez temporairement les tractions, par exemple 10k), sauf qu'il ne le fait pas. t atteindre la pleine tension positive avant de la refaire passer à un "0" logique. C'est ce qui est montré sur une autre page Web liée plus tard. Si vous voyez une forme différente de votre problème, alors mon analyse ultérieure pourrait ne pas s'appliquer.
Le maître I²C contrôle le bus au point de ce problème, entre le démarrage I²C et la première impulsion d'horloge SCL (que vous avez étiquetée "0" bien qu'il s'agisse du MSbit). Cela m'a fait soupçonner du comportement du MSP430, bien qu'avec SCL faible à ce stade, un problème SDA ne devrait pas affecter les appareils compatibles I²C, car ils attendront que SCL monte haut avant de lire ensuite l'état de SDA.
Alors, cet esclave I²C est-il vraiment compatible I²C? Il s'avère que le ZSC31014 est " pointilleux " et moins tolérant que certains autres appareils I²C, exactement au moment où je pense que le MSP430 produit ce petit problème!
La fiche technique du ZSC31014 répertorie 3 domaines dans lesquels ils admettent que le comportement I²C de l'appareil est "différent". Vous pourriez également être affecté par les deux premiers de cette liste à d'autres moments (cela ne fait pas partie de cette analyse), mais c'est le troisième point que j'ai marqué ci-dessous en rouge, qui est lié à ce premier problème SDA:
L'amplitude de ce premier problème SDA est critique . Si ce problème ne monte pas suffisamment pour être reconnu par le ZSC31014 comme un "1" logique avant qu'il ne retombe, alors vous êtes OK - l'appareil doit voir un front descendant sur SDA pour enfreindre cette "règle" et il ne peut être un front descendant s'il a déjà été reconnu comme un "1" logique.
Tout ce qui affecte l'amplitude de ce pépin SDA, comme la charge supplémentaire d'un oscilloscope ou d'un analyseur logique sur le signal SDA, pourrait être suffisant pour empêcher le pépin d'être reconnu par le ZSC31014 comme atteignant un "1" logique et donc pas de "chute". SDA edge ", ce troisième point de la liste, peut se produire (par une bonne journée, en fonction des tensions, des températures, etc.). Cependant, comme vous l'avez constaté, la variation entre les différents oscilloscopes est suffisante pour signifier que certains d'entre eux ajoutent suffisamment de charge pour arrêter le problème, et d'autres pas. Cette configuration doit être très marginale!
Cela confirme ma crainte que vos lots de capteurs "fonctionnels" précédents ne fonctionnent "que" simplement, car les microcontrôleurs MSP430 sur ces configurations "fonctionnelles" produiront probablement également des problèmes SDA. Ma théorie sur une différence possible entre les lots de capteurs, qui pourrait expliquer le comportement différent que vous avez signalé (lot "fonctionnel" vs lot "non fonctionnel") est expliquée ci-dessous.
Fait intéressant, le ZSC31014 est différent du standard I²C dans un autre domaine qui n'est pas mentionné sur cette liste du fabricant, et cela pourrait expliquer pourquoi vous semblez voir une différence entre les lots de capteurs.
Les seuils logiques I²C standard sont (simplifiés) - inférieurs à 0,3 x Vdd pour la logique "0" et supérieurs à 0,7 x Vdd pour la logique "1" comme indiqué dans la spécification I²C :
Cependant, le ZSC31014 a des seuils différents , 0,2 x Vdd et 0,8 x Vdd, ce qui signifie que sa "région non définie" entre ces seuils est plus grande que les périphériques I²C typiques:
Cette "région non définie" plus grande augmente les chances que le pépin pénètre dans la zone de niveau de tension indéfinie, où il pourrait être reconnu comme un "1" logique (rappelez-vous, tout ce qui dépasse 0,2 x Vdd pourrait être reconnu par le ZSC31014 comme un "1" logique , car dans la région non définie, tout est autorisé - il n'est supérieur à 0,8 x Vdd que lorsqu'il doit être reconnu comme un "1" logique). Et, comme expliqué précédemment, si le pépin est reconnu par le ZSC31014 comme ayant atteint un "1" logique, puis lorsqu'il retombe à un "0" logique, vous avez enfreint cette "règle" marquée en rouge pour le comportement I²C requis par le ZSC31014.
Étant donné que la reconnaissance des niveaux logiques dans cette région de tension "non définie" n'est pas spécifiée, le fabricant du capteur ne rompt pas les spécifications s'il crée un lot qui reconnaît le "1" logique uniquement lorsqu'il atteint 0,7 x Vdd, mais crée un autre lot qui reconnaît un "1" logique aussi bas que 0,4 x Vdd, par exemple. Ce deuxième lot hypothétique serait plus susceptible de voir le pépin SDA comme un bord SDA en baisse, en violation de ce troisième point de leur liste, sans pour autant rompre leurs spécifications.
(La plupart des problèmes sur lesquels j'ai travaillé au fil des ans ont été les suivants: il y a deux appareils, dont aucun ne casse individuellement une spécification qui a des lacunes - mais l'un est difficile et moins tolérant, à un point où le l'autre a besoin que les appareils connectés soient plus tolérants en raison de son comportement obscur! Chacun de ces deux appareils s'interface correctement avec la majorité des autres appareils, mais n'est pas fiable (ou échoue complètement) lorsqu'il est connecté l'un à l'autre.)
Alors que peux-tu faire? J'ai pensé à deux options:
N'utilisez pas un MSP430 - utilisez un autre MCU qui ne crée pas ce petit problème SDA. Cependant, je suppose que vous avez investi beaucoup de temps dans le logiciel et que vous ne voudriez pas porter le code sur un autre MCU, si cela pouvait être évité.
"Bit-bang" le protocole I²C sur le MSP430, au lieu d'utiliser son module matériel I²C intégré. De cette façon, vous contrôlez totalement les signaux I²C et pouvez empêcher ce problème de se produire. Cependant, il serait évidemment difficile de créer vos propres routines I²C, de les déboguer, et le code résultant peut être plus volumineux que lors de l'utilisation du module matériel MSP430 I²C, ce qui pourrait être un problème si vous manquez d'espace Flash.
Ensuite, je suis allé à la recherche de problèmes I²C MSP430, et j'ai trouvé que cette combinaison de MSP430 + ZSC31014 est un problème connu, en raison de ce premier problème SDA du MSP430! Voir ce fil sur le forum TI E2E MSP430:
Forum TI E2E: les impulsions de pépin de MSP430 I2C causent des problèmes pour la puce périphérique I2C
La solution de contournement mentionnée ici, consiste à modifier l'adresse ZSC31014 I²C de sorte que SDA soit élevé au moment où le problème positif pourrait se produire, et puisque SDA est élevé, de toute façon, il n'y a pas de problème réel sur SDA:
Notre solution de contournement consiste à configurer la puce ZSC pour avoir une adresse avec son bit 6 défini (par exemple, nous utilisons maintenant 0x42) - cela transforme l'impulsion de pépin en un joli bit "haut" propre pour la durée du bit d'adresse 6, qui se débarrasse du front descendant problématique.
La même solution de contournement est en fait l'inverse de la suggestion de la fiche technique ZSC31014, dans la case rouge que j'ai marquée. Ils disent qu'un pépin SDA doit être évité si le premier bit (qui est le MSbit) de l'adresse I²C ZSC31014 est 0 - donc ne faites pas le MSbit de l'adresse I²C un "0", faites-en un "1" à la place, c'est-à-dire positionnez le bit 6 dans l'adresse I²C 7 bits!
Étant donné que ce fil de discussion TI E2E et la fiche technique ZSC31014 se concentrent tous les deux sur l'adresse I²C, alors peut-être que le problème SDA ne se produit pas, ou n'est pas un problème s'il se produit, lors de l'envoi d'autres données sur le bus. Vous devrez enquêter là-dessus.
Par conséquent, en ignorant la première solution de contournement de l'utilisation d'un MCU différent, les deux solutions de contournement (plus pratiques) sont soit:
- Bit-bang le bus MSP430 I²C en écrivant votre propre code, afin de ne pas créer ce problème sur SDA, ou
- Modifiez l'adresse ZSC31014 I²C de sorte que le bit 6 de son adresse 7 bits soit défini, ce qui signifie que SDA est déjà élevé lorsque le problème se produirait autrement, donc aucun problème réel ne se produit sur SDA lorsque le ZSC31014 est adressé (en supposant qu'un problème SDA soit ne se produit pas après d'autres événements I²C Start pendant le transfert de données, ou si l'un se produit, que le ZSC31014 ne soit pas "bouleversé").
J'espère que cela pourra aider!
