Adresse esclave I2C non acquittée (parfois)

J'essaie de communiquer avec une FRAM connectée à distance (FM24C04 de Ramtron) en utilisant I2C. Cette mémoire est intégrée sur une carte qui peut être insérée et retirée à tout moment vers / depuis le système (la communication est correctement terminée avant la suppression de la mémoire).

Le problème est: juste après avoir inséré la carte qui contient la FRAM, parfois , elle ne reconnaît pas l'adresse.

Mesures des signaux

J'ai mesuré les signaux pour voir ce qui se passe et il semble que le timing soit correct dans les deux cas (fonctionne et ne fonctionne pas).

Communication I2C correcte (lecture de 3 octets):

Adresse I2C FRAM non acquittée (l'adresse esclave est correctement envoyée):

Actions déjà réalisées pour résoudre ce problème (sans succès)

• Délai ajouté après l'insertion de la carte avec la FRAM intégrée afin de garantir le respect de la séquence d'alimentation.
• Arrêt de la génération I2C après détection d'une adresse esclave non acquittement

Configuration du bus I2C

• Un maître (microcontrôleur STM32F205 de ST)
• Trois esclaves (EEPROM 24AA1025 de Microchip, RTC DS1339C de Maxim IC et la télécommande FRAM FM24C04 de Ramtron
• Un sélecteur de niveau I2C (MAX3373E de Maxim IC) est utilisé pour permettre la communication entre le maître et la FRAM
• Fréquence du bus réglée sur 100 kHz

MODIFIÉ (2013-04-17)

Tout d'abord, merci à tous pour vos commentaires.

Puisqu'il y a beaucoup de suggestions, voici la description des enquêtes que j'ai faites.

Schémas

L'illustration suivante montre un schéma simplifié du bus I2C:

Les signaux I2C_SDA et I2C_SCL sont directement connectés au microcontrôleur et les signaux FRAM_SDA et FRAM_SCL sont connectés à la FRAM. Notez que les signaux SDA et SCL connectés à la FRAM sont filtrés en utilisant des ferrites BLM18 de Murata.

Le FRAM est connecté comme suit:

• NC (broche 1) -> non connecté
• A1 (broche 2) -> GND
• A2 (broche 3) -> GND
• VSS (broche 4) -> GND
• SDA (broche 5) -> FRAM_SDA
• SCL (broche 6) -> FRAM_SCL
• WP (broche 7) -> GND (non protégé en écriture)
• VDD (broche 8) -> + 5V

Description de la carte FRAM

Cette carte est une carte de type "ISA" qui n'incorpore que la FRAM.

Enquêtes

Ralentir la fréquence

J'ai effectué des tests avec la fréquence SCL réglée sur 50 kHz et 10 kHz. J'ai mesuré le signal SCL avec un oscilloscope pour m'assurer qu'il était à la fréquence attendue.

Ces modifications n'ont pas résolu le problème. J'ai vérifié les horaires et ils sont conformes aux spécifications de la fiche technique FRAM.

Assurer la séquence de puissance

@jippie.

1. Le sélecteur de niveau I2C est mis en mode trois états avant que la carte qui incorpore la FRAM soit insérée. Les signaux FRAM_SDA et FRAM_SCL sont tirés bas.
2. Après l'insertion de la "carte FRAM", un délai de 100 ms est ajouté afin de garantir la stabilisation de l'alimentation (au moins 11 ms nécessaires avant la première condition de démarrage selon la fiche technique).
3. Le sélecteur de niveau I2C est activé.
4. Un délai de 1 ms est ajouté afin de s'assurer que le levier de niveau I2C est activé et que les lignes sont relevées (~ 4us requis par la fiche technique). Les signaux FRAM_SDA et FRAM_SCL sont extraits.
5. Le FRAM est accessible.

Les signaux FRAM_SDA et FRAM_SCL ont été mesurés après chaque étape.

Le problème persiste.

Condition d'arrêt / démarrage au lieu d'un démarrage répété

@gbarry.

J'ai essayé de mettre un arrêt avant le démarrage répété pendant le transfert d'octets. J'ai mesuré le transfert d'octets avec l'oscilloscope: la condition STOP suivie de la condition START est OK.

Malheureusement, cette solution ne résout pas le problème.

Pensées

Ce problème se produit uniquement juste après la connexion de la carte incorporant la FRAM. J'ai exécuté quelques milliers d'accès en lecture réussis (adressage et lecture esclaves) après que la "carte FRAM" a été insérée et correctement adressée.

Cela ressemble de plus en plus à un problème matériel. Mais je ne sais pas si cela pourrait être lié au décalage de niveau I2C ou aux autres esclaves sur le bus I2C.

Avez-vous d'autres idées ou suggestions?

MODIFIÉ (2013-04-18)

Le problème semble résolu

J'ai remplacé le connecteur du module FRAM et j'ai trouvé un moyen de faire des mesures directement sur la FRAM. Il semble que tout fonctionne bien avec ce nouveau connecteur.

Je ferai plus de tests pour être sûr que le problème vient d'une mauvaise connexion.

Bien que vous disiez que vos communications sont correctement terminées avant l'insertion ou le retrait, il peut être utile d'essayer cette solution, car il existe une situation où le bus I2C peut poser des problèmes après une réinitialisation d'un seul des périphériques sur le bus.

Avant d'initialiser le matériel Master I2C, définissez SDA comme entrée et testez SDA bas.

Si elle est faible, définissez la broche SCL sur haute.

Basculez ensuite la broche SCL vers le bas et vers le haut jusqu'à ce que SDA passe au niveau haut (c.-à-d. Éliminez tous les bits restants que les périphériques tentent toujours d'envoyer). Cela ne peut pas prendre plus de 8 cycles d'horloge - si c'est le cas, il y a un autre problème.

Je ne peux pas garantir que cela résoudra votre problème, mais cela a résolu le mien!

Pour le FRAM:

• connectez d'abord GND et Vcc;
• assurez-vous ensuite que A1, A2 et WP ont le niveau correct;
• alors seulement connectez les broches de données.

La connexion d'autres broches que l'alimentation avant la mise sous tension de la puce peut entraîner des problèmes.

10k semble un peu gros pour vos tractions et vos bords d'attaque semblent lents. Réduisez les résistances à environ 3k et voyez si cela aide.

Aussi, pourquoi la tension hors tension dérive-t-elle avec le temps?

Y a-t-il une chance que quelque chose d'autre essaie de parler à ce conseil? J'ai eu un problème comme ça une fois; Je pourrais obtenir un ack 60% du temps, mais je ne me souviens pas avoir jamais pu voir une collision. Je soupçonne que l'i2c qui m'a été fourni était en quelque sorte isolé du vrai bus interne. Je pouvais l'exécuter en continu, et cela laisserait tomber 30% des messages. Le problème a disparu au moment où nous avons commencé à parler directement à l'appareil (une alimentation) sans le "fond de panier" intermédiaire.

Je ne vois pas de séquence d'arrêt après votre erreur NAK. Je suppose que vous avez un point d'arrêt qui arrête le programme à ce moment-là?

Enfin, si vous pensez que vous êtes le seul dans le bus, vous pouvez aussi essayer de remplacer le démarrage répété par un arrêt / démarrage. J'ai vu des appareils (en particulier des FPGA personnalisés) qui ne savaient pas vraiment comment gérer le RS.

[En réponse au commentaire]: Il y a beaucoup de choses que vous n'avez pas dites sur la carte FRAM, comme s'il s'agissait simplement de mémoire ou d'un sous-système entier. Mais si vous pouvez placer le champ d'application directement sur les fils de l'appareil i2c qui vous pose problème, et que vous voyez toujours ce qui est illustré, alors j'exclure les interférences. I2C est assez simple pour que si vous voyez les bons signaux sur l'entrée, la puce doit jouer correctement sauf si elle a un problème interne.

En particulier, vous voulez vous placer du côté FRAM de ce décalage de niveau. Une coupure du signal est plus probable que quelque chose se produisant qui serait normalement considéré comme une collision.

Je soulignerai qu'un cycle NAK est indiscernable d'une puce qui n'est tout simplement pas là. Les EEPROM le feront pour indiquer qu'elles sont occupées. J'ai recherché le temps d'écriture sur FRAM et c'est plus rapide qu'un simple bit de données i2c ... donc ce n'est pas un problème.

Étant donné que le problème, lorsqu'il se reproduit, est une défaillance permanente qui ne peut être résolue qu'en retirant et en réinsérant l'appareil, alors c'est l'une des deux choses: l'appareil passe dans un mauvais état à partir duquel il ne se rétablit que lors d'un cycle d'alimentation, ou il y a un mauvais contact.

Si l'appareil passe dans un mauvais état à partir duquel il se rétablit lors d'un cycle d'alimentation, vous pouvez avoir un circuit supplémentaire qui permet à votre MCU d'éteindre l'appareil. Le micrologiciel peut alors, sans avoir reçu d'accusé de réception de l'appareil, exécuter une procédure de récupération par laquelle il éteint la puce pendant un certain temps, la rallume, puis réessaye.

Si c'est un mauvais contact, alors vous devrez peut-être regarder la fiabilité du connecteur et trouver quelque chose de mieux. Si vous utilisez le même connecteur pour créer plus de ces cartes, il pourrait y avoir des problèmes sur le terrain. Dans tous les cas, il peut y avoir une procédure humaine pour gérer la situation. L'opérateur qui travaille avec l'appareil doit être conscient du problème potentiel d'insertion de la carte et qu'il peut être nécessaire de le réinstaller pour fonctionner correctement.

Votre appareil principal pourrait avoir un moyen de déclencher une alarme indiquant qu'il ne peut pas parler à la FRAM: une LED "trouble" sur un panneau et / ou un bip ou autre. Ou l'inverse: un peu de lumière qui s'allume, donnant à l'utilisateur une rétroaction que la FRAM a été acceptée et que la communication a été établie. Si la FRAM est éloignée de l'appareil maître, la lumière peut être située sur le module FRAM: une autre puce I2C qui pilote une LED.

La nature sporadique du problème suggère qu'il pourrait s'agir d'un problème de calendrier.

La fiche technique répertorie deux ensembles de temporisations, un pour le "mode standard" et un pour le "mode rapide". D'après vos mesures, il semble que vous vous trouviez à la limite des horaires du "Mode Standard". Je ne peux pas dire en parcourant la fiche technique comment exactement la puce est placée dans l'un ou l'autre mode.

Je ne suppose pas que votre appareil est en mode rapide. Pouvez-vous réduire les délais d'un facteur de 2 à 4, assurez-vous que vous êtes dans les délais du mode standard pour le temps de maintien de la condition de démarrage, la période d'horloge haute et la période d'horloge basse et voyez si ce problème persiste?

U hv a 24c04a, b ou c? Si c'est un c04a, c'était une conception robuste. La partie b est sensible aux rampes d'alimentation. Quel découplage u hv sur pin8 à gnd? J'allais dire quelque chose sur les niveaux de signal mais je vois que vous utilisez un traducteur de niveau. Vous voudrez peut-être vérifier que vous n'avez pas de problème avec SCL que la puce interpréterait comme une horloge supplémentaire.