J'essaie de dépanner les communications entre un msp430fr5847 (maître) et un capteur esclave avec une puce I2C inconnue (partie d'un capteur industriel)
J'ai des problèmes avec un nouveau lot de capteurs où mes données sont renvoyées avec tous les zéros, cependant lorsque j'essaie de dépanner avec mon Saleae logic pro (2Mohm, 10pf), ou mon oscilloscope (10Mohm, 50pf), le système fonctionne parfaitement lors du sondage la broche SDA.
Dépannage supplémentaire le circuit fonctionne correctement si j'ajoute une résistance de 1Mohm entre SDA et la masse, mais ne fonctionne pas si seulement en ajoutant un condensateur de 10pf ou 100pf.
J'utilise des résistances de traction de 4,7 k sur mon rail 3,3 V.
Qu'est-ce qui pourrait être à l'origine de ce problème et que peut-on faire pour résoudre le problème sans résoudre le problème par inadvertance.
EDIT: 19/07/2017 Voici un aperçu rapide de la portée de mes signaux.
Une autre chose que j'ai oublié de mentionner est que seule la vérification de SDA fait fonctionner la carte, la sonde SCL ou ma ligne d'interruption ne la fait pas fonctionner correctement.
EDIT: 21/07/2017
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.
Dans l'image ci-dessus, les traces bleues et vertes sont le SCL et le SDA lorsque le circuit ne fonctionne pas correctement. Les traces jaunes et roses proviennent de quand je connecte également ma logique Saleae à la broche SDA et à la masse mais sans brancher USB (en essayant d'éviter les boucles de masse).
Pour ajouter un peu plus d'informations sur le capteur, il s'agit d'un capteur de pression industriel que nous achetons auprès du fabricant. Nous avons précédemment conçu et testé ces PCB avec notre premier lot de capteurs. Nous avons récemment reçu un nouveau lot et rencontrons maintenant ces problèmes. J'ai fait un peu d'enquête et je soupçonne fortement (après avoir googlé des phrases uniques de la fiche technique) que le capteur utilise en interne un ZSC31014 ou similaire, fiche PDF ICI
EDIT: 26/07/2017
J'espère donc que le dernier épisode pour résoudre ce problème, conformément à la réponse détaillée de SamGibson, j'ai implémenté le correctif de définition du bit élevé de l'adresse pour masquer les pépins à la fin du bit de démarrage.
Cela a fonctionné principalement avec les données qui transitent comme prévu, mais maintenant il apparaît que dans la première commande de lecture après une écriture (si c'est le terme correct pour un groupe de bits i2c), l'esclave tente d'acquitter un bit plus tôt (dans la position du bit d'écriture). Je peux dire que c'est l'esclave qui tire la ligne vers le bas en ajoutant une petite résistance (47 ohms) en série avec la ligne SDA.
Je commencerais généralement cela comme une nouvelle question, mais lorsque j'attache la même portée qui n'a eu aucun effet dans le dépannage ci-dessus, ce problème semble disparaître, cela semble vraiment être un problème limite, même si je joins la sonde de portée, sans le connecter à la portée, le problème est résolu, donc je suppose que c'est un problème de capacité.
Problème sans portée attachée
Problème avec sonde de portée attachée, mais pas attachée à la portée, notant la tension légèrement plus élevée lorsque l'esclave abaisse le bit d'écriture au lieu du bit ACK.
la source
Réponses:
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.
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éeM3(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:
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:
J'espère que cela pourra aider!
la source