[résolu] lire puis reproduire un code série

Bon, c'est simple, j'ai la voiture de madame qui foire, c'est du renault 2000, c-à-d que c'est plein d'électronique et donc plein d'emmerdes.

l'émetteur de la clé est en IR avec un "code évolutif", code reçu par un décodeur qui envoie un autre code aussi évolutif au calculateur d'injection pour déverrouiller l'anti-démarrage (le calculateur refuse d'injecter de l'essence s'il ne reçoit pas le bon code).

et le code IR ne marche plus. n'allez pas m'embrouiller avec la méthode de resynchronisation clé / calculo, je la connais par coeur, et elle ne marche plus. j'ai passé l'oscillo en sortie du récepteur, la clé marche impec. là, c'est un problème Renault : trop d'électronique tue l'électronique. coût de la remise en marche chez renault : entre 300 et 600€.

comme j'ai des doutes sur le récepteur IR (présence de parasites en sortie), je pense à passer avec une télécommande RF à base de PT2262 / PT2272, c'est pas cher et fiable.

Mais il faut qu'un petit ATMEL envoie un code au calculateur pour lui dire de déverrouiller l'injection. je peux relever le code avec l'ICP1, mais comment trouver la loi évolutive (un code différent à chaque coup, et pourtant le calculateur le reconnait...) qui me permettra de générer un bon code à chaque coup...?

si l'un d'entre vous connait ça, je suis preneur!

C'est sans doute du rolling code (le code précédent permet de calculer le nouveau et ainsi de suite). Et le but d'un anti démarrage c'est justement de ne pas être piraté ... Et casser du rolling-code, je suis pas expert mais à ma connaissance c'est presque impossible :s

Super_Cinci:
...
comme j'ai des doutes sur le récepteur IR (présence de parasites en sortie), je pense à passer avec une télécommande RF à base de PT2262 / PT2272, c'est pas cher et fiable.

Mais il faut qu'un petit ATMEL envoie un code au calculateur pour lui dire de déverrouiller l'injection. je peux relever le code avec l'ICP1, mais comment trouver la loi évolutive (un code différent à chaque coup, et pourtant le calculateur le reconnait...) qui me permettra de générer un bon code à chaque coup...?
...

bonjour supercinci
c'est le principe de base des rolling ou hopping codes , evacuer les tentatives d'intrusions et là c'est bien ce que tu veux faire :grin:

comme c'est ta voiture , voir comment est traduite l'autorisation d'injection :
si ça se traduit par une simple autorisation logique ça doit etre assez facilement contournable, si c'est un dialogue regulier , ça risque d’être ardu

bonjour

quand ton calculo est verrouiller:

a tu toujours la synchronisation de ton capteur VR ? = étincelle au bougie (les 4) quand tu et en position démarrage (démarreur en route)
quand tu mais le contacte a tu le 12V sur t'es injecteur ? (les injecteur son contrôler par le - par le calculo certain antie démarrage coupe simplement le + aprer contacte qui va a tes 4 injo)
vérifie si tu a le - présent a tes injo quand tu et en position démarrage
ta pompe a essence se lance t'elle 5 seconde ? quand tu insère la clef est que tu te mais en position 2 juste avent le démarreur(mise sous pression du rail avent démarrage)

si tu a tout sa réunie il y a peut être une électrovanne planquer vers le rail ou t'es 4 injo son raccorder

tu peut bypasser certain antie démarrage

EDIT:

tu a 2 autre possibilité selon ton modèle mais je sas que sa se fait et tu peut demander a renault ou tester

1: avent d’insérer la clef verrouiller déverrouiller la centralisation sur certaine Renault sa stop l'antie démarrage 30 seconde tu a donc 30 seconde pour démarrer aprér ton verrouillage deverouillage

2 (être très patient): demander a renault le code manuel (avec ton calculo et clef il te le génère) tu a une led qui clignote a ton TB de bord chaque clignotement correspond a un chiffre et a chaque fois tu dois appuyer sur un bouton (dépend des modèle) c'est un code a 6 chiffre me semble t'il une fois entrer tu a 30seconde pour démarrer et tu doit répéter a chaque fois cette opération pour pouvoir redémarrer

