2004 to 2020 Mazda 3 Forum and Mazdaspeed 3 Forums banner
61 - 80 of 319 Posts
Clip de prueba del programador SOP 16 ebay
ebay.com/p/Programmer-Testing-Clip-SOP-16-SOP-SOIC-16-Dip16-Pin-IC-Test-Clamp-With-Cable/2131170762

Programador USB BIOS EEPROM SPI FLASH CH341A serie 24 25
ebay.com/itm/USB-BIOS-EEPROM-SPI-FLASH-Programmer-CH341A-24-25-series-/301443899698

programa y controlador: karadev.net/basto/CH341A-programmer-software-1.29/CH341A-1.29-programmer-software.zip

conectando :
Image
nombre oficial de la partición desplazamiento antes de v31 desplazamiento después de v31
bootstrap 0x000000 0x000000
boot-select 0x010000 0x010000
ibc1 0x020000 0x020000
ibc2 0x040000 0x040000
nv-config 0x060000 0x060000
config 0x070000 0x070000
jci-boot-diag n/a 0x0D0000
fail-safe 0x0E0000 0x0E0000
actualizar 0x7E0000 0x7E0000
verifique esto para obtener más información: 2x4logic.com/jci-failsafe.html
¿cómo verificar esto y escribir esto, qué software usar?
 
nombre oficial de la partición desplazamiento antes de v31 desplazamiento después de v31
bootstrap 0x000000 0x000000
boot-select 0x010000 0x010000
ibc1 0x020000 0x020000
ibc2 0x040000 0x040000
nv-config 0x060000 0x060000
config 0x070000 0x070000
jci-boot-diag n/a 0x0D0000
fail-safe 0x0E0000 0x0E0000
update 0x7E0000 0x7E0000
Consulta esto para obtener más información: 2x4logic.com/jci-failsafe.html
¿Qué software usar para cambiarlo?
 
Hola,

Estoy haciendo un procedimiento paso a paso usando Rasberry Pi y, desafortunadamente, mi Mazda Connect aún está muerto.
En mi opinión, todo se ve bien al ejecutar cada comando. Solo el mensaje después de un comando no me parece claro y no sé si debería ser así (adjunto) ...
¿Alguien puede intentar ayudarme con mi problema?
Hola. Tengo el mismo problema, ¿lograste arreglar el tuyo? ¿O alguien sabe cómo solucionarlo?
 
Reparación de CMU bloqueada

Hola,

En realidad, tu CMU está bloqueada. Hice exactamente lo mismo que tú, donde mi coche se apagó justo después de instalar el paquete a prueba de fallos. Afortunadamente, hay una forma de recuperarse, lo cual no es tan fácil de hacer, pero es bastante factible si no tienes miedo de desmontar la CMU, abrirla y conectar algunos cables.

Explicación completa:
Gracias a este sitio web: http://www.2x4logic.com me ahorra mucho tiempo para averiguar cómo funciona el sistema. El proceso de actualización de la CMU está muy mal diseñado, ya que tiene muchos puntos de fallo donde termina con un dispositivo bloqueado que ya no arrancará. La forma más fácil de hacerlo es apagar la CMU después de instalar el paquete a prueba de fallos. Básicamente, lo que sucede es que un pequeño chip flash que contiene el programa de arranque tiene una bandera que decide en qué sistema debe arrancar. Puede ser el sistema Mazda normal o el software «a prueba de fallos». Cuando instalas el paquete de actualización a prueba de fallos sin el segundo paquete de reinstalación, el modo de selección de arranque del chip flash se establece para arrancar en la partición ibc1, que no coincide con el sistema Mazda actual. Esta partición ibc1 se actualiza mediante el paquete de reinstalación. Por lo tanto, está bloqueado porque ya no puede arrancar.
La solución más fácil aquí es cambiar el valor de selección de arranque en el chip flash para arrancar en ibc2 (a prueba de fallos). Esto normalmente lo hace el proceso de actualización, después de que el paquete de reinstalación se verifica para su integridad. Aquí, vamos a hacerlo forzando el arranque. Iniciará el software de instalación «a prueba de fallos», que nos dirá que la instalación falló y que podemos volver a intentarlo poniendo una llave USB en el coche con un paquete de reinstalación correcto. Entonces, la instalación continuará y finalizará.

