Diagnóstico de una válvula EGR de PSA / STELLANTIS averiada.

Pues resulta que también me voy a atrever con la mecánica… Y es que me ha tocado la moral que haya fallado con 80.000Km y que cueste 780€ (más mano de obra y otro montón de conceptos) .

Y es que mi DS5 edición aniversario de 180Cv es un coche genial: bonito, cómodo, buenos acabados, potente, con un consumo ajustado, pegatina C (cumple EURO 6)… pero ha pasado 4 veces por el taller para averías antes de los 90000Km y eso es inadmisible en un coche «premium».

Tres problemas con el depósito de urea: primero con 40.000Km, cubierto por la garantía. Segundo con 60.000 que me costó unos 600€ y el tercero con 73.000Km, este último sin cargo. Y ahora la válvula EGR con 80.000, que como el depósito de urea forma parte del sistema anticontaminación. A este coche se le cambia el aceite cada 30.000Km… no he podido hacer un cambio sin antes pasar por taller con una avería!!!

Este vehículo viene equipado con un depósito de urea para la reducción de los óxidos de nitrógeno NOx, que es un conjunto indivisible de depósito, bomba y electrónica de control. Según me comentan en el taller, no existe despiece ni es reparable «para evitar la manipulación del sistema anticontaminación». Cuesta unos 660€ más la mano de obra del cambio.

Vamos con la válvula EGR… su misión es también reducir las emisiones de óxidos de nitrógeno (dañinos para la salud y el medio ambiente), pero de una forma distinta y muy interesante. Lo que hace es mezclar parte de los gases de combustión del escape con el aire de la admisión para introducirlo de nuevo en los cilindros. ¿Absurdo? No tanto. Los óxidos de nitrógeno se producen en el interior de los cilindros debido a las altas presiones y altas temperaturas producto de una combustión muy eficiente (menos consumo y más potencia), combinado con la gran cantidad de oxígeno y de nitrógeno que hay en los gases de admisión. Los antiguos motores con bombas mecánicas, menos eficientes no generan estos gases.

Los motores diésel siempre deben aspirar la máxima cantidad de gases posible para poder comprimirlos y que aumente la temperatura y se produzca la combustión. Por lo tanto limitar la cantidad de aire que aspiran, para reducir la cantidad de oxígeno y nitrógeno y en consecuencia los óxidos nitrosos, no es una opción, el motor no funcionaria. Aquí es donde entra en funcionamiento la válvula EGR (Exhaust Gas Recirculation). Para disminuir la cantidad de oxígeno disponible lo que hace esta válvula es recircular los gases ya quemados, que a penas contienen oxígeno y sí mucho CO2, a la admisión. El volumen de gases admitidos es el óptimo, pero la concentración de oxígeno es la adecuada para la combustión del gasóil, no más. De esto se encarga la ECU (Electronic Control Unit,) del motor). No hay suficiente oxígeno como para producir óxidos de nitrógeno. Esto sólo sirve con el motor a bajo régimen, cuando la demanda de potencia es alta la necesidad de oxígeno también y no se puede sustituir parte del aire por gases quemados.

Mi coche viene equipado con una válvula EGR (Exhaust Gas Recirculation), modelo 9807593080 que se usa en muchos modelos de DS, citroen, ford y peugeot. Además también es producida por muchos fabricantes distintos (manías de la industria del automóvil: de tener muchos proveedores distintos para cada elemento).

Es un armatoste considerable, pero yo veo al menos 5 elementos completamente independientes y desmontables… ¿Por qué venden todo el conjunto y no los elementos por separado? Además del cuerpo de la válvula, arriba se ve un actuador por depresión, un sensor hall para detectar la posición del actuador, a la derecha un intercambiador de calor aceite / gases y abajo un motor de CC con sensor de posición.

Efectivamente, la válvula tiene elementos extra, además del mecanismo para permitir / impedir la recirculación de gases. El intercambiador de la derecha tiene la misión de enfriar los gases de escape antes de introducirlos en la admisión, algo lógico si pensamos que los gases de admisión interesa que estén lo más fríos posible y los gases de combustión están a más de 600 grados. Esto lo hace intercambiando el calor con el aceite del motor… sí, esta válvula tiene una conexión de entrada y otra de salida del aceite de motor. Como función extra, mediante este intercambiador, es posible calentar el aceite del motor cuando el motor está frío en pocos minutos, a costa del calor residual de los gases de escape. El actuador por depresión comanda una clapeta que abre o cierra el paso de los gases de combustión por el enfriador. Por defecto, un muelle en acatuador mantiene el paso de gases por el intercambiador abierto, se cierra por succión (depresión) de la admisión quizás mediante alguna válvula electroneumática (no he profundizado en este aspecto).

Una vez quitado el intercambiador se ve su entrada de gases a a derecha y salida de gases a la izquierda. Abano una apertura ovalada para el paso del aceite. Paso de gases por el intercambiador abierto:

Paso por el intercambiador cerrado:

Esta es la válvula que regula la recirculación de gases, similar en construcción a una válvula de admisión de los cilindros, pero comandada eléctricamente.

Este es el motor que la acciona, mediante un reductor de una etapa, una leva y un empujador. La placa electrónica contiene un sensor HALL que detecta la posición del piñón secundario, indicando la posición de la válvula a la ECU.

Esta era la posición de la leva que comanda la válvula cuando desmonté el conjunto, hacía tope en la posición casi cerrada, pero no llegaba nunca a cerrar por completo. La ECU detectaba este estado e informaba «Válvula EGR en posición distinta a la comandada».

La válvula cierra por acción de un muelle, de forma que al cortar la alimentación del motor se garantiza el cierre… desconozco si el motor tiene control bidireccional. Si sólo acciona en un sentido para abrir y el cierre se produce por la acción del muelle.. entonces es un diseño muy deficiente. La suciedad que impide el cierre esta alojada en la guía del vástago de la válvula (sometido a los gases de combustión calientes y carbonilla) pero no estaba tan agarrotada como para que un motor con algo más de par (quizás un paso más de reducción) no pudiera moverla.

Después de forzarla un poco con la mano cierra al completo:

Esta es la guía del vástago de la válvula y el propio vástago. No parece un mal diseño, la guía es solidaria al cuerpo de aluminio y todo esta refrigerado mediante al aceite del motor. En mi opinión tiene muy poca suciedad para que haya fallado.

Así ha quedado después de limpiarlo todo, no había mucha suciedad, pero ahora ya se mueve sin ninguna resistencia y el muelle la cierra por completo.

Así se ve ahora la válvula y la lumbrera por donde entran los gases calientes:

En general ha quedado bastante limpia…

Este es el intercambiador de calor entre los gases de combustión y el aceite. El aceite circula por el cuerpo de la válvula y la refrigera, y también por la carcasa de plástico donde está este elemento bañado en flujo de aceite del motor. Los gases de combustión entran por los dos tubos horizontales superiores y sale por los dos inferiores, El texturizado de los tubos es para aumentar la superficie de contacto con el aceite:

Por esta parte entran y salen los gases de combustión. La clapeta de la foto anterior hace de bypass: en una posición lleva la circulación de los gases por el intercambiador de calor y en otra los dirige directamente a la válvula EGR:.

Mi diagnóstico: el accionamiento de la válvula es demasiado flojo, con muy poca suciedad se ha bloqueado y sólo con la mano he podido desbloquearlo. ¿Podría un motor con más par solucionar este fallo? ¿O la suciedad se acumularía más y más con los sucesivos accionamientos y solo se retrasaría el fallo unas semanas?

Viene de aqui: http://heli.xbot.es/?p=33

Han pasado otros diez años (alguno más), y nos hemos metido en 2020. El PLC casero no esta muerto, una tarjeta con un micro H8-500 y la versión 3.8 en su EPROM 27C256 continúa trabajando. Todavía controla, con sus 32 entradas y sus 32 salidas digitales, sus dos puertos serie y sus 32K de RAM con RTC y batería de backup, un filtro prensa destinado a desecar lodos.

Aprovechando el parón por el coronavirus me he puesto a revisar el software de programación ECP. La intención era portarlo a Windows. ECP solo corre en MSDOS debido a que hace acceso directo al hardware. Esto era una necesidad en su momento, ni la BIOS ni MSDOS proporcionaban una API adecuada para manejar el hardware. Por ejemplo, la velocidad más alta que podía programarse en los puertos serie era 19200 bauds, aunque los chip UART 8250 podían trabajar hasta 115200 bauds. Solo escribiendo directamente en los registros adecuados de la UART podían conseguirse todas las velocidades diponibles.

Con la llegada de sistemas operativos más avanzados (XP y posteriores) ya no es posible interactuar directamente con el hardware de la máquina. De eso se encarga el propio sistema operativo mediante los drivers, pero proporciona una API para que los programas de usuario puedan acceder al hardware.

El plan era el siguiente: cambios mínimos en el programa ECP para eliminar todas los accesos al hardware y hacerlo a través de la API de Windows. El programa ECP estaba escrito en ANSI C (Borland Turbo C 2.0, todavía se puede mediante DOSBOX bajo Windows XP). Para la nueva versión usaría GCC 9.30 bajo Msys2 y MinGW en Windows 7 x64 ( y en otros momentos máquinas bajo Windows 10 x64). No uso interfaz gráfico, mantengo el interfaz en texto pero usando la librería ncurses.

El resultado es una vesión (alfa todavía) que corre en desde Windows Vista hasta Windows 10 (incluidos Windows 7 y 8.x) de 32 o 64 bits, y también en Windows XP de 32 bits: http://heli.xbot.es/wp-content/uploads/2020/05/EcDuino4.51.zip.

Del mismo modo he tomado los fuentes en C del firmware del PLC V3.8 y lo he portado a Arduino (uso en entorno arduino 1.8.12, aunque compilará con otros anteriores). Junto con algunas librerías he conseguido que entre en la limitada RAM (2K) del Arduino UNO (Atmega328). Teniendo en cuenta que las versiones antiguas trabajaban en micros con 32K de ram es todo un lograo. Para conseguirlo he tenido que rehacer el mapa de memoria del PLC, menos E/S, menos reles internos etc. El resultado es un PLC con las siguientes características:

256 pasos de programa, 32 temporicadores/contadores, 32 entradas y 32 salidas. Dos entradas analógicas 0 a 5V de 10 bit y una salida analógica de 10 bit de 0 a 5V. 64 + 64 relés internos y reloj (si se usa el módulo RTC DS3231).

Como extra he mantenido el HMI (human-machine interface), con teclado de 6 teclas por I2C mediante PCF8754 y pantalla LCD d e16 caracteres por 2 líneas por I2C. Esto nos permite interactuar con el PLC.

Este es el montaje de prueba:

Este es el software para el Arduino UNO. Yo he usado el entorno 1.8.12, pero funcionará con otros más antiguos. Son necesarias 3 librerías que se encuentran en el directorio «libraries» dentro del ZIP: http://heli.xbot.es/wp-content/uploads/2020/04/EcDuinoUno0.2

El reloj no es imprescindible para el funcionamiento del programa, eliminarse de forma opcional. También es posible eliminar el conjunto del display y teclado dejando sin conectar los dos hilos del I2C amarillo y gris que val a los pines A4 y A5 del arduino. En caso de eliminar todo es recomendable conectar en esos pines un par de resistencias de 10K a positivo, o mejor eliminar la línea 65 de header.h «#define _DISPLAY_» para que no se compile la parte del display.

Algunos programas para el PLC para hacer pruebas: http://heli.xbot.es/wp-content/uploads/2020/04/ProgramasTest.zip

Estoy portando un programa que tengo funcinando en varios Arduino UNO a un ESP8266 y me encuentro que no funciona, provoca una excepción 28 y un volcado de pila en cuanto introduzco datos…

Excepciones del ESP8266: https://arduino-esp8266.readthedocs.io/en/latest/exception_causes.html

Después de mucho revisar compruebo que el programa para Arduino no lo tengo demasiado bien escrito, pero no causa problemas. Eso es debido a que no tiene MMU (unidad de manejo de memoria). El ATMEGA328P es un micro muy sencillo y tiene toda la memoria expuesta. Si tengo un «puntero loco» siempre puedo leer el o escribir en la dirección de memoria a donde apunta.

Sin embargo, el ESP8266, tiene un micro Tensilica Xtensa, bastante más complejo, con MMU https://en.wikipedia.org/wiki/Memory_management_unit y excepciones. Si un puntero apunta a la zona de memoria incorrecta es muy facil que se genere una excepción al intentar leer o escribir datos.

El código mal programado es este:

char *SavePtr;

char * MySerialbuffer; 

char *Token = strtok_r(MySerialBuffer, " ", &SavePtr);  
if (strcmp(Token, "Read") == 0) // Primera palabra clave 
{
  Token = strtok_r(NULL, " ", &SavePtr);
  while (*SavePtr == ' ') SavePtr++;  // Elimina espacios extra
  if (strcmp(Token, "Data") == 0)  // Segunda palabra clave  
  {  
     int Src = atoi(strtok_r(NULL, Space, &SavePtr)); // Primer parametro
     int Len = atoi(strtok_r(NULL, Space, &SavePtr)); // Segundo paametro
     // etc...   
   }
}

En MySerialBuffer estan los comandos que recibo por el puero serie. El trozo de código anterior detecta si he escrito «Read Data 12 23» donde 12 y 23 serían dos parámetros numéricos… Pero ese código es un despropósito.

La función «Token = strtok_r(caden ade entrada, delimitadores, saveptr)» https://linux.die.net/man/3/strtok_r devolverá un puntero nulo (NULL) cuando no encuentre una cadena que terminada por los delimitadores. En un micro sin MMU eso no tiene trascendencia, excepto porque cuando leamos datos de *Token estaremos leyendo de la zona de memoria 0 que puede contener cualquier cosa. En mi caso como son comparaciones con palabras clave es casi imposible que en esa zona de memoria haya algo parecido a lo que busco, la comparación falla y ya esta.

Pero en el ESP8266, con el micro Xtensa y su MMU, leer datos de un puntero nulo genera una excepción y el programa termina en una detención halt.

La forma correcta de programar es ir comprobando que el puntero devuelto por strtok_r no es nulo:

char *Token = strtok_r(MySerialBuffer, " ", &SavePtr);  
if (Token==NULL) return 0; //  No continuar 
if (strcmp(Token, "Read") == 0) // Primera palabra clave   
{
  Token = strtok_r(NULL, " ", &SavePtr);
  if (Token==NULL) return 0; //  No continuar  
    // Elimina espacios extra, con seguridad
  if  (SavePtr!=NULL) while (*SavePtr == ' ') SavePtr++;  
  if (strcmp(Token, "Data") == 0)  // Segunda palabra clave  
  {  
     Token = strtok_r(NULL, Space, &SavePtr);   
     if (Token != NULL) Src = atoi(Token);   
     else return 0;  // Falta un parametro
     Token = strtok_r(NULL, Space, &SavePtr);         
     if (Token != NULL) Len = atoi(Token);    
     else return 0;  // Falta un el otro parametro 
     // etc...   
   }
}

Es lo que pasa cuando uno se acostumbra demasiado a programar micros ulrasencillos, luego hay que volver a la realidad de las MMU, la alineaciones a página etc

Como las placas Arduino UNO, micro nano etc (todas las basadas en el ATMEGA328P) solo disponen de un puerto serie es necesario usar la librería «SoftwareSerial.h» del entorno Arduino para manejar más de un puertos serie.

Esa librería es multi instancia, pueden declararse varios objetos tipo «SoftwareSerial» pero solo se puede escuchar la recepción de UNO en cada momento (seleccioándolo mediante el procedimiento listen().

En el proyecto que estoy trabajando ahora necesito escuchar simultáneamente dos puertos, y la opción de conmutar mediante listen() no sirve porque pierde caracteres.

Para solucionarlo he creado esta bominación, una librería que he llamado «SoftwareSerial2RX.h» que permite tener DOS puertos serie de solo recepción (no necesito transmitir y he eliminado esa parte para no consumir pines) por cada instancia.

Es necesario que los dos pines de recepción se encuentren en el mismo puerto del micro, pero pueden crearse varias instancias con parejas de pines en puertos distintos y escuchar 2, 4 ó 6 puertos en un solo arduino. Este horror no permite la recepción concurrente: si esta recibiendo datos de un puerto y llegan por el otro se interrumpen las dos recepciones. No esta muy currado, pero para leer tarjetas RFID es suficiente porque el usuario pasa de nuevo la tarjeta por el lector si observa que no se ha leido correctamente. Como uso un puerto para el tarjetero de entrada y otro para el de salida no se usarán nunca los dos puertos a la vez.

Esta es la librería, con un ejemplo de utilización: SoftwareSerial2RX

Este es un ejemplo de utilización, los procedimientos estan duplicados, uno para cada puerto: available() y available1(), read() y read1() etc…

#include <SoftwareSerial2RX.h>
// Double software serial: RX0 = digital pin 2, RX1 = digital pin 3
SoftwareSerial2RX TwoPortSerial(2, 3); 

void setup() { 
// Open serial communications and wait for port to open: 
  Serial.begin(9600); 
  
  while (!Serial) {; // wait for serial port to connect. Needed for native USB port only 
  }
  Serial.println (F("SoftwareSerial2RX: Two simultaneous receive only serial ports"));
  // Start only RX serial ports 
  TwoPortSerial.begin(9600); 
} 

void loop() { 
// while there is data coming in, read it 
// and send to the hardware serial port: 
  if (TwoPortSerial.c() > 0) { 
    Serial.print (F("FromPort0: ")); 
    while (TwoPortSerial.available() > 0) { 
        char inByte = TwoPortSerial.read(); 
        Serial.write(inByte); 
      }
      Serial.println(); 
    } 

  if (TwoPortSerial.available1() > 0) { 
    Serial.print (F("FromPort1: ")); 
    while (TwoPortSerial.available1() > 0) { 
        char inByte = TwoPortSerial.read1(); 
        Serial.write(inByte); 
      } 
      Serial.println(); 
   } 
   delay (50); // Slow down! 
}

He comprado un par de lectores RFID de 125Khz modelo RDM6300 V3.1 para un proyecto de control de accesos. https://www.amazon.es/dp/B00K8R7FR6
Son muy fáciles de usar y se encuentra bastante documentación en internet:

Pero la sensibilidad de lectura es bastante baja, aunque promete leer las tarjetas desde 15mm, solo llega a 10mm. En cualquier caso 15mm es una distancia de lectura bastante baja, obliga a pegar la tarjeta contra la carcasa del lector y no permite leerlas si estan guardadas en una cartera abultada o en una mochila.

He pensado que sería posible aumentar la distancia con alguna modificación, en primer lugar he obtenido el esquema aproximado de la placa:

No he medido muchos componentes, pero no es relevante para entender el funcionamiento. La primera modificación que se me ha ocurrido es alimentar la bobina desde 5V en lugar de hacerlo desde 3,3V. Esto puede hacerse desoldando una pata de la boina de choque SMD que alimenta el emisor del transistor PNP y soldando un hilo a +5V. Aumenta un poco la sensibilidad pero no es relevante.

La solución óptima es usar una antena mejor. La antena que se suministra con el módulo es de pequeño tamaño, de hilo de 0,24mm de diámetro. Despues de probar con distintas antenas he encontrado una excelente: esta construida con hilo de 0,3mm de diámeto y consta de 60 espiras sobre un soporte de 60mm de diámetro.

El resultado es espectacular, con la antena original la señal en la antena es de 20V pp:

Con la antena de 60mm de diámetro de 60 espiras la tensión sube hasta 60V pp, quizás hasta demasiado para los transistores S8050 y S8550 (VCE de 25), pero funciona!! La distancia de detección es ahora de 60mm. Ahora puede leer tarjetas guardadas en una cartera dentro de una mochila!!

Para probar el módulo he usado un arduino UNO con el PIN 2 conectado a la salida TX del módulo. El módulo se alimenta entre GND y +5V del arduino. El programa de test es este: Rdm6300Test

Un amigo me ha dejado un TV de marca ANSONIC (marca de Hipercor) para reparar. Aunque el televisor es una marca genérica la electrónica es Vestel, que es un gran fabricante de electrónica de consumo. La misma placa, modelo 17MB55, se usa en televisores Telefunken y otras marcas conocidas.

Los síntomas son que el TV se mantiene en standby, al encenderlo no hace nada de nada. La primera sospecha es de alimentaciones, pero todas son correctas. Comprobando los relojes y reset todo es correcto, pero sique sin arrancar. Si tiene alimentación, tiene reloj y no esta reseteado el procesador debería comenzar a ejecutar el programa y arrancar el TV, pero no… Por último sospecho del propio programa ¿y si es incorrecto?.
Esta placa usa dos memorias EEprom SPI de 8 patas para almacenar el programa, es facil encontrar los puntos de test para leerlas y progrmarlas por ICSP, pero yo prefiero desmontarlas y pincharlas directamente al lector/grabador porque me es mas rápido que preparar un cable ICSP específico para esta placa.

Añadiendo unos hilillos a las memorias SO8 puedo insertar las memorias en el lector/grabador para DIL. Leo las memorias y hago un backup, importante!, que nunca se sabe…

A continuación busco en distintos foros de internet dedicados al servicio técnico de Audio y Video, pero no encuentro el firmware exacto para esta Ansonic. Hay que buscar «Dump» no «firmware» porque lo que la gente sube a la web no es el firmware tal y como lo proporciona el fabricante sino un volcado binario de lo que se lee de las propias eeprom. Por suerte encuentro un firmware para esta placa Vestel, pero para un televisor Telefunken: http://remont-aud.net/dump/lcd_pdp_tv/telefunken/telefunken_d32h125n3_shassi_main_board_vestel_17mb55/378-1-0-31790 Flasheo las memorias y las sueldo provisionalmente en su sitio:

PERFECTO. El TV vuelve a funcionar, aunque ahora los menús son los de Telefunken.

Ya solo queda desoldarlas, quitar las patillas y soldarlas de forma definitiva.
Todavía me quedaba por averiguar la razón de la corrución de los datos… un amigo bromeó que había sido un rayo cósmico, pero yo pensaba que era un error del firmware que al grabar algún parámetro había sobreescrito el bloque equivocado.

Cuando devuelvo el TV a mi amigo y le explico la avería, muy contento, me dice que esta podía ser también la avería de otro TV que tenía. Es cierto, hacía unos meses habíamos estado intentando reparar un Blaupunkt BLA-236/173J con lector de DVD pero nos había sido imposible. Él lo solucionó comprando otro igual pero con el TFT roto y cambiando la placa base. Pero el cambio le funcionó unos meses y de nuevo muerto…
Recuperamos los restos de los TV del trastero y nos ponemos a ello. A ver que sacamos partiendo de dos Blaupunkt iguales averiados con el mismo problema en la placa base, modelo T.MSD309.B66B:

Esta placa base solo tiene una EEPROM, pero la técnica es la misma: desoldarla, leerla, buscar un firmware nuevo adecuado, grabarla, resoldarla para pruebas y soldarla definitivamente, si todo va bien.

Buscando por aqui: http://remont-aud.net/dump/lcd_pdp_tv/blaupunkt/blaupunkt_bla_23207i_gb_3b_hkdp_uk_b23u207thdd_shassi_main_board_t_msd309_b66b/380-1-0-37955
Encontré algunos que mediofuncionaban, aunque no manejaban adecuadamente el modelo de panel que este TV usaba:

Encontré otross que funcionaron bien, lo que confirmaba que el problema era el firmware corrupto, pero ninguno tenían soporte para DVD:

Pensando que el problema era un bloque de eeprom incorrecto, me pongo a comparar todas los firmwares .bin que había descargado con el backup que había leído, intentando buscar un bloque discrepante. Estos firmwares son modulares y dentro contienen secciones con el bootloader, el driver del panel, sintonizador, etc y los menús que cada fabricante personaliza.
Después de mucho comparar no pude ver diferencias en la estructura entre el backup corrupto y los firmwares operativos. Todo parecía estar en su sitio y no había bloques borrados.
Pero la casualidad, que a veces ayuda, me hace ver, en un bloque vacío, un dato discordante:

Un cuatro (04 hexadecimal, que es 00000100 en binario) en medio de un bloque de ceros… Un bit que debia estar a cero esta a uno!!! ¿Es este el problema? Pues SI! después de cambiar este 04 a 00 y grabar la memoria de nuevo el TV vuelve a funcionar como al principio, y con soporte para el lector de DVD! Es mucha casualidad haber encontrado un bit cambiado en 32 millones, pero estaba en una zona de buena visibilidad. Si el bit eeróneo hubiera estado en una zona con datos habría sido imposible identificarlo. Aunque el bit estaba en una zona vacía es común que el firmware realize un autochequeo con un checksum y si no es correcto no arranque, por seguridad.

Ahora ya no me parece tan raro lo del rayo cósmico, aunque es raro… También puede deberse a una mala calidad de la memoria EEPROM o un proceso de grabación incorrecto. La eeprom de este modelo era una GD25Q32 de GigaDevice: http://www.gigadevice.com/product/detail/5/365.html?locale=en_US.

Lo claro es que flasheando este firmware parcheado en las dos EEPROM se repararon las dos placas base del Blaupunkt y el TV funcionó de nuevo. Ya hora con una placa base de repuesto!

Si puede serle de ayuda a alguien, este es el firmware leido y reparado para esta placa T.MSD309.B66B del Blaupunkt BLA-236/173J-GB-4B-FHKDUP-EU: T.MSD309.B66B uf11 GD25Q32 Leida Reparada

Actualización 24/11/2017
Parece que la epidemia de datos corruptos en memorias SPI se extiende a otros aparatos, y a memorias I2C. Ayer reparé un (bastante caro) medidor de espesores por ultrasonidos Krautkramer Branson DM4E.
El aparato es muy parecido a este:

Mide espesores mediante una sonda de contacto por ultrasonidos de entre 1Mhz a 10Mhz. El aparato mostraba «FAIL» en la pantalla y un proveedor nos ofertó repararlo por casi 2000€. Por suerte teníamos otro igual para comprobar…
El problema estaba en una EEPROM I2C Microchip 24lc65.

Por alguna extraña razón el medidor interpretaba que los datos contenidos en la memoria, a penas 64 bytes de los 8K bytes disponibles, no eran correctos y se negaba a trabajar. Un «transplante» de datos desde la EEPROM del otro medidor que funcionaba correctamente y una nueva calibración y reparado!

En construcción.
Esta semana estoy trabajando un poco la ingenieria inversa, a ver si soy capaz de sacar algo en claro de los CIS Contact Image Sensor).
Tengo un puñado de ellos, incluido uno enorme y antiguo para DIN A3 TCD120AC.

Desgraciadamente no hay mucha información técnica pública en internet. De lo poco que he podido encontrar esta hoja de datos de Dyna Image es muy interesante: https://www.tvsat.com.pl/pdf/D/dl100_dyna.pdf
Parece ser que son dispositivos muy personalizables y los fabricantes de escáners los encargan a medida. http://www.csensor.com/M118_CIS.htm
Los sensores CIS son mucho mas fáciles de usar que los CCD (que requieren varios clock y tiempos muy precisos y la salida necesita preamplificador etc). La salida de los CIS suele ser de entre 2,5V a 5V de fondo de escala. Podemos introducirla directamente en un A/D de cualquier micro.
Los elementos sensores son CMOS y eso les da unas características electro ópticas bastante buenas. No he podido encontrar las curvas de sensibilidad espectral de los elementos supongo que serán las típicas de los fotodiodos para luz visible.
Los fabricantes estan empleando CIS para sustituir los CCDs en los escáneres, faxes etc porque les simplifica y abarata los diseños: ya no neceesitan complejas ópticas con espejos y delicados ajustes.
Eso también ayuda a usarlos con facilidad a nivel de aficionado que sean grandes, 216mm (ancho del papel DIN A4), y que tengan bastantes elementos (mínimo unos 8 por mm, 1728 en total).

De todos los que tengo no he podido encontrar hoja de datos de ninguno, algunos se ve claramente que el código marcado es un código de cliente…
Por suerte tengo dos Dyna Image similares a los de la hoja de datos.
Uno es un DL100-10AFJK con conector de 12 pines y el otro un DL100-05EUJK con conector de 7 pines que parece coincidir con la hoja de datos.

Preparo un programa para Arduino UNO sencillo, para tratar de comunicar con él.
Parece ser que todos usan un sistema muy parecido, la salida es analógica y de un nivel compatible con un A/D de 5V fondo de escala. Solo hay que proporcionar dos señales para la lectura:
Pulso SP, (Start pulse) que señala el comienzo de línea y
Pulsos SP o CLK (Clock) que generan la salida del valor analógico de cada punto de imagen.

Para la visualización de las líneas capturadas uso un programa en Processing en un PC con Windows:

Fuentes para probar la lectura de datos de diversos CIS Contact Image Sensor), para Arduino UNO y para el PC, en java con Processing:

Descargar todas las fuentes del proyecto: CISReader.zip

Lectura de CIS DynaImage DL100-05EUJK a baja velocidad:

Lectura de CIS DynaImage DL100-05EUJK a alta velocidad:

Lectura de CIS SS30009B de color RGB: