bonjour,
j'ai placé ce message sur Linux/embarqué, mais c'est pas tout à fait adapté, mais il s'agit bien d'environnement embarqué, mais sans Linux, sur PF ESP32-wroom.
j'ai eu un soucis avec l'un des petits modules. A la console (Arduino, 115.200 bauds), j'ai ce message qui apparaît cycliquement. Je n'ai plus accès à la fonction de programmation via l'IDE.
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:928
ho 0 tail 12 room 4
load:0x40078000,len:9280
load:0x40080400,len:5848
csum err:0xca!=0x2e
ets_main.c 371
ets Jun 8 2016 00:22:57
- est-ce qu'il existe un moyen de reprendre le controle de cette petite bete ?
- le module en question est ici : https://fr.aliexpress.com/item/ESP32-ESP-32-ESP32S-ESP-32S-CP2102-Sans-Fil-WiFi-Bluetooth-Conseil-de-D-veloppement-micro/32928267626.html?spm=a2g0s.9042311.0.0.1a1a6c37CpwuVC
- l'OS natif est en principe un FreeRTOS. Manifestement le boot s'arrête après le checksum
csum err:0xca!=0x2e
# firmware
Posté par Anonyme . Évalué à 3.
je connais pas ces modèles mais je dirais qu'en utilisant esptool pour voir ce que le MCU raconte et en reflashant le firmware ça pourrait refonctionner.
Sinon à terme c'est possible que ce soit la mémoire flash interne qui meurt et qui ne permet plus la réécriture.
[^] # Re: firmware
Posté par Marc Quinton . Évalué à 2.
je me suis déjà aventuré du coté de la ligne de commande avec le kit esptool, sans grand succès. Je n'ai pas vraiment eu le temps de creuser.
Idéalement, ce serait bien que ces modules soient dotés d'un bootloader en ROM plutot qu'en flash. Si le bootloader est endomagé, je crois que je vais avoir du mal à récupérer.
l'idée de mon message était surtout de sonder rapidement auprès de la communauté, si d'autre avaient eu la même expérience.
merci pour ta réponse.
[^] # Re: firmware
Posté par Marc Quinton . Évalué à 2. Dernière modification le 05 avril 2019 à 15:09.
2 modules ESP32, l'un OK, l'autre KO :
[^] # Re: firmware
Posté par NeoX . Évalué à 3.
sur mes modules ESP32 quand j'ai le "connecting…"
il faut que j'appuie sur un bouton (juste à coté du reset) pour autoriser la connexion
sinon ca ne flash pas mon programme arduino
sur d'autre modele, il y a une resistance qui joue ce role et autorise le "flash" sans controle
[^] # Re: firmware
Posté par Marc Quinton . Évalué à 2.
merci pour le commentaire.
Pour ma part, c'est assez variable. J'en perds mon latin. Généralement, ça démarre tout seul. Parfois un simple appui sur RESET ou BOOT.
suite à l'étude des différents documents, et en conformité avec le schéma électronique, le module ESP32 se met en mode téléchargement quand on force la GPIO0 au niveau bas. Au controleur, on voit bien que le signal est mis au niveau bas (j'ai juste contrôle à ohmmètre).
[^] # Re: firmware
Posté par Marc Quinton . Évalué à 3.
plein d'infos intéressante sur cette pagen à propos de l'ESP32, les messages en console au moment du boot, les différents mode de boot et pins associées : https://github.com/espressif/esptool/wiki/ESP32-Boot-Mode-Selection#boot-mode-message
[^] # Re: firmware
Posté par Anonyme . Évalué à 4.
Je suis pas sûr que ce soit une bonne idée. Surtout si c'est une ROM et pas une EEPROM.
ÀMHA (encore une fois je ne connais pas cette puce) il y a déjà une bootrom pour l'amorçage et les fonctions très bas niveau. Le firmware étant davantage le "système d'exploitation" sur lequel tu fais tourner ton programme, pas un bootloader à proprement parler. Le fait d'avoir accès à la mémoire du firmware permet la réinstallation, la mise à jour, ou d'utiliser un autre interpréteur comme NodeMCU.
Dans ce genre de composant embarqué moderne, quasiment toute la mémoire non volatile est en NAND Flash plutôt qu'en NOR pour des raisons de coûts et de place donc je ne pense pas que ton idée soit envisageable sans concessions sur la taille du stockage ou le prix d'achat.
Si elle n'est pas réécrite des milliers de fois, une NAND fait le job et retiendra les données durant des décennies avant que la tension des cellules descendent en dessous du seuil du niveau logique haut. Donc probablement que tu as une cellule défaillante et si la gestion de la mémoire est un peu intelligente, cette cellule sera déclarée comme inutilisable et écartée de la mémoire disponible lors de l'échec de son nouveau cycle d'effacement/réécriture.
[^] # Re: firmware
Posté par Marc Quinton . Évalué à 3.
après un peu de lecture, j'ai vu qu'on pouvait booter sur le port série, ou via la mémoire interne (firmware). Une partie du processus semble se dérouler sur le module défaillant. J'ai un peu de mal à voir ou ca coince.
maintenant, il faut trouver le juste équilibre en temps passé pour une montée en compétence et le recyclage des produits semi-défectueux dont le prix unitaire est < 5€.
[^] # Re: firmware
Posté par Anonyme . Évalué à 3.
sympa, ça permet de tester des projets sans user la NAND.
C'est possible que l'erreur de checksum ne concerne que le projet, pas le firmware, et que toute erreur de ce type déclenche un mécanisme de blocage dans ce firmware qui ne peut se résoudre qu'en opérant à plus bas niveau. Pareil, je ne connais pas FreeRTOS donc ce n'est qu'une hypothèse.
Apparemment esptool permet de voir à quelles adresses sont enregistrés les morceaux de firmware. Et vu que c'est un lien SPI tu peux très certainement trouver la ou les zones fautives par comparaison de d'écriture et lecture et il est peut-être même possible d'y éviter l'écriture du firmware ou de bannir ces adresses mémoire de FreeRTOS.
Si c'est un hobby auquel tu n'as pas beaucoup de temps à accorder, attendre 3 semaines la livraison d'un remplacement est sans doute préférable.
À ce prix-là je commanderai et si j'arrive à réparer le MCU entre temps, la nouvelle pièce me permettrait d'avoir une carte exclusivement pour bidouiller ou une carte de rechange si un jour j'utilise cet ESP32 dans un projet à haute disponibilité.
J'aurai aussi éventuellement acheté quelques unités d'avance de ce MCU mais malheureusement un boitier QFN avec sa large connexion de masse sous le composant rend l'opération de remplacement assez délicate, surtout pour la première extraction vu qu'un assemblage d'usine utilise de l'étain ROHS à haut point de fusion et pas de la soudure basse température. C'est moins compliqué qu'un boitier BGA mais ça reste peu trivial comparé à un boitier QFP.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.