Le logiciel SPI ne reste pas bas

TrivialCase

Le logiciel SPI ne reste pas bas


… et quelques autres choses. Je me fraye un chemin à travers le livre de Geoffrey Brown, Discovering the STM32 Microcontroller, et il s’est largement déroulé jusqu’à présent. Je suis tombé sur un exercice où le lecteur peut essayer de lire / écrire sur une EEPROM via SPI. J’ai eu l’interface SPI fonctionnant en boucle, bien que la nuit dernière, lorsque je la testais, j’ai remarqué que sur l’analyseur logique, je voyais le NSS pousser haut avant que le message ne soit complet. Puis le matin, pas de changement, tout fonctionne à nouveau correctement. D’ACCORD.

J’ai tout configuré pour lire / écrire la ROM (Micro 25LC256) mais le signal que je vois sur l’analyseur n’est pas ce que j’attends. Je vois le NSS pousser de temps en temps au milieu de la communication. De plus, l’horloge semble incohérente et les données semblent fausses, et l’analyseur me donne une tonne d’erreurs.

J’ai pensé, OK, je vais retirer le NSS tout à fait car la ROM est la seule chose connectée de toute façon, alors elle restera faible et je pourrai le vérifier. Mais l’horloge a toujours l’air chancelante … Je ne fais que commencer avec ce genre de choses, mais je n’ai rien du tout à régler la fréquence d’horloge, donc vous ne savez pas comment ça change? Le code peut être trouvé ici , et je pense que c’est assez simple. la plupart de la logique importante ressemble

  // Drop select level low then send the write enable flag
  GPIO_WriteBit(EEPROM_PORT, EEPROM_CS, 0);
  spiReadWrite(EEPROM_SPI, res, cmd, 2, EEPROM_SPEED);
  GPIO_WriteBit(EEPROM_PORT, EEPROM_CS, 1);
  Delay(1); // Debugging aid, Wait 1 ms to make analyzer easier to read

J’ai toutes les vitesses réglées à un niveau bas (les SPI CLK / MOSI / MISO sont 72 / 64 = 1.125< 10Mhz= 25LC256 vitesse maximale et le GPIO que j’utilise pour NSS est à 2 MHz), et j’ai mis un délai 1msentre les opérations juste pour le rendre plus facile à lire sur l’analyseur, il ne semble pas affecter la sortie.

Voici une capture des données de l’analyseur avec le NSS forcé bas (débranché):

entrez la description de l'image ici

En zoomant sur les premières impulsions, je vois que la largeur de l’horloge est partout, ne ressemble pas à CPOL / CPHA = 0/0 et ne ressemble pas à l’envoi de la valeur d’autorisation d’écriture WREN = 0x06 = 0b0000 0110

entrez la description de l'image ici

… et ça ne semble pas aller mieux …

entrez la description de l'image ici

Et un dernier qui montre le NSS pousser haut sans raison

entrez la description de l'image ici

Comment déboguer à partir d’ici? Y a-t-il quelque chose d’évident que j’oublie? Est-il courant d’avoir des problèmes de synchronisation aussi mauvais? Merci!

Érable

La première chose qui vient à l’esprit, vous avez besoin d’une broche CS pour interfacer cette puce. De 3.2 dans la fiche technique: « Après que tous les huit bits de l’instruction ont été transmis, le CS doit être élevé pour régler le verrou de validation d’écriture ». Deuxièmement, avez-vous connecté correctement la broche « Hold »?

brhans

À quelle vitesse votre analyseur logique échantillonne-t-il? Il semble que ce soit trop lent par rapport à votre horloge SPI.

TrivialCase

@brhans Je l’ai réglé à son maximum, qui est de 50 ms / s. Je pense que cela devrait être suffisant pour échantillonner un < 2MHzsignal?

TrivialCase