Quand je dis aux gens que Renault c'est la pire daube ...

(désolé pour toi Super_Cinci)

+1 batto

étant dans le domaine je suis allergique au marque française (je dépanne que la famille et encore)

dans le domaine de la préparation quand tu parle au rectifieur quand les client leur enmene des vilebrequin ou tout autre pièces mobile du moteur de marque francaise au niveau des tolérance d’équilibrage ect... il prenne peur a chaque fois ^^ quand il les monte sur leur machine pour voir a combien de gramme de défaut a la pieces

B@tto:
Quand je dis aux gens que Renault c'est la pire daube ...

(désolé pour toi Super_Cinci)

d'accord avec toi, mais seulement à partir de 96/97, quand les normes sont apparues. jusque là tout allait bien (tout était accessible, et je sais de quoi je parle). Maintenant, c'est tellement pourri d'électronique que même si la méca reste fiable, on est toujours emm....

@ neodelavega, si seulement c'était le commun des injecteurs qui était coupé, ce serait trop facile. comme c'est un µP qui gère les commandes d'injection, il serait étonnant que l'interdiction ne se fasse pas dans le code (programme) lui-même, il suffit de ne pas configurer les timers correspondants tant qu'on n'a pas reçu le code de déblocage. Ainsi, on peut déclencher toutes les fonctions et registres que l'on veut, si le timer n'est pas initialisé, il ne fera rien... Mais tu as raison dans un sens, ça ne va pas coûter grand chose de vérifier...

Je suis dans le cas du code de secours dont tu parles au 2 de ton édit, ça marche, mais c'est relou. c'est d'ailleurs par ce code de secours que l'on fait la manip de resynchronisation clé(s) / décodeur. j'ai fait une fois cette manip et ça a marché il y a deux ans. mais ça ne veut plus aujourd'hui.

pour revenir au code "évolutif", celui que la clé envoie a aussi une autre particularité, c'est que (selon les docs) on peut appuyer jusqu'à 999 fois dans le vide et le code suivant sera reconnu par le décodeur comme si de rien n'était. il y a donc une loi d'évolution de code assez tordue donc difficile à trouver, même si on peut en lire plusieurs d’affilé, on ne trouvera pas cette loi tout de suite... pour info, les signaux que j'ai pu relever à l'oscillo, c'est une 10aine d'impulsions, soit une 20aine de bits. comment faire un code aussi précis avec seulement 20 bits?

il me reste une solution, ce serait de remplacer la led IR de la clé par un bon vieux NPN, et remplacer le récepteur IR par le collecteur de ce NPN. là, plus de parasites, on passe en direct, et si le code ne veut pas passer, alors oui, renault a tout fait pour qu'on jette la voiture au bout de 15 ans (son âge)...

ou sinon une autre suggestion si je comprends bien en plus de ton ecu tu a un boitier "antie démarrage"

se qui nous donne

nieman > boitier antie démarrage > ECU

plutôt que d'essayer d'injecter un code (roling code) au boitier antie démarrage pourquoi ne pas voir se qu'il se passe comme communication antre le boitier d'antie démarrage et l'ecu ?

il s'agit peut être d'un code fixe et non tournant il te suffirez donc juste de reproduire se code de déverrouillage émis par le boitier antie démarrage

la seul condition est de réussir a faire marcher ta clef pour au moins choper le code qui part du boitier antie démarrage vers ton ecu

Justement, c'est bien ça que je veux faire. A la mise du contact, au bout de 1 seconde, j'envoie le code à l'ecu. Je peux lire ce code, puisque j'ai la manip de secours (là, il faut être synchro pour enregistrer la séquence...). Et le faire plusieurs fois pour être sûr que c'est tout le temps le même, ou voir s'il change...

aaaaaaah sa semble être la meilleur approche pour toi si le code ne change pas c'est juste parfait !

Surtout que les connaissant, je vais tomber sur un série classique 62500 voire même 115200... mais faut quand même tomber sur le bon, et comme c'est la voiture à madame, ben ça va pas être facile, elle bouge tout le temps... je lui ai proposé de prendre ma R21 de 1996 qui marche bien (pas d'antidémarrage), mais elle préfère la sienne... ah les femmes...

