LoadProbited ESP32cam reboot

Lorsque j’essaye d’ajouter le code de demo pour recevoir un signal (RC Switch), j’obtiens une erreur de type Guru Meditation Error: Core 1 panic’ed (LoadProhibited). Le code de base qui permet capturer une photo et l’envoyer via blynk est fonctionnelle. C’est simplement lorsque j’avoue cette partie de code que cela plante et fait rebooter l’esp32 en boucle :

  Serial.print("Ready to receive.");
  mySwitch.enableReceive(digitalPinToInterrupt(15));
  delay(1000);

Auriez-vous une idée de ce qui cloche ? J’ai trouvé un problème similaire mais impossible de vraiment comprendre comment implémenter la solution : ESP always crashing when attach an Interrupt. · Issue #90 · espressif/esp-who · GitHub
Erreur

Ready to receive.Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.
Core 1 register dump:
PC      : 0x4015849b  PS      : 0x00060833  A0      : 0x801362b7  A1      : 0x3ffb1e50  
A2      : 0x00000000  A3      : 0x3ffb8058  A4      : 0x00000001  A5      : 0x00000001  
A6      : 0x00060820  A7      : 0x00000000  A8      : 0x80135be9  A9      : 0x3ffb1e20  
A10     : 0x02000000  A11     : 0x401357a4  A12     : 0x3ffb1e38  A13     : 0x00000001  
A14     : 0x00060a20  A15     : 0x00000000  SAR     : 0x00000007  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x00000000  LBEG    : 0x4000c46c  LEND    : 0x4000c477  LCOUNT  : 0x00000000  
Backtrace: 0x4015849b:0x3ffb1e50 0x401362b4:0x3ffb1e70 0x40138018:0x3ffb1ea0 0x40138197:0x3ffb1ed0 0x400d247a:0x3ffb1f00 0x400d5853:0x3ffb1fb0 0x4008bc19:0x3ffb1fd0

Interprétation de l’erreur

PC: 0x401584a3: esp_intr_get_cpu at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/intr_alloc.c line 780
EXCVADDR: 0x00000000

Decoding stack results
0x401584a3: esp_intr_get_cpu at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/intr_alloc.c line 780
0x401362bc: gpio_isr_handler_add at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/driver/gpio.c line 389
0x40138020: camera_init at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/components/esp32-camera/driver/camera.c line 1205
0x4013819f: esp_camera_init at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/components/esp32-camera/driver/camera.c line 1268
0x400d2482: setup() at /Users/admin/Downloads/Code_Security_Camera_ESP32CAM_Blynk_02/Code_Security_Camera_ESP32CAM_Blynk_02.ino line 115
0x400d585b: loopTask(void*) at /Users/admin/Library/Arduino15/packages/esp32/hardware/esp32/1.0.4/cores/esp32/main.cpp line 14
0x4008bc19: vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c line 143

Bonjour

-la gestion des interruptions sur un ESP32 est différente de celle des micros AVR,
Votre code fait planter l'ESP32 parce qu'il ne tient pas compte de ces particularités.
Lancer un moteur de recherche avec 'ESP32 interruptions" pour découvrir la manière de gérer les interruptions externes sur un ESP32

-il n'est pas certain que la librairie RCSwitch soit compatible avec l'ESP32

Bonjour et merci pour ta réponse

-la gestion des interruptions sur un ESP32 est différente de celle des micros AVR, votre code fait planter l'ESP32 parce qu'il ne tient pas compte de ces particularités
Peux-tu m'aider à comprendre ce qu'il faudrait changer dans mon code pour que ca ne plante plus ?

il n'est pas certain que la libaririe RCSwitch soit compatible avec l'ESP32
Lorsque je test le code de demo de RC switch sur l'esp 32, tout fonctionne et je n'ai aucune erreur et tout fonctionne. Peux-t-on en déduire que l'interrupt fonctionne tel qu'il est écrit et que la librarie est compatible ?

voir le code testé et fonctionnel sur esp32 cam ici-> rc-switch/ReceiveDemo_Advanced.ino at master · sui77/rc-switch · GitHub

le principe des interruptions externes avec un ESP32 est bien décrit sur ce site :

il y a même un exemple ou une interruption issue d'un capteur PIR déclenche une prise de vue sur une carte ESP32CAM

je ne connais pas la librairie RCswitch, à part son existence... et ne prévois pas de m'y intéresser vu que les télécommandes sur 433 MHz en OOK/ASK disparaissent de mon environnement domestique !

J'ai suvi tes recommandations et j'ai modifié un peu les parties qui concernent l'interrupt comme ceci :

  esp_sleep_enable_ext0_wakeup(GPIO_NUM_13, 0);
  mySwitch.enableReceive(digitalPinToInterrupt(GPIO_NUM_13));

Malheureusement ca ne fonctionne toujours pas :confused: Pourtant lorsque je test le code indépendemment tout fonctionne bien…

les deux lignes de cod eque tu montres ne suffsient pas à produire une interruption concenabel sure ESP32

il est impératif que la fonction appelée lors d'une interruption ("handler") possède l'attribut IRAM_ATTR comme dans le second exemple ci dessous où le détecteur PIR interrompt l'ESP32

void IRAM_ATTR detectsMovement() {.......

Est-ce le cas dans ton code (ou dans celui de la librairie utilisée) ?
(le petit bout de code à éxécuter lors de l'interruption externe doit être implanté en RAM et non en mémoire flash comme le reste du code)

Ne connaissant pas RCSwitch je ne peut aider davantage, ne sachant pas ce qui s'y passe.

Sur un ESP32 on a deux coeurs. Le coeur des applications fonctionne comme un Arduino normal. Mais les routines d'interruption s'exécutent sur l'autre coeur. Les précautions qu'on prend ordinairement sur un mono-processeur lorsqu'on fait communiquer une routine d'interruption avec le reste de l'application sont insuffisantes. Il ne suffit pas de protéger les séquences critiques par des cli() et sei(), ni de définir en "volatile" les variables partagées. Il faut un autre mécanisme, plus puissant.

L'ESP32 fournit ce mécanisme : il s'agit des "mutex". Enfoui dans le hardware des sytèmes multi-processeurs il y a une instruction spéciale, connue sous le nom de "test and set" dans la théorie, qui consiste en fait à tester et mettre à "1" une variable booléenne en un seul cycle du bus mémoire, pour assurer l'exclusivité entre processeurs qui partagent ce bus. Le mutex doit utiliser un tel mécanisme pour assurer l'exclusivité sur des séquences critiques. Quand je dis "doit", c'est une supposition, car un système multi-processeurs ne peut pas fonctionner autrement, mais je n'ai pas trouvé ce détail dans la doc de l'ESP32.

L'inconvénient est qu'on est obligé d'avoir une programmation spéciale pour l'ESP32 des séquences critiques, avec par exemple des compilations conditionnelles.