Tutorial:
Aquí hay un tutorial paso a paso sobre cómo lograr esto. Ten en cuenta que puede ser difícil hacerlo si no entiendes lo que estás haciendo. Pero en caso de que tu CMU esté bloqueada (pantalla negra después de una actualización fallida o algo así) no tienes nada que perder, ¿verdad? Llevar el coche a un concesionario no te ayudará, simplemente te cobrarán por un reemplazo completo de la CMU, y eso cuesta mucho...

El chip flash se coloca en la parte posterior de la PCB de la CMU. Es una NOR SPI Flash. La idea es conectarse directamente a este chip y usar una raspberry pi (que tiene un bus SPI) para reprogramar la memoria.

Hardware requerido:

  • [* ]Una raspberry pi
    [* ]Un clip de prueba de programador SOIC16 o 6x clips de prueba IC (usé clips de prueba)
    [* ]Una placa de pruebas para hacer las conexiones
En la raspberry pi, necesitas instalar Raspbian (la versión Lite está bien). Desde una nueva instalación de Rasbian, configura la pi para que tenga SPI habilitado ejecutando:
Code:
sudo raspi-config
(habilitar SPI en Opciones de interfaz*)
sudo reboot
Instala algunas herramientas necesarias:
Code:
sudo apt-get update
sudo apt-get install build-essential libusb-1.0-0-dev libusb-dev git wget curl libpci-dev
Obtén una versión más reciente de flashrom:
Code:
git clone https://github.com/flashrom/flashrom
cd flashrom
make
sync
Apaga la alimentación de la raspberry.

Ahora la raspberry pi está lista. Desmonta la CMU de tu coche (busca en youtube un vídeo sobre cómo hacerlo, es fácil), desenrosca la PCB de la CMU y conecta los cables de la raspberry al chip flash como aquí (ver foto adjunta) y http://www.2x4logic.com/mcbot-annotated.jpg

Enciende la raspberry pi. Y comprueba si se detecta el flash:
Code:
cd flashrom
./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=8000
Esto te dirá si se detecta un chip o no. De lo contrario, tu cableado no está bien. Cuando se detecta algo, flashrom puede decirte que se detectan varios chips diferentes. Esto se debe a que algunos chips del mismo fabricante pueden tener el mismo protocolo. Necesitas leer el modelo de dispositivo correcto de lo que está escrito en el chip. Yo tenía un MX25L6445E. Sé que algunas otras CMU pueden tener un modelo de chip diferente. También debería funcionar si flashrom puede detectarlo.

Luego, intenta leer la memoria y hacer una copia de seguridad:
Code:
./flashrom -r backup-cmu.bin -c "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F" -V -p linux_spi:dev=/dev/spidev0.0,spispeed=8000
Lee atentamente lo que está haciendo flashrom para comprobar si hay algún fallo. Tuve que usar la opción -c "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F" para seleccionar el modelo de chip correcto en flashrom, ya que estaba escrito al usar la opción -p (enumera todos los dispositivos detectados)

Una vez que tengas la copia de seguridad, modificamos el byte de selección de arranque dentro del archivo
Code:
cp backup-cmu.bin cmu-mod.bin
printf '\x00' | dd of=cmu-mod.bin bs=1 seek=65536 count=1 conv=notrunc
Ahora es el momento de escribir el archivo modificado en el flash:
Code:
./flashrom -w cmu-mod.bin -c "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F" -V -p linux_spi:dev=/dev/spidev0.0,spispeed=8000
Lee el flash de nuevo para verificar que funcionó
Code:
./flashrom -r cmu.bin -c "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F" -V -p linux_spi:dev=/dev/spidev0.0,spispeed=8000
Comprueba si el archivo coincide verificando la suma de comprobación
Code:
sha1sum cmu.bin cmu-mod.bin
La suma de comprobación debe coincidir, si lo hacen, el procedimiento está hecho. Es hora de desenchufar todo y volver a poner la CMU en el coche. La CMU debería arrancar en el sistema de recuperación a prueba de fallos y pedirte una llave USB con el paquete de reinstalación.

¡Buena suerte y feliz hacking! ;
Raoulh.
También hice el a prueba de fallos y decidí dejar que el coche se apagara y volviera a encenderse = ¡bloqueado!
Así que seguí tus instrucciones, compré el kit, jugué con los comandos y logré decirle a FLASH que se volviera a cargar, muchas gracias. Me hago eco de lo que mucha gente ha dicho aquí, me salvaste a lo grande con esas instrucciones. También logré actualizar a 70.00.100A también :).
¡Eres increíble!
Rodger
 
No puedo recordar qué versión estaba dentro de mi CMU antes de que la pantalla muriera. En este momento, he logrado volver a flashearlo, pero necesito poner un USB con una versión adecuada. ¿Cómo puedo verificar qué versión está dentro? ¿Puedo verificarlo a través de raspbian o conexión serial? Si es posible, ¿qué comando debo usar?
 
Encontré 3 opciones diferentes:
  1. Conexión SSH a través de un adaptador usb-ethernet: Use, por ejemplo, WinSCP para navegar a /jci/version.ini y copiarlo y abrirlo; allí se encuentra la información de la versión del firmware. Más detalles, consulte esta publicación: Atascado en un bucle de instalación de V.59 a V.70
  2. Conexión serie: Mostrar la versión del firmware en Putty; consulte los detalles en esta publicación: Atascado en un bucle de instalación de V.59 a V.70
  3. Conexión serie: Copie /jci/version.ini (con la versión del firmware) en una memoria USB formateada en FAT32 para leer el contenido del archivo más tarde; consulte los detalles en esta publicación: Atascado en un bucle de instalación de V.59 a V.70
Recomendaría la opción 3.
 
¿Quizás alguien (por ejemplo, @raoulh) pueda ayudarme?
Tengo un CMU de repuesto muerto. Lo recibí como defectuoso. No sé por qué no funciona. No arranca en absoluto. Cuando se enciende, la pantalla permanece en *****. Y también a través de la conexión serie no hay señales de vida. Espero/pensé que podría revivirlo flasheando el chip SPI NOR. Conseguí todas las piezas que mencionó Viên Tịnh y conecté el chip correctamente (verificado 3 veces), ya que puedo leer el chip con éxito y hacer un archivo de respaldo *.bin. Pero cuando intento escribir el valor 00 como recomienda raoulh, aparece un error: "Error de tiempo de espera de las operaciones de escritura" (ver captura de pantalla). Uso el botón ESCRIBIR en la fila superior. Por favor, házmelo saber qué puedo intentar para escribir con éxito. Gracias.

Error:
 
¿Quizás alguien (por ejemplo, @raoulh) pueda ayudarme?
Tengo un CMU de repuesto muerto. Lo obtuve como defectuoso. No sé por qué no funciona. No arranca en absoluto. Cuando se enciende, la pantalla permanece en *****. Y también a través de la conexión en serie no hay señales de vida. Espero/pensé que podría revivirlo flasheando el chip SPI NOR. Conseguí todas las piezas que mencionó Viên Tịnh y conecté el chip correctamente (verificado 3 veces), ya que puedo leer el chip con éxito y hacer un archivo de respaldo *.bin. Pero cuando intento escribir el valor 00 como recomienda raoulh, aparece un error: "Write operations timeout failed" (ver captura de pantalla). Uso el botón WRITE en la fila superior. Por favor, házmelo saber qué puedo intentar para escribir con éxito. Gracias.

Error:
View attachment 279882
Necesita borrar antes de escribir, así que primero BORRAR, luego ESCRIBIR y por último VERIFICAR.
 
Gracias. Es bueno saberlo, ya que es la primera vez que uso esta herramienta. Pero incluso si borro con éxito (e hice la verificación en blanco con éxito), no puedo escribir directamente ni abrir y escribir el "archivo bin" con el valor "00" parcheado previamente. Siempre obtengo el mismo error de escritura que se muestra en la captura de pantalla de mi publicación anterior. ¿Alguna otra idea?

Intenté:
a) leer -> borrar -> en blanco -> escribir (siempre con el valor 00 en la línea 10000) = sin éxito
b) leer -> borrar -> escribir = sin éxito
c) leer -> borrar -> abrir (archivo bin con el valor 00) -> escribir = sin éxito
d) leer -> borrar -> en blanco -> leer (todos los valores siguen siendo FF) -> escribir = sin éxito
e) verificar (estado: la memoria principal del chip está en blanco) -> abrir (archivo bin con el valor 00) -> escribir = sin éxito
f) abrir (archivo bin con el valor original FF) -> escribir = 100% y luego no hay mensaje de error, así que supongo que tuvo éxito, incluso si eso no es lo que quiero lograr, por lo que básicamente la función de escritura podría funcionar.

El esquema/patrón de conexión que se muestra en post#16 es la vista desde arriba al programador CH341, ¿verdad? Entonces las conexiones deberían verse así (agregué líneas rojas/azules solo como ejemplo).


Mi chip es el mismo que se muestra en este hilo:

...y instalé los controladores de 64 bits, ya que en mi Win10 de 64 bits no se pudieron instalar los controladores de 32 bits vinculados. Fuente: karadev.net/basto/CH341A-programmer-software-1.29/ -> Archivo ZIP PAR 2.2
 
Después de 2 reconexiones más y la reinstalación de los controladores y usando CH341A Programmer Versión 1.34 (antes de 1.29) finalmente pude escribir el valor 00 en la línea 10000. Pero la pantalla sigue en ***** después de conectar el cmu (y no arranca). ¿Alguna idea de cómo proceder? ¿Algún otro valor que pueda cambiar? ¿Algo más que pueda hacer? ¿Hay algún otro proceso?
 
Lo he hecho para un amigo, el mismo programador y este Test Clip y funcionó bien, también usé un archivo de inicio de este usuario aquí y arrancó, creo que es la versión 51.00.300 NA. Espero que hayas guardado el archivo que leíste, ¿podrías publicarlo aquí? Tal vez CMU tenga más problemas que un problema de arranque.
 
Gracias de nuevo. Borré el chip, abrí el archivo vinculado de usted/macomeza, lo escribí y lo verifiqué en el chip, pero el cmu todavía está muerto. Ninguna señal de vida, cuando está conectado. La pantalla sigue negra y el acceso serie no muestra ningún texto que pase - solo un cuadrado verde inmóvil. Por favor, encuentre adjunto mi archivo *.bin original, que leí/guardé/copié antes de hacer cambios: Downloadlink Correcto, como no sé el origen del brick/cómo se brickeó, también podría ser, por ejemplo, un problema de hardware o algo más. Ya he revisado el cableado, pero mi CMU cx-5 normalmente instalado tiene el mismo cableado que este CMU mx-5/miata brickeado.

Uso casi el mismo clip de prueba que usted:


P.S.: Y envié un correo electrónico a Vien Tinh, pero él sabía exactamente cómo brickeó su cmu en ese entonces y lo arregló manualmente copiando los valores hexadecimales de los archivos de firmware a prueba de fallos a la sección de desplazamiento correcta en el chip cmu y esto funcionó para él. También intenté esto, pero desafortunadamente sin éxito.
 
Lo siento Tristan, pero el archivo que publicaste está vacío, todo FF, tal vez ese sea tu problema, vuelve a leer el rescue.bin que acabas de programar y compáralo con el archivo original. El Hash MD5 de Rescue.bin es: 688b34e65e2d24fae62887dadf0b5a90.
 
Maldita sea, esta era la única copia de seguridad que tenía. No comprobé si estaba vacía o si tenía valores escritos. Obviamente, la herramienta de programación CH341 me mostró que la lectura era posible y almacenó un archivo (pero vacío). Por eso asumí que mi conexión estaba bien. Pero parece que el clip no estaba conectado correctamente al chip. Así que ya no tengo ninguna copia de seguridad original :-( Ahora tengo HxD como Editor HEX. Flasheé correctamente el rescue.bin (sin ningún cambio) y la cmu sigue muerta y sin signos de vida a través de putty/acceso serie visible - lo mismo después de que cambié el valor FF a 00 en la línea 010000 -> la cmu sigue muerta. ¿Supongo que el problema no es el chip SPI NOR, sino otra falla de hardware? ¡Muchas gracias craz por toda la ayuda e información!
 
Tengo aquí un segundo CMU con 70.00.352 EU (funcionando). Hice una copia de seguridad de su chip SPI NOR y la copié al CMU muerto. El CMU sigue haciéndose el muerto (sin pantalla/sin actividad serie). Mismo resultado cuando parcheé el valor 00 a la línea 10000 de esta copia de seguridad. Por favor, encuentra estos dos archivos adjuntos:
Así que supongo que este CMU está realmente muerto y no se puede revivir mediante el flasheo SPI NOR.
 
61 - 80 of 319 Posts