[mrphanbg]

As-tu traité l'écran
Si ce n'est pas le cas, fais-moi signe, je t'aiderai.

, merci!!! s'il vous plaît ib

 

[nelson]

Clip de test de programmeur SOP 16 ebay
ebay.com/p/Programmer-Testing-Clip-SOP-16-SOP-SOIC-16-Dip16-Pin-IC-Test-Clamp-With-Cable/2131170762

Programmeur USB BIOS EEPROM SPI FLASH CH341A série 24 25
ebay.com/itm/USB-BIOS-EEPROM-SPI-FLASH-Programmer-CH341A-24-25-series-/301443899698

programme et pilote : karadev.net/basto/CH341A-programmer-software-1.29/CH341A-1.29-programmer-software.zip

connexion :

nom de partition officiel décalage avant v31 décalage après v31
bootstrap 0x000000 0x000000
boot-select 0x010000 0x010000
ibc1 0x020000 0x020000
ibc2 0x040000 0x040000
config nv 0x060000 0x060000
config 0x070000 0x070000
jci-boot-diag n/a 0x0D0000
fail-safe 0x0E0000 0x0E0000
mettre à jour 0x7E0000 0x7E0000
vérifiez ceci pour plus d'informations : 2x4logic.com/jci-failsafe.html

comment vérifier cela et écrire ceci, quel logiciel utiliser ??

 

[nelson]

nom officiel de la partition décalage avant v31 décalage après 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
Consultez ceci pour plus d'informations : 2x4logic.com/jci-failsafe.html

Quel logiciel utiliser pour le modifier ?

 

[nelson]

Quelqu'un m'envoie le bon nor flash (.bin) s'il vous plaît. Merci beaucoup!

 

[nelson]

quelqu'un m'a envoyé le bon nor flash (.bin) merci beaucoup

quelqu'un peut-il m'envoyer??

 

[matzuda3]

Bonjour,

Je suis une procédure étape par étape en utilisant Rasberry Pi et malheureusement mon Mazda Connect est toujours mort.
À mon avis, tout semble bon en exécutant chaque commande. Seul le message après une commande ne me semble pas clair et je ne sais pas si cela devrait être comme ça (ci-joint) ...
Quelqu'un est-il en mesure d'essayer de m'aider avec mon problème?

Bonjour. J'ai le même problème, avez-vous réussi à résoudre le vôtre ? Ou quelqu'un sait-il comment le réparer ?

 

[specialedition77]

Réparation CMU brickée

Bonjour,

En fait, votre CMU est brickée. J'ai fait exactement la même chose que vous, où ma voiture s'est éteinte juste après avoir installé le package de sécurité. Heureusement, il existe un moyen de récupérer, ce qui n'est pas si facile à faire, mais c'est tout à fait faisable si vous n'avez pas peur de démonter la CMU, de l'ouvrir et de brancher des fils.

Explication complète :
Grâce à ce site Web : http://www.2x4logic.com, cela m'a fait gagner beaucoup de temps pour comprendre le fonctionnement du système. Le processus de mise à jour de la CMU est en effet très mal conçu, car il comporte de nombreux points de défaillance où il se termine par un appareil brické qui ne démarrera plus. Le moyen le plus simple de le faire est d'éteindre la CMU après l'installation du package de sécurité. Fondamentalement, ce qui se passe, c'est qu'une petite puce flash qui contient le programme de démarrage a un indicateur qui décide sur quel système il doit démarrer. Il peut s'agir du système Mazda normal ou du logiciel « failsafe » ». Lorsque vous installez le package de mise à jour de sécurité sans le deuxième package de réinstallation, le mode de sélection de démarrage de la puce flash est défini pour démarrer sur la partition ibc1, ce qui ne correspond pas au système Mazda actuel. Cette partition ibc1 est mise à jour par le package de réinstallation. Il est donc brické car il ne peut plus démarrer.
La solution la plus simple ici est de modifier la valeur de sélection de démarrage sur la puce flash pour démarrer sur ibc2 (le failsafe). Cela se fait normalement par le processus de mise à jour, après que le package de réinstallation ait été vérifié pour son intégrité. Ici, nous allons le faire en forçant le démarrage. Il démarrera le logiciel d'installation « failsafe » », qui nous dira que l'installation a échoué et que nous pouvons réessayer en mettant une clé USB dans la voiture avec un package de réinstallation correct. Ensuite, l'installation continuera et se terminera.

Tutoriel :
Voici un tutoriel étape par étape sur la façon d'y parvenir. Sachez qu'il peut être difficile de le faire si vous ne comprenez pas ce que vous faites. Mais dans le cas où votre CMU est brickée (écran noir après une mise à niveau ratée ou autre), vous n'avez rien à perdre, n'est-ce pas ? Amener la voiture chez un concessionnaire ne vous aidera pas, ils vous factureront simplement un remplacement complet de la CMU, et cela coûte très cher…