Salut,

L'IR qui marche il est sur la clef ?
Y aurait pas moyen de contourner le problème en piquant la partie IR de la clef et en injectant le signal directement dans le bouzin sans passer par l'infrarouge ?

Sinon faudrait essayer d'automatiser la génération de code pour essayer de trouver une logique dans la génération du dit code.
Un arduino qui commuterait le bouton de la clef et un capteur IR devant pour lire le signal. Le tout avec un petit terminal série à l'autre bout pour faire un log.
Si ça ce trouve âpres 999 codes ça boucle :grin:

Si la clé est désynchronisée, IR ou pas IR, elle n'enverra jamais le bon code au bon moment. C'est le principe des codes tournants. Je pose des automatismes de portail avec des télécommandes à code tournant, 256 possibilités sur ces machins, donc une chance sur 256 de tomber sur le même code que le portail du voisin. Ici c'est pareil. C'est pas chiffré, et la séquence est assez simple. En général, le code est composé d'une tranche, et de l'adresse de la prochaine tranche (c'est ce qu'il y a sur mes automatismes).
Le plus simple serait donc de shunter tout ça et d'alimenter tes injecteurs en direct, quite à trouver d'occasion l'Ecu de la même sans l'option télécommande et anti-démarrage codé (Il me semble qu'il n'y a pas si longtemps, c'était une option !)

Je n'ai pas regardé la forme du signal sur la LED émettrice de la clé, mais en sortie du récepteur IR, on est sur un collecteur ouvert, la pul-up est fournie par le boîtier-décodeur (+5 ou +12, ça n'a pas d'importance dans notre cas), on peut donc sans souci remplacer le récepteur IR par un simple transistor NPN. Pour ce qui est du signal en sortie du récepteur (et donc en entrée du décodeur), il est à 1 en IDLE, et propose un train d'impulsions à 0 toutes de la même durée. Reste donc à voir si sur la LED j'ai exactement le même signal. donc si c'est seulement un problème de réception (cellules fatiguées par exemple), à partir du schéma d'origine :

clé(LED) => (cellule IR)récepteur(collecteur ouvert) -> (pullup)décodeur -> calculateur d'injection

on peut imaginer le schéma suivant :

clé(collecteur ouvert) -> (pullup)décodeur -> calculateur d'injection
ou
clé(NPN) -> récepteur(collecteur ouvert) -> (pullup)décodeur -> calculateur d'injection (si le signal de la clé n'est pas le même électriquement)

ou encore :

arduino -> calculateur d'injection

légende :
=> liaison IR
-> liaison filaire
(xx)yy(zz) module yy avec format d'entrée xx et de sortie zz

