Challenge NumWorks++ | Flash chip hardware mod

[Lionel Debroux]

Version française / English version

Objectif :

Réussir à upgrader matériellement sa calculatrice NumWorks pour la doter d'une mémoire Flash externe à l'emplacement prévu pour sur la carte mère.

Cet emplacement, c'est le "U7" sur les schémas. On peut le voir sur la photo ci-contre, à gauche.
Et même en vidéo, avec un chip de flash :

Show/Hide spoilerAfficher/Masquer le spoiler

Officiellement, ce U7 est prévu pour un AT25SF641, "64-Mbit, 2.7V Minimum SPI Serial Flash Memory with Dual I/O, Quad I/O and QPI Support".
Cependant, il semble possible d'utiliser une Flash NOR similaire (même boîtier SOIC-8, même pin layout, même tension d’alimentation, consommations typiques / pic et timings similaires) de 64 ou 128 Mbits (8 ou 16 MB).
Les mémoires Flash NOR QSPI de 256 Mbits et plus utilisent souvent d’autres boîtiers, comme SOIC-16 ou WSON-8, nécessitant une adaptation matérielle, et sont donc plus difficiles à intégrer par des utilisateurs moins expérimentés/outillés.

Il est nettement préférable de coopérer avec les autres développeurs qui s’intéressent à réaliser la même opération pour accélérer le processus… et également de ne pas interférer, voire de collaborer, avec NumWorks.

Goal :

Make a successful hardware upgrade of your NumWorks calculator, adding an external Flash memory chip onto the suitable location of the motherboard.

This location is labeled "U7" on the schematics). You can see it in this photo, on the left side.
And even in this official video, with a Flash chip:

Show/Hide spoilerAfficher/Masquer le spoiler

The official purpose of that location on the motherboard is to house a AT25SF641 chip : "64-Mbit, 2.7V Minimum SPI Serial Flash Memory with Dual I/O, Quad I/O and QPI Support".
However, using a similar chip (same SOIC-8 package, same pin layout, same supply voltage, similar typical / peak power consumptions) providing 64 or 128 Mbits (8 or 16 MB) of NOR Flash memory. QSPI NOR Flash memories of capacity larger than or equal to 256 Mbits often use different packages, e.g. SOIC-16 or WSON-8, requiring some kind of hardware adaptation, and therefore are harder for users with lower skills or worse tooling to integrate.

Collaborating with fellow developers who have the same aim is highly desirable to proceed faster… as is lack of interference with, or even collaboration with, NumWorks.

Ce qu'il faut faire :

Partie matérielle :
Souder le chip de Flash, 8 plots au pas de 1.27mm (1/20”, 50 mils). C’est bien sûr plus difficile que de souder du matériel au pas de 2.54mm ou 2mm, mais reste accessible. Comme toujours, il ne faut pas trop chauffer le chip et le PCB.
Note additionnelle: il est possible que l’ajout du chip ait un impact sur l'alimentation globale sur la carte mère. Peut-être faut-il s'attendre à des complications à ce niveau là ?

Partie logicielle :

• Ajouter (éventuellement récupérer et adapter) dans l’OS NumWorks un framework et des drivers pour des chips externes de Flash
  Voir la datasheet du chip ciblé. Au minimum, le framework d’accès bas niveau à la Flash externe devrait être prévu pour sélectionner un chip de Flash parmi plusieurs à la compilation, mais ça serait encore mieux si on complétait (les deux ne sont pas mutuellement exclusifs) ceci par une sélection dynamique / validation au runtime, basée sur les données CFI;