La puce flash est placée à l'arrière du circuit imprimé de la CMU. C'est un NOR SPI Flash. L'idée est de se connecter directement à cette puce et d'utiliser un raspberry pi (qui possède un bus SPI) pour reprogrammer la mémoire.

Matériel requis :

• 
  [* ]Un raspberry pi
  [* ]Un clip de test de programmateur SOIC16 ou 6x clips de test IC (j'ai utilisé des clips de test)
  [* ]Une plaque d'essai pour faire les connexions

Sur le raspberry pi, vous devez installer Raspbian (la version Lite est correcte). À partir d'une nouvelle installation de Rasbian, configurez le pi pour activer SPI en exécutant :

sudo raspi-config
(activer SPI dans les options d'interface*)
sudo reboot

Installez quelques outils requis :

sudo apt-get update
sudo apt-get install build-essential libusb-1.0-0-dev libusb-dev git wget curl libpci-dev

Obtenez une version plus récente de flashrom :

git clone https://github.com/flashrom/flashrom
cd flashrom
make
sync

Éteignez l'alimentation du raspberry.

Maintenant, le raspberry pi est prêt. Démontez la CMU de votre voiture (recherchez sur youtube une vidéo sur la façon de le faire, c'est facile), dévissez le circuit imprimé de la CMU et branchez les fils du raspberry à la puce flash comme ici (voir photo ci-jointe) et http://www.2x4logic.com/mcbot-annotated.jpg

Allumez le raspberry pi. Et vérifiez si le flash est détecté :

cd flashrom
./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=8000

Cela indiquera si une puce est détectée ou non. Sinon, votre câblage n'est pas correct. Lorsque quelque chose est détecté, flashrom peut vous indiquer que plusieurs puces différentes sont détectées. C'est parce que certaines puces d'un même fabricant peuvent avoir le même protocole. Vous devez lire le bon modèle d'appareil à partir de ce qui est écrit sur la puce. J'avais un MX25L6445E. Je sais que certaines autres CMU peuvent avoir un modèle de puce différent. Cela devrait également fonctionner si flashrom peut le détecter.

Ensuite, essayez de lire la mémoire et de faire une sauvegarde :

./flashrom -r backup-cmu.bin -c "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F" -V -p linux_spi:dev=/dev/spidev0.0,spispeed=8000

Lisez attentivement ce que flashrom fait pour vérifier toute défaillance. J'ai dû utiliser l'option -c "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F" pour sélectionner le bon modèle de puce dans flashrom tel qu'il était écrit lors de l'utilisation de l'option -p (liste tous les appareils détectés)

Une fois que vous avez la sauvegarde, nous modifions l'octet de sélection de démarrage à l'intérieur du fichier

cp backup-cmu.bin cmu-mod.bin
printf '\x00' | dd of=cmu-mod.bin bs=1 seek=65536 count=1 conv=notrunc

Il est maintenant temps d'écrire le fichier modifié dans le flash :

./flashrom -w cmu-mod.bin -c "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F" -V -p linux_spi:dev=/dev/spidev0.0,spispeed=8000

Relisez le flash pour vérifier que cela a fonctionné

./flashrom -r cmu.bin -c "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F" -V -p linux_spi:dev=/dev/spidev0.0,spispeed=8000

Vérifiez si le fichier correspond en vérifiant la somme de contrôle

sha1sum cmu.bin cmu-mod.bin

La somme de contrôle doit correspondre, si c'est le cas, la procédure est terminée. Il est temps de tout débrancher et de remettre la CMU dans la voiture. La CMU devrait démarrer dans le système de récupération de sécurité et vous demander une clé USB avec le package de réinstallation.

Bonne chance et bon piratage ! ;

Raoulh.
J'ai également fait le failsafe et j'ai décidé de laisser la voiture s'éteindre et de revenir = brické !
J'ai donc suivi vos instructions, acheté le kit, bricolé avec les commandes et réussi à dire à FLASH de se recharger, merci beaucoup. Je fais écho à ce que beaucoup de gens ont dit ici, vous m'avez sauvé la mise avec ces instructions. J'ai également réussi à passer à 70.00.100A aussi .
Vous êtes génial !
Rodger

 

[dammy89]

Je ne me souviens plus de la version qui était dans mon CMU avant que l'écran ne meure. Pour l'instant, j'ai réussi à le reflasher, mais je dois mettre une clé USB avec une version appropriée. Comment puis-je vérifier quelle version est à l'intérieur ? Puis-je le vérifier via raspbian ou une connexion série ? Si c'est possible, quelle commande dois-je utiliser ?

 

[Tristan-cx5]

J'ai trouvé 3 options différentes :

1. Connexion SSH via adaptateur usb-ethernet : Utilisez par exemple WinSCP pour naviguer vers /jci/version.ini et le copier et l'ouvrir - les informations de version du micrologiciel s'y trouvent. Plus de détails dans ce message : Bloqué dans une boucle d'installation de V.59 à V.70
2. Connexion série : Afficher la version du micrologiciel dans Putty - voir les détails dans ce message : Bloqué dans une boucle d'installation de V.59 à V.70
3. Connexion série : Copier /jci/version.ini (avec la version du micrologiciel) sur une clé USB formatée en FAT32 pour lire plus tard le contenu du fichier - voir les détails dans ce message : Bloqué dans une boucle d'installation de V.59 à V.70

Je recommanderais l'option 3.

 

[Tristan-cx5]

Peut-être que quelqu'un (par exemple @raoulh) peut m'aider ?
J'ai un CMU de rechange mort. Je l'ai reçu comme défectueux. Je ne sais pas pourquoi il ne fonctionne pas. Il ne démarre pas du tout. Lorsqu'il est alimenté, l'écran reste noir. Et aussi via la connexion série, il n'y a aucun signe de vie. J'espère/pensais que je pourrais le faire revivre en flashant la puce SPI NOR. J'ai obtenu toutes les pièces mentionnées par Viên Tịnh et j'ai correctement connecté la puce (vérifié 3 fois), car je peux lire avec succès la puce et créer un fichier de sauvegarde *.bin. Mais lorsque j'essaie d'écrire la valeur 00 comme recommandé par raoulh, une erreur apparaît : "Échec du délai d'attente des opérations d'écriture" (voir capture d'écran). J'utilise le bouton ÉCRIRE dans la rangée supérieure. Veuillez me faire savoir ce que je peux essayer pour écrire avec succès. Merci.

Erreur :

 

[craz]

Peut-être que quelqu'un (par exemple @raoulh) peut m'aider?
J'ai un CMU de rechange mort. Je l'ai reçu comme défectueux. Je ne sais pas pourquoi ça ne marche pas. Il ne démarre pas du tout. Lorsqu'il est alimenté, l'écran reste noir. Et aussi via une connexion série, il n'y a aucun signe de vie. J'espère/pensais que je pourrais le faire revivre en flashant la puce SPI NOR. J'ai obtenu toutes les pièces mentionnées par Viên Tịnh et j'ai correctement connecté la puce (vérifié 3 fois), car je peux lire avec succès la puce et créer un fichier de sauvegarde *.bin. Mais quand j'essaie d'écrire la valeur 00 comme recommandé par raoulh, une erreur apparaît : "Write operations timeout failed" (voir capture d'écran). J'utilise le bouton WRITE dans la rangée supérieure. Veuillez me faire savoir ce que je peux essayer pour écrire avec succès. Merci.

Erreur :
View attachment 279882

Il faut effacer avant d'écrire, donc d'abord EFFACER puis ÉCRIRE et enfin VÉRIFIER.

 

[Tristan-cx5]

Merci. Bon à savoir, car c'est la 1ère fois que j'utilise cet outil. Mais même si j'efface avec succès (et que j'ai fait la vérification de blanc avec succès), je ne peux ni écrire directement ni ouvrir et écrire le "fichier bin" avec la valeur "00" corrigée précédemment. J'obtiens toujours la même erreur d'écriture affichée dans la capture d'écran de mon message précédent. Une autre idée ?

J'ai essayé :
a) lire -> effacer -> blanc -> écrire (toujours avec la valeur 00 à la ligne 10000) = infructueux
b) lire -> effacer -> écrire = infructueux
c) lire -> effacer -> ouvrir (fichier bin avec la valeur 00) -> écrire = infructueux
d) lire -> effacer -> blanc -> lire (toutes les valeurs sont toujours FF) -> écrire = infructueux
e) vérifier (état : la mémoire principale de la puce est vierge) -> ouvrir (fichier bin avec la valeur 00) -> écrire = infructueux
f) ouvrir (fichier bin avec la valeur d'origine FF) -> écrire = 100% et ensuite aucun message d'erreur, donc je suppose que cela a réussi, même si ce n'est pas ce que je veux obtenir - donc, fondamentalement, la fonction d'écriture pourrait fonctionner.

Le schéma/motif de connexion montré dans post#16 est la vue de dessus du programmateur CH341, n'est-ce pas ? Donc les connexions devraient ressembler à ceci (j'ai ajouté des lignes rouges/bleues juste à titre d'exemple).

Ma puce est la même que celle montrée dans ce fil :

...et j'ai installé les pilotes 64 bits, car sur mon Win10 64 bits, les pilotes 32 bits liés n'ont pas pu être installés. Source : karadev.net/basto/CH341A-programmer-software-1.29/ -> Fichier ZIP PAR 2.2

 

[Tristan-cx5]

Après 2 autres reconnexions et la réinstallation des pilotes et en utilisant CH341A Programmer Version 1.34 (avant 1.29), j'ai finalement pu écrire la valeur 00 à la ligne 10000. Mais l'écran reste noir après avoir connecté le cmu (et il ne démarre pas). Une idée de la façon de procéder ? D'autres valeurs que je peux modifier ? Autre chose que je peux faire ? Y a-t-il un autre processus ?

 

[craz]

Je l'ai fait pour un ami, le même programmeur et ce Test Clip et ça a bien fonctionné, j'ai aussi utilisé un fichier de démarrage de cet utilisateur ici et il a démarré, je pense que c'est la version 51.00.300 NA. J'espère que vous avez enregistré le fichier que vous avez lu, pourriez-vous le poster ici ? Peut-être que CMU a plus de problèmes qu'un problème de démarrage.

 

[Tristan-cx5]

Merci encore. J'ai effacé la puce, ouvert le fichier lié de vous/macomeza, l'ai écrit et vérifié sur la puce, mais le cmu est toujours mort. Aucun signe de vie, lorsqu'il est connecté. L'écran est toujours noir et l'accès série n'affiche aucun texte défilant - juste un carré vert immobile. Veuillez trouver ci-joint mon fichier *.bin d'origine, que j'ai lu/enregistré/sauvegardé avant de faire des changements : Downloadlink C'est exact, comme je ne connais pas l'origine de la brique/comment elle a été brickée, cela pourrait aussi être, par exemple, un problème matériel ou autre chose. J'ai déjà vérifié le câblage, mais mon CMU cx-5 normalement installé a le même câblage que ce CMU mx-5/miata brické.

J'utilise presque le même clip de test que vous :

P.S. Et j'ai envoyé un e-mail à Vien Tinh, mais il savait exactement comment il avait brické son cmu à l'époque et il l'a réparé manuellement en copiant les valeurs hexadécimales des fichiers du micrologiciel de sécurité dans la section de décalage correcte sur la puce cmu et cela a fonctionné pour lui. J'ai également essayé cela, mais malheureusement sans succès.

 

[craz]

Désolé Tristan, mais le fichier que tu as posté est vide, que des FF, c'est peut-être ça ton problème, relis le rescue.bin que tu viens de programmer et compare-le au fichier original. Le Hash MD5 de Rescue.bin est : 688b34e65e2d24fae62887dadf0b5a90.

 

[craz]

Le clip à 16 broches que j'ai acheté est venu avec un petit circuit imprimé adaptateur avec le câblage correct comme dans ce post: TEST CLIP. Procurez-vous également un éditeur hexadécimal, il est très utile pour comparer des fichiers, rechercher, calculer des sommes de contrôle, etc.

 

[Tristan-cx5]

Merde, c'était la seule sauvegarde que j'avais. Je n'ai pas vérifié si elle était vide ou si des valeurs y étaient écrites. Évidemment, l'outil de programmation CH341 m'a montré que la lecture était possible et qu'il avait stocké un fichier (mais vide). C'est pourquoi j'ai supposé que ma connexion était correcte. Mais il semble que le clip n'était pas correctement fixé à la puce. Donc je n'ai plus de sauvegarde originale :-( J'ai maintenant HxD comme éditeur HEX. J'ai correctement flashé le rescue.bin (sans aucun changement) et le cmu est toujours mort et aucun signe de vie via putty/accès série visible - de même après avoir changé la valeur FF en 00 dans la ligne 010000 -> cmu est toujours mort. Je suppose que le problème n'est pas la puce SPI NOR, mais une autre panne matérielle ? Merci beaucoup craz pour toute l'aide et les infos !

 

[Tristan-cx5]

J'ai ici un second CMU avec 70.00.352 EU dessus (fonctionnel). J'ai fait une sauvegarde de sa puce SPI NOR et je l'ai copiée sur le CMU mort. Le CMU continue de faire le mort (pas d'affichage/pas d'activité série). Même résultat lorsque j'ai corrigé la valeur 00 à la ligne 10000 de cette sauvegarde. Veuillez trouver ces deux fichiers ci-joints :

• Lien de téléchargement vers la sauvegarde SPI NOR originale d'un CMU 70.00.352 EU fonctionnel
• Lien de téléchargement vers la sauvegarde SPI NOR corrigée d'un CMU 70.00.352 EU fonctionnel (valeur 00 à la ligne 10000)

Je suppose donc que ce CMU est vraiment mort et ne peut pas être relancé via le flashage SPI NOR.

 

[craz]

Zut alors !! Je craignais que ce soit plus qu'un bootloader bloqué, maintenant vous avez une bonne sauvegarde pour votre CMU de banc au cas où...