@Maple Merci, je connais le CS utilisé pour définir le verrou d’écriture. Je l’ai seulement désactivé pour voir si je pouvais «  forcer  » le signal correct hors de MOSI (je m’attends à voir 0x06quelle est la valeur d’activation d’écriture), mais il ne va même pas aussi loin. En ce qui concerne la broche d’attente, je vérifierai le matin, mais tout est assez simplement connecté sur sa propre planche à pain, donc je suis sûr qu’il est bien connecté.

Réponses


 Arsenal

Une partie qui est assez évidente:

Ne laissez pas la puce sélectionnée non connectée ou faible tout le temps. Dans la plupart des appareils esclaves, la sélection de puce est une partie essentielle de la machine d’état de l’esclave. Dans les EEPROM par exemple, l’écriture dans les cellules réelles est souvent effectuée après que la sélection de puce est élevée.

Maintenant, vos captures d’analyseur logique semblent très bancales. Je suppose que vous avez du bruit sur vos lignes (couplage des autres lignes, boucles de masse) de sorte que vous ne voyez pas vraiment ce qui se passe vraiment là-bas. J’ai également eu des rapports de collègues selon lesquels l’analyseur logique lui-même injectait une bonne quantité de bruit.

Vous n’avez pas mentionné si vous avez réellement regardé ce que le logiciel vous dit – est-ce que le tampon de lecture est identique à ce que vous avez écrit? C’est la principale chose qui devrait vous inquiéter, si ce n’est pas le cas, vous pouvez commencer à regarder le bus, mais avant cela, j’essaierais de voir ce que je peux obtenir dans le débogueur.

Si votre analyseur prend en charge le mode analogique, il peut être utile d’examiner les signaux analogiques pour voir si certains des bords provoquent un bruit significatif sur les autres lignes. Ou bien sûr, utilisez un oscilloscope.

TrivialCase

Merci! J’ai vérifié les valeurs sur la ROM, et je ne vois pas mes écritures, mais je récupère le nombre correct de valeurs nulles lorsque j’archive le débogueur (je le fais extraire toute la première page, et je récupère 64 zéros , ce qui semble être un bon signe). Cela rend la situation plus confuse car si la lecture fonctionne correctement, je pourrais simplement avoir quelque chose de mal dans le logiciel avec les écritures (c’est pourquoi j’essayais de déboguer avec l’analyseur logique en premier lieu) mais je ne suis tout simplement pas en mesure de résoudre les problèmes à cause de problèmes d’analyseur. : – /

TrivialCase

En fonction de votre réponse, j’ai lié tous les motifs à une meilleure source. Il s’avère que le sol que j’utilisais pour la broche CS est farfelu (probablement toute la carte est défectueuse d’une manière ou d’une autre). Je reçois maintenant un signal plus clair, bien que quelque chose semble encore un peu décalé. Merci de votre aide!

TrivialCase

Merci encore pour l’aide, j’accepte votre réponse depuis qu’elle m’a permis de démarrer. L’analyseur logique a encore un peu de bruit, mais j’ai tout bien fredonné. Je ne sais pas comment c’est possible, mais l’une des broches de mise à la terre de ma carte de découverte donne une tonne de bruit même si le reste de la carte semble fonctionner correctement. Je soupçonne que les autres motifs pourraient être à blâmer pour le reste du comportement erratique que je vois sur l’analyseur, mais comme cela fonctionne, je ne vais pas devenir fou pour le tester pour l’instant.

Arsenal

@TrivialCase Si l’une des broches de terre vous donne beaucoup de bruit supplémentaire, il se peut qu’elle ne soit pas connectée à la masse (mauvaise soudure?) Ou à une terre différente (certaines cartes ont des terres séparées, mais je ne pense pas que c’est le cas des cartes découverte). Cela pourrait également être dû au fait que la broche a un mauvais routage vers la masse (boucle longue au lieu d’être directement dirigée vers l’avion). Heureux de pouvoir vous aider un peu.

 

#pas, bas, Le, Logiciel, ne, reste, SPI

 

google

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *