Problème de communication flash série Microchip SST26VF064B - ID JEDEC incorrect

Aug 19 2020

J'essaie de tester la communication SPI avec le flash série Microchip SST26VF064B et j'ai rencontré un problème lors de la lecture de l'ID JEDEC à partir de la puce. Selon la fiche technique, les trois premiers octets doivent être 0xBF, 0x26, 0x41 / 0x42. J'obtiens des données entièrement différentes: 0x7C, 0x20, 0x7F. La puce semble répondre à la commande de lecture JEDEC ID 0x9F, mais envoie toujours les mêmes données inattendues.

J'ai essayé le pilote SPI fourni avec le SDK pour SOC avec lequel je travaille, ainsi que le SPI simple, le résultat est le même, donc je pense que la communication SPI fonctionne bien. Je n'ai plus d'idées pour essayer ensuite ... Y a-t-il une raison pour laquelle je peux obtenir ces données au lieu de l'ID attendu?

Réponses

1 woytekm Sep 01 2020 at 14:30

Il semble que ce soit un problème complexe partiellement lié à la synchronisation et également au manque de résistance série sur la ligne MISO. Les problèmes ont finalement disparu après l'ajout d'une résistance de 100 ohms sur le MISO et le réglage de la ligne SOC SCLK nRF52840 sur "high drive", pour faire chuter / monter les fronts d'horloge plus rapidement.

Je soupçonne que mes problèmes sont liés au fait que je travaille actuellement sur une maquette avec des fils de cavalier assez longs (10-15 cm). Comme pour tout projet, j'essaye de tester tous les composants inconnus avant de les intégrer dans un circuit / PCB. Bien sûr, la maquette peut et introduira ses propres problèmes, et cela se produit probablement ici, mais j'ai quand même travaillé avec quelques puces SPI différentes, et je n'ai jamais rencontré un comportement aussi erratique des signaux sur le bus auparavant.

- Premier problème: l'esclave sort quelque chose sur MISO, mais les données de sortie sont inattendues / erronées. J'ai inclus des écrans d'oscilloscope dans la question initiale, et sur la deuxième, élargie, on peut voir de petites pointes se produire sur MISO. J'ai examiné ces pics, et il semble qu'ils se produisent toujours à la chute du bord de l'horloge, lorsque l'esclave doit décaler le bit suivant:

Jaune - CS, Bleu - Horloge, Violet - MISO (MOSI est laissé de côté sur ces écrans)

Sur l'écran supérieur ci-dessus, on peut voir que l'esclave détecte la chute du bord de l'horloge et que MISO commence à monter (apparenty un bit dans l'octet lu est égal à 1), mais alors que le bord de l'horloge tombe encore plus lentement, l'esclave devient confus et ferme MISO avant qu'il n'atteigne le niveau logique H approprié (au moins c'est ma compréhension de ce qui se passe ici). Deuxièmement, l'écran inférieur est à titre de comparaison, lorsque la fonction «high drive» du nRF52840 SOC est activée sur la broche SCLK - le bord de l'horloge tombe plus rapidement et MISO agit correctement avec ce paramètre - la puce produit les données attendues.

- Deuxième problème: le signal MISO est correct lorsqu'il est sondé non connecté. Après la connexion au maître, le signal MISO est déformé au point qu'il est illisible par le maître, ou il n'y a aucun signal MISO.

Vous trouverez ci-dessous un comportement approprié (avec une résistance de 100 ohms sur MISO, un lecteur haut activé sur SCLK) - il s'agit d'une puce flash différente de celle de la question d'origine - je l'ai changée en Micron MT25QL128ABA, mais elle s'est comportée exactement de la même manière. Sondé avec le maître connecté à MISO. Jaune - CS, Bleu - Horloge, Violet - MISO. MOSI est omis sur ces écrans.

Voici le comportement sans résistance - aucun signal MISO. Sondé avec le maître connecté à MISO. Jaune - CS, Bleu - Horloge, Violet - MISO. MOSI est omis sur ces écrans.

J'ai trouvé de nombreux fils sur les forums nordiques, décrivant des problèmes MISO similaires: https://devzone.nordicsemi.com/f/nordic-q-a/47335/problem-using-digital-io-as-miso https://devzone.nordicsemi.com/f/nordic-q-a/47968/spi-doesn-t-work-in-nrf52810-while-emulating-nrf52810-in-nrf52832dk-was-successful/190230#190230

Je ne sais pas s'il s'agit d'un bug ou d'une mauvaise configuration de la broche SOC utilisée pour MISO, ou est-ce lié à de longs fils de bus SPI dans mon circuit de test. D'après ce que j'ai lu, les résistances peuvent être utilisées sur le bus SPI pour correspondre à l'impédance du récepteur et du transmetteur lorsque les fils / traces sont longs (mais 10 cm sont-ils assez longs pour causer de tels problèmes?). Le fait est que cette résistance de valeur relativement faible sur MISO aide ici. J'aimerais savoir pourquoi exactement cela se produit, mais je n'ai pas de connaissances solides de bas niveau pour être sûr. J'incorporerai une résistance sur MISO sur un PCB, mais je vais d'abord le tester avec une valeur 0R, pour voir si de meilleures conditions sur PCB (traces plus courtes) feront ce travail sans résistance supplémentaire.