Etat d’avancement du projet NFC au 19 Septembre 2013

Après avoir travaillé de manière intense sur ma fraiseuse numérique pour pouvoir la présenter au salon des Associations de ma ville, j’ai repris du temps pour faire avancer mon projet NFC. Voici ce qui a été réalisé.

J’ai implémenté les codes nécessaires pour piloter le bus SPI depuis le chip ARM de commande. Ce n’était pas très complexe. J’ai pu vérifier avec un analyseur logique que les signaux étaient corrects. Le Tiva a plein de registres qu’il faut configurer correctement, mais il met à disposition une doc assez complète qui décrit les séquences d’initialisation. Quand on les suit sans se tromper, ça marche!

Les choses sont plus compliquées du côté du front end NFC. Pour commencer, j’ai réussi à obtenir de nouveaux samples de Texas, que j’ai soudé correctement cette fois: Pas d’apport supplémentaire de pâte à braser, mais utilisation de flux et chauffage rapide. Le soudage est très nettement amélioré, l’étain déjà présent sur la carte suffit à assurer la soudure sans débordements.

Il me manque encore tous les composants de la partie analogique et les condensateurs de découplage, mais j’avais envie d’essayer quand même. Effectivement, le chip réagit, puisque le passage de sa ligne “Enable” dans le bon état produit le démarrage de toutes les alimentations secondaires produites par le chip. Au moins, j’ai la preuve que certaines pattes sont correctement soudées et que le chip n’est pas totalement grillé 😀

Par contre, il m’a été pour l’instant impossible de lire par SPI la moindre valeur de registre depuis le chip. Et c’est là que j’ai commencé à découvrir pas mal de défauts du circuit.

Pour commencer, sa documentation n’est absolument pas claire. Elle répète certaines informations dans des paragraphes différents, se contredit, et contient des manques et des erreurs. On ne s’en rend pas compte en première lecture, mais le nombre de messages d’incompréhension sur leur forum “E2E” en dit long.

Le circuit n’est pas non plus exempt de bugs “silicium”. Il réagit de manière non documentée, ou imprévue, quand son pilotage est réalisé comme dans la datasheet. Par exemple, le chip dispose de trois modes de pilotage:

  • un mode parallèle (on pilote 8 fils de données, puis on valide une horloge)
  • un mode SPI sans signal CS : dans ce cas ils ont “inventé” un genre de start condition ressemblant à de l’I2C, mais qui n’est pas de l’I2C, et qui n’est pas supporté par le Tiva, ce qui demanderait un pilotage manuel par bit banging
  • un mode SPI avec signal CS : dans ce cas l’assertion de la ligne CS démarre la transaction SPI, et la désassertion la termine. Sauf que, lors de cette déassertion, il n’y a pas de nouveau signal d’horloge généré,ce qui est normal pour du SPI. Eh bien dans certains cas, ceci empêche le circuit de prendre en compte la commande envoyée. Pour corriger cela, il faut générer une unique pulse d’horloge supplémentaire pour valider la commande. Pas 8, sinon le chip croit qu’une autre commande lui est addressée. Ceci demande de reconfigurer terporairement le bus SPI en GPIO normales, puis d’envoyer la pulse, puis de reconfigurer le bus SPI.

Vous voyez le genre de techniques tordues qu’il faut appliquer… Et qui ne sont pas documentées clairement, malgré leur bizarrerie. Et on n’en est encore qu’à la couche transport, je n’imagine même pas encore tous les bugs fonctionnels que je vais trouver! Je trouve ça assez peu sérieux de la part d’un grand fabricant de circuits intégrés, surtout quand on essaye de concurrencer NXP et Broadcom sur le marché du front end NFC.

Exemple de documentation: dans une version précédente, les données SPI envoyées au chip étaient valides sur le front descendant de SCLK, et les données retournées juste après étaient disponibles sur le front montant de l’horloge… Pas très pratique. Mais bon. Dans la dernière révision du chip, ceci a été corrigé. Toutes les données (MOSI et MISO) sont valides au front descendant de SCLK. Mais la datasheet n’a pas été mise à jour, jusqu’à ce que quelqu’un se plaigne sur le forum!

J’avoue que tous ces problèmes m’ont été signalés par un ami qui avait déja travaillé avec ce circuit, sinon j’en serais encore à savoir pourquoi ça ne marche pas. D’un autre coté, pour DIY qui se voulait électroniquement simple, ces bugs m’agacent, car ils vont complexifier le projet. Je n’attendais pas de me heurter à des problèmes techniques aussi basiques à un stade aussi peu avancé.

Donc pour le moment, je mets ce projet de côté et je repars sur mon autre projet: la fraiseuse.

En attendant, j’ai mis à disposition de tous le code de démarrage que j’utilise pour faire fonctionner le cpu ARM Tiva. J’ai fait un projet github avec tous les codes communs qui évitent de ‘réinventer la roue’. J’ai choisi la licence WTFPL pour son coté humoristique et très proche du domaine public. En effet, je trouve indécent de vouloir mettre des licences restrictives (dites libres ou non) sur un code aussi basique et aussi nécessaire. Ca se passe sur github:

http://www.github.com/f4grx/freestella