Forum
Y este es el emulador.
![]()
Oscar, todo eso está muy bien, pero a Xabi le pasa como a mi, no le interesa el resultado, nos interesa el saber como y fabricarlo, como buen radioaficionado que es también, la experimentación es lo importante aunque te dejes una pasta en componentes y un cerro de horas, como me ha pasado a mi con las ecus, pero lo que nos llena es saber realmente como funcionan las cosas.
No se quien me contó que unos hicieron una apuesta de que sería capaz de hacer andar un motor de gasolina inyección electrónica sin ECU fabricando una ecu con piezas de una radio vieja, y lo consiguió. Es como quedarte sin gasoil en el desierto y hacerlo andar con la grasa de un cerdo como creo recordar que alguien hizo en una ocasión con un series.
P.D.: No se si a la gente no le interesa, está acojonada, le da miedo o no entiende lo que estoy haciendo ;D ;D ;D Sea como fuere, creo que de este post van a salir cosas interesantísimas.
😮 😮 😮 yo me he quedado callado porque vas mil pasos por delante de mi, asi que, eso si lo mio seria tirar mas por lo mecanico o material y no por lo electronico (que no tengo ni pajolera idea) , pero sigo leyendo con interes. Lo que si queda claro es que no hay casi imposibles, y si tubieras un td4 ... tambien caeria. ;D
El delay, es de 4ms, aparecía en el código del Link 1, pero lo confirmé midiendo la señal. El protocolo trabaja a 250 baudios, por tanto 1s/250 = 4ms. Debería de haber calculado, cuanto tarda el DigitalWrite y la comparación de 1y 0 y el del while, pero los he ignorado. No los he ignorado, he decidio, que no merece la pena ternerlos en cuenta:
Precisamente te lo comentaba ya que con esa forma de controlar los tiempos cada vez que metas una línea más de código te variarán los tiempos y aquello empezará a no funcionar. Yo lo hice no recuerdo para que y era un lío de la leche. Con el X24 que yo utilizaba no me quedaba más remedio que dedicar todo el procesador y dejar parado el resto de código hasta terminar de mandar todo.
Si saco ganas me voy pedri un arduino de los nuevos para ir aprendiendo a programarlo, se puede hacer cualquier cosa con él. El X24, que se programa en xbasic, lo tengo precisamente en el defender td5 controlando la presión de turbo para que no corte por exceso de presión interceptando la señal del sensor y mandando una nueva señal mas baja, todo en analógico, de 0 a 5 voltios.
Oscar, gracias por las fotos 😉 😉 😉 😉 😉 😉 😉
Que no es un pic, es una eprom.
No vas a poder convertir la ECU a robust tan solo programando las flash principal, por seguridad el tema del inmovilizador no lo controla el firmware de la ecu, el pic de inyección es el que decide en función de lo que hay en la eprom de 4k y lo que manda la alarma. Eso mismo me pasó a mi hace años, leí la eprom completa de una ecu a la que se le había eliminado el inmovilizador creyendo que encontraría la clave del asunto y me lleve un chasco cuando comprobé que allí no había nada cambiado con respecto a una ecu de serie. De todos modos inténtalo que lo mismo estoy yo equivocado.
Vas a terminar por ñapear la eprom, ya lo verás.
Esto si que tiene sentido, y ahora he caído en ello. Las MSB venían con el firmware tostado de fábrica, y aún así se le pueden cambiar parámetros, entre ellos los inyectores (no estoy seguro de esto, pero lo supongo, si no vaya mierda de diseño). Según el manual del nanocom las ECU tienen 3 modos, de fábrica, robusto y no robusto. De fábrica permiten arrancar el coche una vez, y despues no arrancan mas hasta ponerlo como robusto o no robusto. Por tanto este valor se guarda en la EEPROM serial esa.
La EEPROM se tiene que poder escribir desde el motorola, si no, no entiendo como se puede leer MEMS desde el ODB. Auqnue esto es una suposición, y es que el ODB lo controle el Motorola. Hasta tener el circuito delante de mi no lo sabré. Si el EEPROM es accesible desde el Motorola, la EEPROM se puede reflashear entera utilizando BDM.
Ya verás cuando empieces a explorar el contenido de la flash, a mi me falta mucha info y herramientas, no he querido gastar dinero en comprar información, me niego y todo lo he ido deduciendo o me lo han filtrado, sobre todo Oscar que es el que más conoce de esto.
Lo ideal sería dar con las fuentes de la ecu, allí tendríamos todo para cambiar, pero no hay forma de que salgan de la fábrica. Tal vez cuando pasen años se empiecen a filtrar para poder ñapear sin ingeniería inversa.
A ver si este finde me fabrico el lector BDM, y leo la flash entera y empiezo a desensablar de mientras 😉 Trabajo de chinos.
No voy a empezar con una NNN, sencillamente, porque actualmente no tengo pelas para gastarme en esto. En cambio las MSB en ebay.uk están tiradas de precio. Dentro de un mes ya se verá, pero de mientras, con lo que hay.
Oscar, todo eso está muy bien, pero a Xabi le pasa como a mi, no le interesa el resultado, nos interesa el saber como y fabricarlo, como buen radioaficionado que es también, la experimentación es lo importante aunque te dejes una pasta en componentes y un cerro de horas, como me ha pasado a mi con las ecus, pero lo que nos llena es saber realmente como funcionan las cosas.
Tu lo has dicho, si el objetivo fuese quitar el inmobilizador, compraría una NNN con la ñapa hecha y me olvidaría 😀 Tan importante como la meta, es el camino recorrido para llegar a ella. Y lo que se aprende, y lo que aporta.
Precisamente te lo comentaba ya que con esa forma de controlar los tiempos cada vez que metas una línea más de código te variarán los tiempos y aquello empezará a no funcionar. Yo lo hice no recuerdo para que y era un lío de la leche. Con el X24 que yo utilizaba no me quedaba más remedio que dedicar todo el procesador y dejar parado el resto de código hasta terminar de mandar todo.
Lo suyo es hacer una interrupción por software con un Timer que tiene el Atmega para este fin. Y te aseguras de que los 4ms sean clavados.
Buenas noches a todos!!!!!
Otro dato importante, el VIN del coche está grabado en la ECU en las Flash principal, entre medias de la variante y del fuel. Este VIN es importante a la hora de hacer ciertas cosas, sobre todo con nanocom y otros aparatos de flashear ecus. Yo directamente borré el VIN pero solo se puede hacer con BDM o escribiendo la flash con un grabador.
Yo tengo por aquí un grabador BDM pero no lo he usado nunca. No se como funciona BDM, a ver si me lo cuentas, entiendo que usa el procesador para grabar la eeprom, no?. Pero la rutina de grabado donde esta?, en el procesador?
Te explico, cuando activas el modo BDM del procesador, este se pone en Halt y arranca un programa que esta incrustado en el microcódigo de la CPU que te permite leer y escribir mediante un protocolo de serie.
Permite:
Leer y escribir los registros de estado de la CPU
Leer y escribir los registros de datos de la CPU
Leer y escribir en el bus de Datos de la CPU
Salir del modo BDM
Es decir, te permite, que con tu consola serie, te conviertas en la CPU, sirve para hacer debug, ya que es posible poner una instrucción en el código que hace que micro salte al modo BDM, despues lees los registros de la CPU o la RAM (o los escribes), y vuelves a proseguir la ejecución.
Para grabar la EEPROM, hay que darle vueltas a ver como funciona, concretamente al reloj de la EEPROM. Si es lo suficientemente lento o lo genera la CPU, se podría escribir con el BDM, a tiempo real.
Si no lo es, hay que escribir una rutina, grabarla en cualquier sitio de la Flash, cambiar el Intruction_Pointer a esa dirección y salir del BDM. La CPU escribirá la EEPROM solita. Después habrá que escribir la Flash entera ya que la habremos corrompido.
Te explico, cuando activas el modo BDM del procesador, este se pone en Halt y arranca un programa que esta incrustado en el microcódigo de la CPU que te permite leer y escribir mediante un protocolo de serie.
Permite:
Leer y escribir los registros de estado de la CPU
Leer y escribir los registros de datos de la CPU
Leer y escribir en el bus de Datos de la CPU
Salir del modo BDMEs decir, te permite, que con tu consola serie, te conviertas en la CPU, sirve para hacer debug, ya que es posible poner una instrucción en el código que hace que micro salte al modo BDM, despues lees los registros de la CPU o la RAM (o los escribes), y vuelves a proseguir la ejecución.
Para grabar la EEPROM, hay que darle vueltas a ver como funciona, concretamente al reloj de la EEPROM. Si es lo suficientemente lento o lo genera la CPU, se podría escribir con el BDM, a tiempo real.
Si no lo es, hay que escribir una rutina, grabarla en cualquier sitio de la Flash, cambiar el Intruction_Pointer a esa dirección y salir del BDM. La CPU escribirá la EEPROM solita. Después habrá que escribir la Flash entera ya que la habremos corrompido.
El problema es que la EEprom para escribir necesitas activar de momento el write enable que en la MSB no existirá. También habría que ver tema de tensiones que algunas eeprom necesitan más tensión para ser grabadas ,creo que no es el caso de la 29f200, etc etc etc. Un lío del copón que no se si serias capaz de hacerlo.
Al final lo de hacer la rutina de grabación es precisamente lo que tienen la NNN en la flash, pero no se escribe la flash entera, se mantiene intacta siempre la parte del loader que está al principio de la memoria. El grabado de la flash por OBD se hace en dos bloques, primero graba la variante que son 101kb y luego el fuel que son 17k. Entre medias hace una pequeña comprobación y continua grabando. Pero como no tenemos un buffer donde almacenar y comprobar, si haces algo mal al arrancar la ECU se queda el procesador frito y no hay forma de recuperar la ecu hasta volver a grabar toda las flash de nuevo desoldando o por BDM. Esto le ha pasado a mucha gente, a mi el primero. Yo creo que la ecu debería tener un watch dog de hardaware que en caso de quedar colgado el procesador activara el modo grabado de flash por OBD y nos permitiera volver a grabar la flash de nuevo.
Gus el Write enable tiene que existir. Puede que en las pistas de la memoria no, pero en el procesador, necesariamente tiene que existir. Sería hacer un puente.
Cuando lea la flash, ya empezaré a ver cosas mejor.
Bueno, al hilo. El invento va avanzando, fase 1 del proyecto completada, he terminado el emulador de alarma. De momento solamente se puede programar con el ordenador, pero mañana escribiré el código para que aprenda el código automáticamente, pinchando el hilo B37. El circuito lo subiré pronto.
Foto del chisme:

