Japan Car

Salut,
En ce moment je suis entrain d'étudier le composant qui intégre la ROM et la RAM dans les ecu nissan, ceux qui ont besoin d'une daugterboard, bien entendu il y a une doc qui circule sur le net mais à voir le mapping mémoire de la doc et le dump de la mémoire rien ou presque ne correspond, le mapping est différent bien que le pinout est identique, donc il faut étudier pour comprendre et là il y a pas 36 solutions il faut l'interfacer :

Et voilà, j'ai craqué :


J'ai dessoudé l'espèce de ROM/RAM/IO_extender qui est dans de nombreux ECU nissan et j'ai décidé de l'étudier pour mieux comprendre ce truc non(ou mal)-documenté !



J'adore cette image, elle montre le bordel que c'est que de vouloir étudier ce truc :


Donc au final rien que pour l'interface MCU (le circuit intégré noir et allongé) et RAM/ROM (le circuit intégré suspendu) il faut compter 27 fils (sans compter l'alimentation et les fils de configuration : environ 10 fils en plus).
L'MCU est un atmel atmega 644 (que j'utilise souvent ponctuellement pour faire tout ce que je veux), il dispose de 32 entrées/sortie configurable et coup de chance incroyable il ne demande que 3 pins pour le programmer et 2 pins pour communiquer avec l'extérieur via une liaison série, donc les 27 de l'interface + 3 + 2 = 32 pile poil !

La lecture/écriture se fera depuis une bécane linux via une liaison série, ce soir si tout se passe bien ça sera fait !

Le composant est un JECS A12-281001 soit disant un M6M72561J de mitsu, mais si d'apparence c'est bien lui à l'intérieur c'est pas tout à fait le cas !

Donc si des tarés veulent que je fasse une batterie de tests qu'ils me contactent tant que c'est en place, je vais pas m'amuser à recâbler ça une fois démonté !

fichtre! beau boulot

contacte asphalt,ou RC200(romchip),des fois que.......

sinon,perso,je vois pas quoi te demander,techniquement parlant,mes competences s'arretent un peu dans ces alentours

moi j'aurai une petite question mais qui na pas grand choses en commun avec le sujet .

sur les gestion des voitures recente a partir de 2004 avec une fiche diag obd0 ils disent qu'on peu reprogramer avec un bete cable et un pc ,j'ai entendu dir que le flashage de la "puce" est limité es ce vrais ?

je supose aussi qu'il ya des risques déja que j'ai jamais eu envie de flashé le bios d'un de mes pc

Coucou,
Bon j'ai oublié de tenir à jour le topic, donc après moult colère et énervement et aussi tentatives j'ai enfin trouvé le problème qui m'empêchais de faire une lecture de la bestiole, la doc de mitsubishi est très... comment dire "fait à l'arrache" donc faut vraiment lire de A à Z la doc pour comprendre !

Donc j'arrive à faire une lecture 8 bits de la ROM et RAM, et je devrais bientôt arriver à y écrire d'ici sous peu (dans la RAM), mais de temps en temps il arrive qu'un parasite arrive à corrompre la lecture, mais quand on regarde l'installation le contraire aurait étonné, il suffit de réduire la vitesse pour arriver à une lecture fiable ! ouf !

Donc le composant en question cache un problème de taille :
-le dump sous CONSULT donne un résultat différent d'une lecture direct

La cause ? un autre composant mémoire en parallèle sur le bus qui va modifier, la suite à venir dès que j'en ais terminé !

Nos1985 Je pense que tu fais allusion à l'odb2 qui permet de flasher l'ECU, hors ici nos bestioles sont en ODB1 et c'est pas possible.

Tout ce qui contient une puce pour stocker des informations même si courant coupé ne permet pas un cycle d'écriture illimité ! Dans la liste ou peut citer :
-clé usb
-carte mémoire d'appareil photo/mp3/etc...
-mémoire flash des microcontrolleurs (atmel, pic, freescale, etc...) qu'on trouve dans les DVD, voiture, bios de pc, etc...
-le NATS (antivol nissan)

la raison est simple : pour écrire un octet on doit appliquer un voltage légèrement supérieur à ce qu'une "cellule" peut supporter pendant un laps de temps très court, mais cela suffit à dégrader la cellule, a force d'y écrire un beau jour elle sera morte.

En général les puces peuvent tenir 10ans (rétention d'information) et 1.000.000 de cycles d'écriture donc ça fait une marge !

Si les clé USB sont rapidement morte c'est que 1.000.000 de cycle en quelques années ou mois c'est très rapidement atteins surtout avec une partition NTFS/FAT32 et une système d'explotation comme windows qui fait un peu n'imp en continu, ainsi à votre insu windows s'amuse à déplacer les donner, trié, organiser (d'où les problèmes si on débranche une clé sans demander à windows de déconnecter le périphérique) et à la longue des secteurs entier sont mort !

Un jour les propriétaire de nissan (et d'autres marques) auront un problème avec le NATS, car à chaque démarrage l'ECU va écrire dans une puce ayant les specs cité plus haut, donc en démarrant deux fois par jours dans 1300 ans la mémoire va poser problème

Et si je démarre 2 fois par an (ce qui doit pas être loin de la vérité), je peux tenir combien de temps ?

NutCracker a écrit :Donc le composant en question cache un problème de taille :
-le dump sous CONSULT donne un résultat différent d'une lecture direct

La cause ? un autre composant mémoire en parallèle sur le bus qui va modifier, la suite à venir dès que j'en ais terminé !

Tiens, ça m'intéresse ça, ça pourrait expliquer pourquoi mes dumps correspondent pas à ce que j'ai pu dumper de certaines eproms ... (mais il est aussi fort probable que j'ai pas été capable de les dumper correctement )

folken a écrit :Et si je démarre 2 fois par an (ce qui doit pas être loin de la vérité), je peux tenir combien de temps ?

Tu laisse tourner le moteur entre temps ?

folken a écrit :

NutCracker a écrit :Donc le composant en question cache un problème de taille :
-le dump sous CONSULT donne un résultat différent d'une lecture direct

La cause ? un autre composant mémoire en parallèle sur le bus qui va modifier, la suite à venir dès que j'en ais terminé !

Tiens, ça m'intéresse ça, ça pourrait expliquer pourquoi mes dumps correspondent pas à ce que j'ai pu dumper de certaines eproms ... (mais il est aussi fort probable que j'ai pas été capable de les dumper correctement )

Je préfère ne pas m'avancer pour l'instant, mais dès que j'en sais plus je te tiens au courant, ce que je peux t'affirmer c'est :
-Un dump avec CONSULT désassembler avec IDA Pro te donnera un résultat correct mais en regardant en détaille tu va voir que des portions de code vont tomber inévitablement dans ce qui semble être une portion de RAM et donc l'issu est très incertaine !
Le truc choquant c'est la table des vecteurs d'interruption (reset, division par 0, rx, tx, convertisseur, etc...) certaine adresse pointe directement en RAM !!! donc là aussi c'est un peu de la science fiction !
Le problème semble être au niveau des ECU dit "64k" avec un dump de 64k justement ! lol !

Dans ton dump tu aura forcément une partie de RAM succeptible d'être variable selon le moment ou la méthode du dump, rien de choquant, mais que la ROM (en read only et de type OTP) soit modifié c'est paranormal, une seule explication : une mémoire rom/ram en parallèle !

je post pour suivre

1er surprise : la ROM où se trouve le code et les cartographie ne fait pas 32ko comme l'annonce la pseudo-doc qu'on attribue à ce composant mais 49ko !
Effectivement la plage ROM va de 4000h (et non 8000h) à FFFFh.
Donc la RAM se trouve ailleurs, les registres de configuration aussi, bref tout est très différent sauf peut être le pinout !

j'ai rien compris mais je post pour voir ou tu arrive....

Tu peux me parler en langage électronique pour me décrire ce que tu cherches à faire, quel est ton but final ?