la première solution me plait beaucoup mieux, car avec un simple émetteur RF à deux boutons, je peux déclencher la clé (pour l'ouverture) et le bouton FC (pour la fermeture). Et il y aura un bouton poussoir pour la manip manuelle, car chez nous, les clés restent sur le contact la nuit (voiture donc ouverte), donc pour démarrer le matin, il faut un système de déverrouillage simple. Bref, dans ce cas, pas besoin d'arduino.

Pour la seconde, il faudrait pirater le code généré par le décodeur et réussir à le générer...

Ce qui m'impressionne, c'est que dans le code tournant, ils ont prévu le cas où un (des) codes s'évaporeraient dans la nature...

depuis que j'ai découvert arduino et que les premiers calculateurs d'injection étaient à base de 68HC11 à 8Mz, j'y pense, à faire mon propre calculateur (cartographies reprogrammables à souhait via USB...). Mais ça, c'est pas pour tout de suite. Mais j'ai déjà tout ce qu'il faut pour relever les cartographies injection et allumage des calculateurs, il suffit de simuler les signaux des capteurs du moteur, et il n'y en a pas tant que ça de vraiment utiles au calcul.

Alors grande première, mon premier µP embarqué en stand alone!

J'ai utilisé un 328P qui est alimenté quand on met le contact. de là, il récupère l'état de la LED antidémarrage, puis si elle clignote rapidement (< 2Hz), il fait le code de 4 chiffres en "appuyant" via un relai sur le bouton de fermeture centralisée et en comptant les impulsions de la LED (le nombre de clignotement indique à combien on est rendu quand on fait un chiffre). Si tout s'est bien passé, le système est alors dévérouillé et on peut démarrer.

Jusque là, fallait le faire à la main, et c'était bien chi**t. maintenant, on met le contact, et pendant les 30 secondes de la manip, on peut attacher la petite à l'arrière, ranger les courses dans le coffre...

C'est toujours ça de gagné, mais le problème n'est pas pour autant réglé. Place aux photos :

le circuit (50 x 65mm, c'est raisonnable) :

Une fois la planche de bord remontée, les deux leds qui dépassent (pas bien prévu le coup, j'ai du découper un peu le plastique pour les voir...)

On notera le connecteur vert qui permet de relier le circuit au FTDI arduino pour le reprogrammer si besoin...
Côté code, rien de bien méchant :

/*********************************************************
                  DEVEROUILLEUR
                  
                  MEGANE I essence
**********************************************************
branchement : 
- Détection led TDB : ICP1 (PB0)
- Led rouge : OC2A (PB3)
- Led verte : OC2B (PD3)
- Relais CPE : (PB2)
*/

#define T1_stop TCCR1B=0x40  // arrête le timer

#define LED_v_on  PORTD|=0x08
#define LED_v_off PORTD&=0xF7
#define LED_r_on  PORTB|=0x08
#define LED_r_off PORTB&=0xF7

const volatile byte code[4] = {1, 2, 3, 4};  // code de déverrouillage (spécifique à chaque voiture)
volatile byte T1_count;  // compteur d'impulsions
volatile word T1_max, T1_min;  // plage de mesure
byte dumy;

void T1_start(word capture_min, word capture_max){  // démarre le timer1 à 15625Hz et les interruptions IPC1 et TOVF1
  T1_stop;  // arrêter le timer
  TCNT1 = 0;  // reset timer
  T1_count = 0;
  T1_min = capture_min;   // définition de la plage de capture
  T1_max = capture_max;
  TIMSK1 = 0x21;  // autoriser les int TOVF et ICP
  TCCR1B = 0x45;  // démarrer le timer
}

void mkcode(){  // fait le code
  byte i;
 
  for (i=0; i<4; i++){  // 4 chiffres
    PORTB |= 0x04;  // alimenter le relai
    LED_v_on;
    T1_start(18000, 30000);  // prend en compte les impulsions entre 1,152 et 1,92 secondes, normalement, l'impulsion fait 1,5s.
    while (T1_count < code[i]){
      dumy++;
    }
    T1_stop;
    LED_v_off;
    if (T1_count != code[i]) {  // erreur dans la procédure
      i = 250;  // arrêter la procédure
    }
    delay (400);
    PORTB &= 0xFB; // couper le relais
    delay (400);
  }
  if (i == 4) {    // procédure OK
    LED_v_on;
    LED_r_off;
    delay (10000);
    LED_v_off;
  } else {        // procédure foirée
    while(1){       // clignottement des deux leds
      LED_v_on;
      LED_r_on;
      delay(500);
      LED_v_off;
      LED_r_off;
      delay(500);
    }
  }
}

void setup() {
  // configuration des entrées / sorties
  DDRB = 0x0C;
  DDRD = 0x0A;
  LED_v_on;
  LED_r_on;

  // config timer 1 / ICP
  TIMSK1 = 0;
  TCCR1A = 0;
  TCCR1B = 0;
  //TCCR1B = 0x05;   // démarre compteur @15625Hz
  TCCR1C = 0;
  
  // vérification du vérouillage
  T1_start(2500, 9375);      // prend en compte les impulsions entre 160 et 600 ms, normalement, l'impulsion fait 300ms.
  while (T1_count < 10){  // on en copmte 10 pour être sûr
    dumy++;
  }     // attendre 10 clignottements
  T1_stop;
  LED_v_off;
  if (T1_count != 10){   // erreur ou déjà dévérouillé. dans ce cas, les deux leds sont restées allumées 4,2 secondes
    LED_r_off;
    LED_v_on;
    delay(2500);
    LED_v_off;
  } else {  // vérouillage OK
    mkcode();  // on fait le code
  }
}

void loop() {    // ben oui, on n'a plus rien à faire une fois le code rentré...
}

ISR(TIMER1_OVF_vect){  // débordement timer (au bout de 4,192 secondes sans impulsion sur ICP1)
  T1_stop;  // arrêter le timer
  T1_count = 250;  // indiquer le débordement
}

ISR(TIMER1_CAPT_vect){  // capture event
  TCNT1 = 0;   // reset timer
  if ((ICR1 < T1_max) && (ICR1 > T1_min)) { // vérification "dans les clous"
    T1_count++;
 // } else {      // on a reçu une impulsion en dehors de la plage valide
 //   T1_count = 0;  // sinon, reset compteur
  }
}

J'ai remarqué qu'un while(qqchose); n'était pas compilé, du coup, mes boucles d'attentes ne marchaient pas... c'est pourquoi j'incrémente dumy, histoire de compiler quelque chose... peut-être qu'une paire d'accolades auraient suffit...

Sinon, le code a marché du premier coup, j'ai eu un début d'érection!

Super_Cinci:
J'ai remarqué qu'un while(qqchose); n'était pas compilé, du coup, mes boucles d'attentes ne marchaient pas... c'est pourquoi j'incrémente dumy, histoire de compiler quelque chose... peut-être qu'une paire d'accolades auraient suffit...

Comment as tu prouvé que les boucles n'était pas compilées ? En passant l'assembleur à la mano ?
Ça me semble bizarre comme histoire ces boucles qui boucle pas.

simplement parce que :

  T1_start(2500, 9375);      // prend en compte les impulsions entre 160 et 600 ms, normalement, l'impulsion fait 300ms.
  while (T1_count < 10);     // attendre 10 clignotements

n'attendait rien du tout. ou dans T1_start(), T1_count est mis à 0 et n'est modifié que dans les interruptions ICP1 ou TOVF, Comme T1 est configuré pour tourner au plus lent, un TOVF met 4,192 secondes pour arriver. ma séquence ne durait qu'une petite seconde (car il y a des delays). Quand j'ai rajouté mon dumy++, j'ai tout de suite retrouvé mes 4 secondes!

il faudrait que j'essaie while (T1_count < 10){} pour voir.

Bizarre, surement l'optimisation de code qui dégage la boucle.
Si tu ajoutes un volatile asm("nop"); dans le boucle ça fait quoi ?

Alors j'ai testé 4 cas différents, sans rien sur ICP1, donc le timer tourne jusqu'au TOVF, la boucle while doit normalement durer 4 secondes environ. :

  T1_start(2500, 9375);      // prend en compte les impulsions entre 160 et 600 ms, normalement, l'impulsion fait 300ms.
  while (T1_count < 10){}     // attendre 10 clignottements
  T1_stop;

Taille code : 702, fonctionnement : OK.

  T1_start(2500, 9375);      // prend en compte les impulsions entre 160 et 600 ms, normalement, l'impulsion fait 300ms.
  while (T1_count < 10){
    asm("nop");
  };     // attendre 10 clignottements
  T1_stop;

Taille code : 706, fonctionnement : OK. un NOP = 2 octets. alors pourquoi 4 de plus... mystère!

  T1_start(2500, 9375);      // prend en compte les impulsions entre 160 et 600 ms, normalement, l'impulsion fait 300ms.
//  while (T1_count < 10);     // attendre 10 clignottements
  T1_stop;

Taille code : 688, fonctionnement : pas OK.

  T1_start(2500, 9375);      // prend en compte les impulsions entre 160 et 600 ms, normalement, l'impulsion fait 300ms.
  while (T1_count < 10);     // attendre 10 clignottements
  T1_stop;

Taille code : 702, fonctionnement : OK. et là, c'est passé... étonnant, non?

Bon, de toutes façon, ça marche dans la voiture, c'est le principal. et vu le peu que je demande au 328, je n'ai vraiment pas besoin d'optimisation, des digitalWrite() auraient même pu trouver leurs places, mais bon, j'ai un minimum d'amour propre à préserver... XD

Bizarre bizarre, mais si ça marche au final tant mieux :grin: