Archives par mot-clé : trf7970

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

 

Colis reçus !

Et voila, c’est fait. J’ai reçu ce matin le colis contenant mon eShapeOko, et la seule chose qui m’empêche maintenant de la monter, c’est le taraudage des makerslides, qui sera fait demain soir par mon ami radio-amateur Yves, F1BHY, que je remercie chaudement pour sa disponibilité et sa gentillesse. C’est un bricoleur extra, il manie parfaitement les machines outils et les outils classiques, et nous fait profiter de ses capacités!

Pièces eShapeOko
Pièces eShapeOko

J’ai aussi reçu les nouveaux échantillons de TRF7970 pour mon projet NFC, ce sont des composants en boitier QFN, dont la soudure s’est plutôt mal passée la dernière fois, qui était aussi la première. J’ai mis trop de pâte à souder, ce qui s’est traduit par un composant qui flottait dans l’étain liquide, et en voyant es billes d’étain qui se sont formées de chaque coté après refroidissement, je soupçonne fortement que les contacts soient en court circuit en dessous des boitiers. Seule une inspection par rayons X pourrait m’en informer, mais je n’ai pas ce moyen de mesure en stock :p En plus, si il n’y a pas de court circuit, je crains d’avoir fait un peu trop “bronzer” ces circuits à la station à air chaud.

D’autre part, j’ai fait une erreur de conception sur ces cartes, heureusement rattrapable: j’ai connecté les lignes VCORE au +3V3, ce qui est une erreur : VCore est une sortie, connectée au régulateur interne, et elle ne sert qu’à la connexion de capas de découplage! Du coup, la ligne 1,2 volts s’est retrouvée alimentée en 3V3! Une hérésie! La bonne nouvelle numéro 1, c’est que j’ai réussi à soulever les pattes du TQFP et à y souder des capas CMS “en volant”. La deuxième bonne nouvelle, c’est que le circuit marche encore, ce que je trouve assez extraordinaire sachant que j’ai injecté une “haute tension” sur la sortie d’un LDO interne… Enfin, je vais quand même utiliser un nouveau circuit “propre” sur la carte de test 😀

Les composants sont faits pour être soudés sur une carte SeeedStudio, qui est déja étamée. Je pense qu’avec le flux que j’ai récupéré entre temps, cet étain déja déposé est largement suffisant pour souder les composants. Je vais donc essayer de souder ces QFN avec une bonne quantité de flux, mais sans étain supplémentaire, et on va voir.

A coté des QFN, la soudure des ARM en TQFP est une partie de plaisir 😀

Je vous tiendrai au courant bien plus souvent, maintenant que la machine est arrivée! Pour info, j’ai également démarré un sujet “build log” (en anglais) sur le forum officiel de la ShapeOko, qui contient un max d’informations sur ces machines, avec les modifications que les gens ont réalisées, et les erreurs à ne pas commettre. Une des améliorations décrites là bas que je trouve le plus intéressante est la modification de l’axe Z pour utiliser une “ACME screw”, autrement dit une vis à pas trapézoïdal. Le but est d’accélérer les mouvements sur l’axe Z (le pas de la vis est plus important), ce qui accélère globalement toute la machine. Nous aurons donc bientôt une amélioration à ce niveau dès que j’aurai trouvé un bon fournisseur pour ce matériel, et surtout quand la machine actuelle fonctionnera 😀 En réalité, je peux déja jouer sur le mode de déplacement micro-pas de l’axe Z pour accélérer la cadence. A voir!