• Prouver que le chip de Flash est utilisable et utilisé
  1ère étape : fournir une démonstration simple, vraisemblablement assez rapide à développer, de votre choix. Une des possibilités est d’effacer une partie de la mémoire externe, puis d’y écrire une application embarquée dans le firmware mais indépendante du reste du firmware, ceci lors du démarrage de l’OS (le premier, ou à chaque fois). Un exemple d’application pourrait être un petit jeu avec sauvegarde des paramètres et/ou highscores.
  2ème étape : fournir une démonstration plus complexe: embarquer dans l’OS une application destinée à s’exécuter en mémoire externe qui dépend du code (fonctions de calcul flottant, etc.) de l’OS en mémoire interne. Ceci nécessite du travail sur le système de build et probablement sur certains aspects de l’OS lui-même. Une des applications les plus difficiles à déporter est probablement l'application Python.

What you need to do:

In the hardware area:
Solder the Flash chip, 8 pins with 1.27mm (1/20”, 50 mils) spacing. Of course, it’s harder than soldering hardware with 2.54mm or 2mm spacing, but it remains reasonably easy. As usual, excessive heating of the chip and the PCB is a bad thing to do.
Additional note: the addition of a chip might impact the global power supply chain on the motherboard. Maybe some issues are to be expected in that area ?

In the software area:

• Add (possibly by borrowing and modifying) a framework and drivers for external Flash chips to NumWorks’ OS
  See the targeted chip’s datasheet. At a minimum, the framework for low-level access to an external Flash memory should be designed to allow selecting a single Flash chip from a set at compile time, but it would be even better if compile-time selection were complemented (they’re not mutually exclusive) by runtime selection / validation of the chip, based on CFI data;
• Prove that the Flash memory chip is usable and being used
  1st step : build a simple showcase of your choice, whose development should be relatively quick. One of the options is to erase a portion of the external memory, then write an application embedded into the main firmware but independent from it, when the OS boots (for the first time, or every time). For instance, a small game which saves configuration and/or highscores.
  2nd step : build a more complex showcase: embed into the OS an application designed to execute from external memory, depending from code (e.g. floating-point functions) from the OS in internal memory. This needs some work on the build system and probably the OS itself. The Python application is probably the hardest to move.

Challenge additionnel niveau software :
L’étape suivante, encore plus difficile, mais beaucoup plus utile, est de coder une méthode générique de transfert de firmware vers la mémoire Flash externe. C’est utile pour gérer plusieurs applications en mémoire externe (c’est une autre étape, mais pas très différente de la gestion d’une seule application en mémoire externe), et nécessaire si on veut pouvoir utiliser plus de code+données que ce qui peut rentrer en mémoire interne, comme le PoC de portage NumWorks réalisé par Bernard Parisse sur le simulateur NumWorks.

Quelques ressources et informations:

Additional software challenge :
The next step, which is even harder but much more useful, is to provide a generic way to transfer firmware to external Flash memory. This is useful to handle multiple applications in external memory (another step, but not that different from handling a single application in external memory), and a prerequisite for using of an amount of code+data too large to fit into the internal memory, such as the NumWorks Giac port PoC performed by Bernard Parisse on the NumWorks simulator.

Several resources and pieces of information:

Show/Hide spoilerAfficher/Masquer le spoiler

• Le boot code du STM32F412VG, qui s’occupe du transfert du firmware à travers USB en utilisant le protocole DFU, ne semble pas gérer le flashage d’une mémoire externe, cf. AN2606 “STM32 microcontroller system memory boot mode”. C’est au demeurant compréhensible, parce qu’il y a une grande variété de chips de mémoire externe, disposant de jeux de commandes variés, et qu’il faudrait donner à l’utilisateur le moyen de modifier ce bootloader pour ajouter le support de ses chips…
• AN4852 “Programming an external Flash memory using the UART bootloader built-in STM32 microcontrollers” : http://www.st.com/content/ccc/resource/ ... 281415.pdf
  Logiciel correspondant à cette AN :
  http://www.st.com/en/embedded-software/ ... tboot.html. Protocole utilisé: AN3155.
• Autres logiciels pour STM32, dont des stacks USB :
  http://www.st.com/en/embedded-software/ ... tware.html.

Au pire, il est toujours possible de modifier/faire et utiliser un firmware spécial pour la mémoire interne capable de flasher la mémoire externe, qui s’utiliserait de la façon suivante:

• en utilisant le bootloader ST, transférer par DFU le FW spécial de flashage de la mémoire externe, comme les autres FW pour mémoire interne;
• en utilisant le FW spécial, transférer par un certain protocole, logiquement DFU, les données pour la mémoire externe et les écrire au fur et à mesure;
• en utilisant de nouveau le bootloader ST, transférer par DFU vers la mémoire interne la partie principale du FW NumWorks…

Cette capacité de flashage de la mémoire externe à travers DFU pourrait être intégrée au firmware standard, et avoir une stack USB intégrée au firmware standard serait de toute façon une bonne idée pour le long terme, mais c’est plus de travail.

Show/Hide spoilerAfficher/Masquer le spoiler

• The STM32F412VG’s boot code, which handles firmware transfer through USB using the DFU protocol, doesn’t seem to handle flashing an external memory chip, see AN2606 “STM32 microcontroller system memory boot mode”. This is understandable, given that there’s a huge variety of external memory chips with different command sets, and therefore, users would need a way to modify the bootloader in order to add support for the chips they want to target…
• AN4852 “Programming an external Flash memory using the UART bootloader built-in STM32 microcontrollers” : http://www.st.com/content/ccc/resource/ ... 281415.pdf
  The software corresponding to this AN is:
  http://www.st.com/en/embedded-software/ ... tboot.html. The protocol used is described in AN3155.
• Other pieces of software for the STM32 family, among which are USB stacks:
  http://www.st.com/en/embedded-software/ ... tware.html.

In the worst case, one can modify/create and use a special firmware suitable for internal memory, able to reflash external memory. The usage flow would be as follows:

• using ST’s bootloader to make a DFU transfer of the special FW for reflashing the external memory, just like other firmwares suitable for internal memory;
• using the special firmware to make a (probably DFU) transfer of the data to be written into external memory, and write these data blocks the fly;
• using ST’s bootloader again to make a DFU transfer of the main part of the NumWorks firmware to internal memory…

The ability to flash external memory through DFU could be integrated into the standard firmware, and integrating an USB stack to the standard firmware would be a good thing for the longer term anyway, but it’s more work.

Participation de TI-Planet/UPECS :

Achat + livraison de 2 chips de Flash (un 8 Mo, un 16 Mo avec les mêmes tension d’alimentation, consommation, timings, pas de bloc de boot) à ceux qui voudraient participer, dans la limite des stocks :

• L'"officiel" listé sur les schémas de NumWorks (64 Mbits = 8 Mo) : Adesto AT25SF641-SUB-T.
• Un autre, avec 2x plus de capacité (128 Mbits = 16 Mo) : Winbond W25Q128JVSIQ.

Si vous avez la capacité de réaliser des adaptations matérielles, vous pouvez utiliser par exemple des W25Q257JV (256 Mbits) et W25Q512JV (512 Mbits, consommation un peu plus élevée) dont les boîtiers WSON-8 ont le même pinout que le SOIC-8 du W25Q128JV et dont les boîtiers SOIC-16 sont plus faciles à souder que les boîtiers WSON-8, mais vous devrez vous débrouiller pour les acheter


Lots à gagner :
Si vous réussissez, vous vous aurez fait votre propre cadeau: une "NumWorks++"... Mais, on peut aller un peu plus loin :

• Bien entendu des news à l'honneur du grand bidouilleur ou de l’équipe de grands bidouilleurs, et des possibilités rendues disponibles
• Compte(s) Premium TI-Planet
• Stickers TI-Planet et/ou autres goodies

Vous-êtes intéressé par le challenge et souhaitez participer ? Répondez au topic et/ou envoyez un court e-mail de présentation à info@tiplanet.org

What TI-Planet/UPECS takes care of :

We'll buy and ship 2 flash chips (one of 8 MB, and one of 16 MB with the same voltage, consumption, timings, lack of a boot block) to those willing to participate, as long as our supplies last:

• The "official" one listed on Numworks’ schematics (64 Mbits = 8 MB) : Adesto AT25SF641-SUB-T.
• The other, with twice the storage capacity (128 Mbits = 16 MB) : Winbond W25Q128JVSIQ.

If you can make hardware adaptations, you can use for instance W25Q257JV (256 Mbits) and W25Q512JV (512 Mbits, higher power consumption) chips whose WSON-8 packages have the same même pinout as the W25Q128JV’s SOIC-8 and whose SOIC-16 packages are easier to solder onto an adapter PCB than WSON-8 packages, but you’re on your own


Prizes :
If you succeed, you will have made yourself you own gift: a "NumWorks++"… But, we can go a little further:

• Of course, news articles about the great [team of] hacker(s) and the possibilities made available
• Premium TI-Planet account(s)
• TI-Planet stickers and/or other goodies

If you're interested in the challenge and would you like to participate, reply to the topic and/or drop a short introduction e-mail to info@tiplanet.org

News rédigée par / written by Lionel & Adriweb.

[darthvader]

pour brancher le w25m512jv en SOIC-16 (64Mb) il suffit de faire comme ca :



Pour la broche Reset (qui est sur IO3 broche 7 du chip en SOIC-8 je ne sais pas si c'est necessaire.

[Lionel Debroux]

C'est ce genre d'adaptation matérielle dont je parlais, en effet
Le plus gros problème, à mon sens, est d'obtenir un assemblage mécaniquement solide:
* des fils volants sont simples et pas chers mais pas solides, donc l'usage dans le monde réel et la réplicabilité de la bidouille vont souffrir;
* un PCB pour déporter le SOIC-16 sera solide, mais réaliser un PCB custom pour ça va être cher.

[jean-baptiste boric]

Vous-êtes intéressé par le challenge et souhaitez participer ? Répondez au topic et/ou envoyez un court e-mail de présentation à info@tiplanet.org

Ma foi, après la défiguration totale et sans pitié de l'une de mes HP Prime FOR SCIENCE!, il serait logique de mutiler ma Numworks ensuite... Allez, je suis partant.

[Adriweb]

Ma foi, après la défiguration totale et sans pitié de l'une de mes HP Prime FOR SCIENCE!, il serait logique de mutiler ma Numworks ensuite... Allez, je suis partant.

On n'est pas surpris de ta volonté de participer \o/

Du coup, envoie nous ton adresse postale par email, et on va voir si on bufferise ou non les commandes de chips.

[toml_12953]

Pour la broche Reset (qui est sur IO3 broche 7 du chip en SOIC-8 je ne sais pas si c'est necessaire.

La broche RESET doit être connectée à un pullup externe.

The RESET pin must be connected to an external pullup.

Tom L

[Wistaro]

Intéressant !

Je participerai bien, si j'avais le temps (et une calculatrice NumWorks!)

En tout cas j'ai hâte de voir comment les participants vont se débrouiller

Bonne chance à tous!

[critor]

Quand on regarde bien la photo, est-ce que le bon fonctionnement de la puce Flash manquante en U7 ne nécessiterait pas aussi les composants manquants en R15 (résistance) et Q4 (transistor) ?

[jean-baptiste boric]

Quand on regarde bien la photo, est-ce que le bon fonctionnement de la puce Flash manquante en U7 ne nécessiterait pas aussi les composants manquants en R15 (résistance) et Q4 (transistor) ?

D'après les schematics, c'est un... truc... pour la VDD du connecteur microSD (je ne suis pas électronicien).

Edit: au pif, je dirais un circuit de stabilisation d'alimentation pour la microSD.

A priori, il ne manque aucun composant pour la puce flash.

[critor]

Ok, merci. Je faisais donc trop confiance à leur découpage visuel de la carte mère en différentes zones.