ESP32 Forum

Hey guys

Before anyone asks "Yes i have searched for a fix" unfortunately I'm quite new to C++/Arduino and a fair few of the details in the other posts confuse me.

so my issue is, i have an ESP32 (TTGO Lora32) I'm using the default SPI for the lora and the flash. I've disabled the on-board display and i have reconfigured the "Hardware Serial(1)" to use pins 34 and 35 for a neo 6m receiver and i have MPU9250 on i2c bus pins 21 and 13. the device is taking position and mpu readings and sending them out to a lora mesh and also over BT to an android app. The GPS and the MPU9250 reads/workload where associated with core1 task and the lora and other work happened on core0. (when i started having issues i moved all the code back to core0)

In my first attempt i had no software interrupts or callbacks and the device would run indefinitely. However recently we went through an optimization and placed a lora receive callback in the code. then it randomly started doing this:

Guru Meditation Error: Core 1 panic'ed (Interrupt wdt timeout on CPU1)
Core 1 register dump:
PC : 0x4008c9e6 PS : 0x00060634 A0 : 0x8008bba6 A1 : 0x3ffc0a70
A2 : 0x3ffcd28c A3 : 0x3ffd2698 A4 : 0x00060621 A5 : 0x00000001
A6 : 0x00060621 A7 : 0x00060523 A8 : 0x3ffd2698 A9 : 0x3ffd2698
A10 : 0x00000018 A11 : 0x00000018 A12 : 0x00000000 A13 : 0x00000001
A14 : 0x00060623 A15 : 0x00000000 SAR : 0x00000010 EXCCAUSE: 0x00000006
EXCVADDR: 0x00000000 LBEG : 0x4000142d LEND : 0x4000143a LCOUNT : 0xfffffffd
Core 1 was running in ISR context:
EPC1 : 0x4008b263 EPC2 : 0x00000000 EPC3 : 0x00000000 EPC4 : 0x4008c9e6

Backtrace: 0x4008c9e6:0x3ffc0a70 0x4008bba3:0x3ffc0a90 0x4008a9bf:0x3ffc0ab0 0x400d677d:0x3ffc0af0 0x400d6bdd:0x3ffc0b10 0x40178331:0x3ffc0b30 0x400d6d76:0x3ffc0b50 0x400d3426:0x3ffc0b70 0x400d3a68:0x3ffc0bb0 0x400d3a7e:0x3ffc0bd0 0x40080ead:0x3ffc0bf0 0x400816cd:0x3ffc0c10 0x400d679d:0x00000000

Core 0 register dump:
PC : 0x4008b280 PS : 0x00060034 A0 : 0x8008b88b A1 : 0x3ffc05a0
A2 : 0x3ffc1170 A3 : 0x00000000 A4 : 0x00000005 A5 : 0x00000020
A6 : 0x00000020 A7 : 0x00000001 A8 : 0x0000abab A9 : 0x0000cdcd
A10 : 0xb33fffff A11 : 0x0000abab A12 : 0x00060021 A13 : 0x00000001
A14 : 0x00060021 A15 : 0x00060923 SAR : 0x0000001a EXCCAUSE: 0x00000006
EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000

Backtrace: 0x4008b280:0x3ffc05a0 0x4008b888:0x3ffc05c0 0x4008c747:0x3ffc05e0 0x4008c461:0x3ffc0600 0x400816d6:0x3ffc0610 0x401537ef:0x00000000

I have tried to install the ESP8266/ESP32 exception debugger in the Ard IDE but its not working
i beleive it is the callback causing the crash as the code has all been copied over from the original sketch's, the only fundamental difference is the call back:LoRa.onReceive(onReceive); instead of reading every time the device cycles. like in the example given with the lora send / receive examples.

Is it possible that the call back is being called multiple times, should i be taking the device out of receive mode when responding to the call back so it doesnt call again perhaps ?

Also if anyone knows of any boards with this type of configuration please feel free to suggest, i dont want to have to have this manufactured if i can help it

Moving this to the Arduino subforum as it seems mostly Arduino related.

https://github.com/Heltec-Aaron-Lee/WiF ... /issues/39

Onreceive is called in interrupt context from a function that is doing a bunch of stuff that also should not be in interrupt context.

Sorry im a noob to this, i felt whats happening on core 1 wouldn't be effected by work on core 0

any suggestions for a work around ?

In ISR function you can do only simple, no time consuming operations. Usually its operation on queue or setting group flag or just changing boolean variable value. Then in main loop you can have if(variable) then do whatever you are doing now in ISR function and what is causing crash.

Ok i set the callback to mark "Received = true" and then the main loop checks if received is true and cycles accordingly.

I will data log it over night and see what happens FYI its twice as bad when the BT is enabled. Just an observation i data logged 3 units and even the ones with out a BT client crashed. they just didnt do it as often.

I appreciate the feedback,

Well that worked, atleast it worked for excess of 6 hours. i set it when i went to bed that the call back only toggle received = true then in the main loop it checks if(received){onReceive(int)} and it appears to be working. thanks for the help.... well i hope its fixed i disabled the GPS and MPU for the tests so lets see what happens when i re-enable