Challenge NumWorks++ | Flash chip hardware mod

[critor]

Reçu également les puces Adesto 8Mio :

[zardam]

De mon coté, pas encore de flash, par contre j'ai fini par installer un debugger pour pouvoir maniper plus facilement. Du coup, tombé sur un bug dans la définition des registres : https://github.com/zardam/epsilon/commi ... 9e1d851e21

Maintenant, j'ai bien les signaux d'horloge/data sur les pins dédiés à la flash

[Adriweb]

Haha, bien vu Tu devrais soumettre une PR.

Par ailleurs, envoie nous (info [at] tiplanet.org) ton adresse postale comme ça on pourra t'envoyer les 2 chips de flash

Bravo, sinon, ça a l'air de bien avancer !

[coco33920]

Bonjour, je souhaiterais mettre une puce 8MO dans l'optique d'intégrer le calcul formel dessus, pouvez vous me communiquer le site sur lequel acheter le composant ?
Merci,
Colin.

[Adriweb]

Tu peux la trouver ici : http://www.mouser.fr/search/ProductDeta ... F641-SUB-T ou ici https://www.arrow.com/fr-fr/products/at ... ration-inc

[coco33920]

Merci, j'avais vu sur mouser mais 20€ de frais de ports pour une puce a 0.74€, je l'ai commandée chez arrow ( Fedex economy long mais pas de frais de ports ^^ )
Bon du coup la puce elle va arriver, souder mon père sait très bien faire ça et il va le faire manque plus que la partie software, comme écrit au premier message en théorie il suffirait juste de récupérer un driver pour arm ?

[zardam]

Avec ma puce de flash de 1Mo (retirée d'un ESP8266 donc déjà programmée), je lis bien des choses de façon répétable depuis la flash externe :

Code: Select all

(gdb) x/32xb 0x90000000
0x90000000:   0xa9   0x03   0x00   0x20   0x00   0x00   0x10   0x00
0x90000008:   0x00   0x00   0x10   0x00   0x88   0x30   0x00   0x00
0x90000010:   0x00   0x00   0x10   0x00   0x21   0xbb   0xbb   0x20
0x90000018:   0xa3   0x13   0x81   0x12   0x00   0x00   0x00   0x00


Reste à savoir si c'est correct, mais le plus facile semble fait. Il faut maintenant passer par l'envoi de commandes vers la flash, histoire de pouvoir la programmer depuis la calculatrice.

Une petite photo du champ de bataille pour la route :

[Lionel Debroux]

Bien
L'assemblage réalisé pour pouvoir changer plus facilement de chip, et utiliser GDB, est intéressant.

En effet, l'étape suivante est d'envoyer des commandes vers la Flash. Je suggère de commencer par le mode queries CFI, qui est géré par virtuellement tous les chips, au moins pour obtenir les IDs du fabricant et du modèle (2 premiers mots de 16 bits).

Je reposte ce que j'avais posté dans le topic interne qui a servi de brouillon à celui-ci, et que je m'aperçois que je n'ai pas encore re-posté en public, parce que je pense que le design en couches tient la route, même si l'implémentation pourrait être un peu différente (du genre, tableau de structs contenant des pointeurs de fonction - on ne l'avait pas fait puisqu'on n'avait qu'un modèle de chip à gérer). Il est probable que tu saches déjà ce qui suit

Lors de mon stage de fin d'études en binôme, il y a 10 ans maintenant, on avait implémenté (c'était une partie dont j'étais davantage en charge que mon binôme, mais je pense qu'on avait au moins discuté ensemble des couches du design) un framework + driver simple de gestion de mémoire Flash pour une carte Analog Devices basée sur un processeur/DSP Blackfin. On programmait en C++, en tirant partie seulement de l'héritage et de la composition. A l'époque, c'était mon premier vrai projet de C++, dans lequel je faisais autre chose que modifier le contenu de méthodes existantes.
J'avais aussi rédigé une documentation un peu générale sur la gestion d'une mémoire Flash (à l'époque, je crois que je n'étais pas conscient de la différence entre une Flash NOR, telle que celles de ces cartes Blackfin et celles des TI-68k que je connaissais, et une Flash NAND) et le design du framework; une des questions de la soutenance, posée par un des profs que nous avions invités, qui nous a malheureusement quittés quelques années plus tard, avait porté sur le design et la flexibilité - ciblage d'autres chips de Flash - de ce framework.

Bref - il y avait 3 couches permettant potentiellement le ciblage de plusieurs chips de Flash:
* la couche de plus bas niveau, qui s'occupait de réaliser les opérations unitaires spécifiques à ce chip de Flash, telles que décrites dans la datasheet. Il devait y avoir 2 ou 3 méthodes dans cette classe parce qu'on n'avait pas besoin de plus: essentiellement get status, single write, single block erase. Je ne sais plus si j'avais implémenté les queries CFI et les fast writes (ni si des commandes de ce type étaient gérées);
* la couche intermédiaire, qui implémentait notamment des opérations de block write en utilisant le single write en boucle (ou les fast writes s'ils étaient gérés), et de multiple block erase en utilisant le single block erase;
* la couche supérieure, qui fournissait des fonctions de plus haut niveau comme l'enregistrement d'un firmware, probablement une paire uint8_t * data + uint32_t length, dans le slot A ou le slot B qu'on avait définis en mémoire Flash, pour pouvoir garder le firmware de production et un firmware de backup.

D'une manière générale, la réalisation des opérations unitaires du chip consiste à envoyer, d'une façon ou d'une autre, des suites de commandes précises. Dans ce projet de stage de fin d'études, la Flash était directement mappée en mémoire (et ça serait pareil sur la NumWorks, sinon aucun intérêt de mettre de la Flash NOR), et il fallait envoyer des commandes à des adresses précises comme 0x554/0x555 ou 0x5554/0x5555, 0xAAA ou 0xAAAA, avant de cibler l'adresse qu'on veut écrire dans le cas du single write / effacer dans le cas du block erase. Les suites de commandes de ce chip sont d'autant plus longues et plus complexes qu'elles sont destructives, ce que j'avais attribué à la volonté de minimiser la probabilité que des commandes dangereuses soient déclenchées par hasard (crash de la machine).

Je n'ai jamais soudé du matériel au pas de 1.27mm, mais au-delà de ce que j'ai soudé en cours de techno comme la plupart des élèves, j'ai utilisé de nouveau des fers à souder lors du stage de fin d'études et dans mon précédent emploi; dans ce dernier, j'ai vu que les élèves qui ont soudé des choses au pas de 1.27mm étaient plus des informaticiens que des électroniciens.

[critor]

Photo mémorable en effet, bravo !

[Adriweb]

On m'a dit qu'utiliser quelque chose de ce genre : https://www.aliexpress.com/item/ST-Link ... 63657.html pouvait grandement aider, donc je partage