Reverse engineering du protocole de diagnostic Rover

Oui je viens de voir, je sais pas ce qu'il manque du coup... y a meme l'interface d'adaptation du signal...

Il manque pas grand chose oui, mais quand même de quoi régler le CO et le stepper pour le ralenti.

Et puis l'idée d'en faire un soft plus générique qui permet de rentrer d'autres chaines d'init pour passer d'autres caisses à base de MEMS 1.6

Je poste ce soir l'avancement, car coté acquisition du signal je suis presque bon. Faut juste que je vous mette ça en image, le dénouement est assez inattendu

Alors, voilà ce qu'il faut faire pour avoir des signaux propre avec cet outil de diagnostique de mes deux.

J'utilise le Rover POD 3 qui me donne ça comme signaux :




On voit donc des merdes de palier qui ne sont pas du TTL.

Colin (le gars du site CMB) a qui j'avais posé la question des niveaux logiques hors norme et la raison m'a répondu. Lui a du bon matos et à tout de suite vu ce problème. Le problème est tout simplement le Rover POD 3 qui gère mal les signaux et les dénatures ! Le calculo s'en débrouille par chance.
Il a la chance d'avoir accès à un très vieux lecteurs de code défaut de Sykes Pickavant et a utilisé le Rover POD 1 pour monitorer les signaux et il a fait le reverse comme ça du protocol.

Perso je n'ai pas de vieux lecteur, MAIS j'ai trouvé un vieux POD version 1 que l'on ne m'a pas volé avec ma MPI. Seulement ça ne va pas dans les lecteurs actuels. En y regardant de prêt on voit que malgré tout que le connecteur des POD version 1 et 3 est strictement identique. Il suffit donc de couper un peu de plastique pour rentrer le vieux POD dans le nouveau lecteur, comme ceci :




Ce qui donne une cartouche qui ne bloque plus avant d'atteindre le connecteur du lecteur et rentre parfaitement :




Ensuite, il suffit que j'utilise mon interface bricolée pour intercepter les signaux sur les 2 lignes IN et OUT, ça donne à l'oscillo à mémoire ceci :



Je m'attendais à trouver des F4 et des 80 d'après le commandes documentées sur le site de Colin. 80 n'est pas une valeur super reconnaissable au niveau du train de bits, mais F4 l'est et il n'y a donc pas de doute possible.
On voit bien l'outil de diag envoyer F4, l'ECU répond F4 puis 00, ensuite l'outil de diag demande la frame contenant les valeurs des sondes via la commande 80 et la réponse suit.

Ceci me permet donc de valider que je ne fais pas de connerie, mais ça reste malgré tout inutile car le Rover POD 3 ne possède pas les fonctions d'ajustement de Stepper pour le ralenti et le réglage de pollution pour le CO .

Maintenant, n'ayant pas d'analyseur logique qui sait gérer le tensions exotiques, je dois faire un bout de circuit qui met en forme proprement les tensions en les abaissants à 0V, rebrancher le POD version 3 et utiliser ensuite mon analyseur de contrefaçon à $10.

C'est pas rapide mais ça avance ...

C'est sur la bonne voie. Est-ce que ces paliers intermédiaires ne seraient pas un brouillage pour éviter que des petits malins lisent trop facilement le signal ?

trumpet a écrit:

C'est sur la bonne voie. Est-ce que ces paliers intermédiaires ne seraient pas un brouillage pour éviter que des petits malins lisent trop facilement le signal ?

Non c'est des gorets qui ont fait le POD V3

Ces outils de diagnostiques en après-vente sont parfois douteux et là on en a bien la preuve !

Un peu d'avancée sur le projet.

J'arrive donc à lire, comme j'aurais du le faire dès le premier jour, les échanges entre l'outil de diag et le Rover POD 1.

Une fois passé à l'analyseur logique ça donne ça :



Sur la capture ci-dessus on voit bien la demande 0xF4, suivie de l'echo 0xF4 0x00, puis la demande de frame 0x80 suivit de la réponse.

En dézoomant un peu ça donne donc des échanges réguliers :



On voit bien le début de la demande et les datas de réponse.


En terme de logs bruts ça donne pour la pinoche IN du calculo  :

Code:

Time [s],Value,Parity Error,Framing Error
0.16418,0xF4,,
0.1676,0x80,,
0.36036,0xF4,,
0.3636,0x80,,
0.55624,0xF4,,
0.5596,0x80,,
0.75236,0xF4,,
0.7556,0x80,,
0.94836,0xF4,,
0.9516,0x80,,
Etc ....

Les demandes d'état des sondes partent en gros toutes les 200ms.

Coté réponse de l'ECU, pinoche OUT ça cause un peu plus :

Code:

Time [s],Value,Parity Error,Framing Error
0.16552,0xF4,,
0.16656,0x00,,

0.17166,0x80,,
0.17728,0x1C,,
0.18238,0x00,,
0.18342,0x00,,
0.1885,0x51,,
0.19372,0xFF,,
0.19892,0x56,,
0.20422,0xFF,,
0.20942,0x62,,
0.21452,0x88,,
0.21992,0x2D,,
0.22512,0x08,,
0.23032,0x10,,
0.23542,0x01,,
0.24084,0x00,,
0.24604,0x00,,
0.25124,0x00,,
0.25666,0x28,,
0.26174,0x7B,,
0.26694,0x8B,,
0.27236,0x04,,
0.2734,0x97,,
0.27828,0x00,,
0.2836,0x38,,
0.2889,0x09,,
0.28994,0xBA,,
0.29482,0x00,,
0.30004,0x00,,
0.30534,0x00,,