Funciones que va a tener:
- Guardar un código imborrable, solamente programable por ordenador.
- Guardar otros 5 códigos.
- Aprender códigos pinchando el cable.
- Mandar a la ECU cualquiera de los 5 códigos disponibles.
Si hubiese interés de la gente, podría diseñar una PCB y hacer una tirada de 50, saldría a menos de 2€ por PCB.
Un saludo.
Bueno, aquí tenéis un vídeo donde arranco el Td5, con la alarma activada.
Lo tiro cuesta abajo ya que no me apetecía puentear el motor de arranque.
Feliz fin de semana!!!!!
Acojonado estoy cada vez con el señor Garmendia........ :tongue9:
Lo de ayudarte caso necesites, son palabras que las retiro pues vamos............ni el alfabeto lingüístico utilizado entiendo......jejeejejej
Aupa ahí Garmen!
Yo veo un pequeño fallo (por experiencia propia), vuelve a probar a arrancarlo, pero esta vez no dejes el mando en el salpicadero, sino que se lo das a alguien para que se lo lleve lejos del coche, bastante lejos. A ver que pasa... el dia que yo puentee mi 300 (alarma + inmovilizador) cometi el error de arrancarlo teniendo la llave cerca del coche, me di una vuelta y llene el deposito en una gasolinera.... alli se tubo que quedar el coche , hasta que mi hermano me trajo el mando. El receptor del mando es traicionero ::)
Paulo, se agradece la intención 😀 😀
Iban, he probado el invento de mil maneras y funciona. La señal de que la alarma está inmobilizada el el testigo rojo que parpadea en el vídeo. Incluso lo he probado sin llave, haciendo el puente al coche. Metiéndole 12 Voltios directo a la centralita y empujando, luego tuve que ir a por la llave para quitar el bloqueo de dirección. ;D ;D
Para el que quiera hacerse el invento aquí tiene esquema, los gerbers para el fotolito y el archivo de Eagle:
Esquema:

JP_1 es la alimentación a 12 Voltios, pin 2 +, pin 1 -
JP_2_1es la salida hacia la ECU
JP_2_2 es la entrada desde el modulo de alarma, para aprenderse el código.
JP_3 y JP_4 son botones
El transistor es un P2N2222
PCB, desde el lado de componentes:

PCB, lado pistas, fotolito para hacer transferencia:

ZIP del archivo de Eagle:
Feliz semana!!!!
