Forum Linux.embarqué ESP32 / problème de flash et reboot

Posté par . Licence CC by-sa.
0
5
avr.
2019

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
  • # firmware

    Posté par . Évalué à 3.

    est-ce qu'il existe un moyen de reprendre le controle de cette petite bete ?

    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 . É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 . Évalué à 2. Dernière modification le 05/04/19 à 15:09.

        2 modules ESP32, l'un OK, l'autre KO :

        # OK pour celui-ci
        marc@gigabyte:~$ esptool.py flash_id
        esptool.py v2.6
        Found 1 serial ports
        Serial port /dev/ttyUSB0
        Connecting....
        Detecting chip type... ESP32
        Chip is ESP32D0WDQ6 (revision 1)
        Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
        MAC: a4:cf:12:45:be:3c
        Uploading stub...
        Running stub...
        Stub running...
        Manufacturer: 20
        Device: 4016
        Detected flash size: 4MB
        Hard resetting via RTS pin...
        
        # KO pour celui-ci
        marc@gigabyte:~$ esptool.py flash_id
        esptool.py v2.6
        Found 1 serial ports
        Serial port /dev/ttyUSB0
        Connecting........_____....._____....._____....._____....._____....._____....._____
        /dev/ttyUSB0 failed to connect: Failed to connect to Espressif device: Timed out waiting for packet header
        
        A fatal error occurred: All of the 1 available serial ports could not connect to a Espressif device.
        ```il y a plein d'autre options sur esptool.py, mais ca reste sans résultat.
        
        • [^] # Re: firmware

          Posté par . Évalué à 3.

          Serial port /dev/ttyUSB0
          Connecting……..__…..…..…..…..…..…..___
          /dev/ttyUSB0 failed to connect: Failed to connect to Espressif device: Timed out waiting for packet header

          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 . É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 . É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 . Évalué à 4.

        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.

        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 . É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 . É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).

            sympa, ça permet de tester des projets sans user la NAND.

            Une partie du processus semble se dérouler sur le module défaillant. J'ai un peu de mal à voir ou ca coince.

            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.

            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€.

            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 à ceux qui les ont postés. Nous n'en sommes pas responsables.