0.36152,0xF4,,
0.36256,0x00,,

0.36786,0x80,,
0.37328,0x1C,,
0.37848,0x00,,
0.37962,0x00,,
0.3845,0x50,,
0.3897,0xFF,,
0.3949,0x56,,
0.40022,0xFF,,
0.40532,0x62,,
0.41052,0x88,,
0.41592,0x2D,,
0.42102,0x08,,
0.42622,0x10,,
0.43142,0x01,,
0.43674,0x00,,
0.44204,0x00,,
0.44724,0x00,,
0.45254,0x28,,
0.45774,0x7B,,
0.46294,0x8B,,
0.46826,0x04,,
0.4693,0x97,,
0.47428,0x00,,
0.47948,0x38,,
0.4848,0x09,,
0.48584,0xBA,,
0.49072,0x00,,
0.49614,0x00,,
0.50124,0x00,,

On voit bien l'echo de la commande 0x80 suivi des 28 octets utiles des valeurs des diverses sondes et registres de l'ECU.

C'est donc OK pour étudier le protocole, mais c'est ce qu'à déjà fait Colin (site de Valant1) et j'ai rien à gratter la dessus pour le moment.

Maintenant la suite c'est retour au point de départ en ayant tout validé sur le POD V1 pour essayer de faire la même chose avec le POD V3. Il va falloir jouer un peu avec un ampliop ou un transistor ou deux pour adapter ces fausses tensions à la noix.

Tiens, je viens de trouver ça :
http://www.mini-forum.de/archive/index.php/t-38032.html

Sur cette page, traduit salement par Google, un gars parle de la pinoche OUT que je n'arrive pas à lire et est très étonné de l'étage de sortie :

"
En conséquence Pin # 10 est la sortie de données (TxD de l'ECU de vue) - Couleur de câble blanc-jaune.
La sortie est activée à 5V avec un transistor MOS de type P - qui est le transistor en boîtier SOT223, l'au l'image de Dougie presque pas reconnaissable sous le capteur de pression négative est (type BSP205 comment l'autre en vertu de la puce Philips mystérieuse).
Sur le dos de platine, il ya encore un transistor (ou diodes de serrage) dans un boîtier SOT23 de la sortie de données se connecte en quelque sorte à la terre. Toutefois, cette puce a un comportement totalement confus: Il est ni transistor NPN, PNP encore - du moins pas si il avait une occupation standard. Puis 10 encore connectés entre le MOSFET et le Pin # Une résistance 1.3k avec un condensateur (capacité = ?? nF) à la masse. Pourquoi presque chaque signal entrant est il relié à un condensateur à la terre est au delà de moi ...
À moins que ces Pinöppels roses sont pas condensateurs ... hm.
"

En gros, il y a un sacré mic-mac sur cette sortie qui est donc tout sauf du TTL ...


Et il donne aussi une explication de pourquoi j'ai pas eu de merde sur le pinoche IN :

"
Avec un 74HC14 (trigger de Schmitt inverseur), le signal est tamponné et un peu "nettoyée".
"

C'est un simple CI TTL 74HCxx qui reçoit le signal de l'outil de diag, et j'arrive à le lire depuis le début avec mes modules USB, l'analyseur logique. Normal.

Et d'ailleurs, sur cette page de forum archivée participe tous les gars qui ont fait le calculo programmable de SPI, l'UMS ! Ils devaient à peine se connaitre à l'époque et commençaient le reverse.

C'est génial tout ça  .... je bit rien  et je sais même pas si c'est du 4 ou du 8

ben avec 4 bits on a bien du mal à faire quelquechose, donc c'est au moins 8.
Bon avec un analyseur logique comme ça tu dois y arriver, c'est le rêve ce truc.

Oui c'est du siècle d'avant, mais c'est quand même 8 bits

Pour le rêve, il est quand même relativement accessible celui là :
http://www.dx.com/p/logic-analyzer-w-dupont-lines-and-usb-cable-for-scm-black-148945#.Vb--CPlYDJU



Bon ensuite, le soft USBEE il marche pas sous Linux, il est pourrit, faut cracker etc. Alors il faut le convertir en analyseur logique de la marque SALEAE qui a un soft au top (celui des captures ci-dessus). La procédure est là :
http://www.jwandrews.co.uk/2011/12/saleae-logic-analyser-clone-teardown-and-reprogramming/

Quand le copieur copié est recopié par les Chinois, ça fait un cout de $10 à l'arrivée


Ensuite, le rêve c'est le matos avec un prix à 5 chiffres qui me permettrait de faire le shift de tension directement sans faire de conversion de merde avec des transistors ou un AOP !

La dernière fois que je me suis servi d'un anaylseur logique ça doit faire... je m'en rappelle même plus... même si c'était du matériel de pointe je t'assure qu'on en était pas là. Mais c'était déjà très pratique ! C'est fou ce qu'on peut avoir pour une poignée de figues maintenant.
Avec un processeur 8 bits bien mené on peut en faire des choses quand même, et au moins ça marche même sur un bout de carte à essai. Pas de problème d'induction sur le bus à 500MHz qui passe dans la 9ème couche de la carte ou je ne sais quoi...