Micropython 1.19.1 crashes on ESP32

[zachmoshe]

I'm running MicroPython v1.19.1 on a ESP32 board. Sometimes, after a soft-reset of the device, the device start running but immediately crashes with the following message. The second reboot succeeds. The device has an sdcard module (SPI), and I2S board connected. It uses the bluetooth (although I'm not sure if it kicks in before it shuts down). Other connections seem harmless (switches, leds, ...). The code will basically read WAV files from the sdcard and play through I2S.

The crash doesn't happen all the times, and I couldn't replicate exactly, but I suspect it has something to do with open filehandles. I'm basically deinit-ing SPI and I2S before shutting down, but if it seems related I can double check that there is no other exception flow that I'm missing.

The main problem is that I don't understand this message so have no idea where to look for solutions. Can anyone help understanding what's going on?

/home/micropython/esp-idf-v4.2/components/freertos/queue.c:1462 (xQueueGenericReceive)- assert failed!

abort() was called at PC 0x40097282 on core 1

Backtrace:0x40093b5e:0x3ffcc9c0 0x400942d5:0x3ffcc9e0 0x40097f26:0x3ffcca00 0x40097282:0x3ffcca70 0x400d5ca9:0x3ffccab0 0x400ea8d0:0x3ffccae0 0x400eab52:0x3ffccb10 0x400eac06:0x3ffccb30 0x400dbdd3:0x3ffccb50 0x400e2679:0x3ffccb80 0x400e27a9:0x3ffccba0 0x40084789:0x3ffccbc0 0x400dbd66:0x3ffccc60 0x400e2679:0x3ffccc90 0x400e27a9:0x3ffcccb0 0x40084789:0x3ffcccd0 0x400dbd66:0x3ffccd70 0x400e2679:0x3ffccda0 0x400846f6:0x3ffccdc0 0x400dbd66:0x3ffcce60 0x400e2679:0x3ffccec0 0x400e27a9:0x3ffccee0 0x40084789:0x3ffccf00 0x400dbd66:0x3ffccfa0 0x400e2679:0x3ffcd010 0x400e27a9:0x3ffcd030 0x40084789:0x3ffcd050 0x400dbd66:0x3ffcd0f0 0x400e2679:0x3ffcd120 0x400e27a9:0x3ffcd140 0x40084789:0x3ffcd160 0x400dbd66:0x3ffcd200 0x400e2679:0x3ffcd260 0x400e26a2:0x3ffcd280 0x400efbca:0x3ffcd2a0 0x400eff71:0x3ffcd330 0x400d4cea:0x3ffcd350


ELF file SHA256: 00495403985fb7e0

Rebooting...
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x17 (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:2
load:0x3fff0030,len:4540
ho 0 tail 12 room 4
load:0x40078000,len:12344
ho 0 tail 12 room 4
load:0x40080400,len:4124
entry 0x40080680

[chaseadam]

I am running into a similar issue which I can associate with specific .config() calls to a network.WLAN(network.STA_IF) object. Can you share your network connection code? Does it happen to include a sta_if.config(dhcp_hostname = host)?

[zachmoshe]

Intersting.. I don't use WiFi (or the network module) at all, but I do use Bluetooth, and I do set gap_name by bluetooth.BLE().config(gap_name="..."). Not sure if this has to do with the config. I'll try to disable the config and see if it persists.

[dpgeorge]

The device has an sdcard module (SPI),

There have been recent fixes to SD card and soft reset (eg #8949 an d108fc9c4793e1846b2ddfad925fb17bbc44cd51).

Please can you try your code with the latest unstable firmware?

[zachmoshe]

Yes, still happens.. (tested with esp32-20220926-unstable-v1.19.1-451-gbdbc44474.bin)

/home/micropython/esp-idf-v4.2/components/freertos/queue.c:1462 (xQueueGenericReceive)- assert failed!

abort() was called at PC 0x40097212 on core 1

Backtrace:0x40093aee:0x3ffcc9c0 0x40094265:0x3ffcc9e0 0x40097eb6:0x3ffcca00 0x40097212:0x3ffcca70 0x400d5c91:0x3ffccab0 0x400eac90:0x3ffccae0 0x400eaf12:0x3ffccb10 0x400eafc6:0x3ffccb30 0x400dbf1b:0x3ffccb50 0x400e2c6a:0x3ffccb80 0x400e2d99:0x3ffccba0 0x40084775:0x3ffccbc0 0x400dbeae:0x3ffccc60 0x400e2c6a:0x3ffccc90 0x400e2d99:0x3ffcccb0 0x40084775:0x3ffcccd0 0x400dbeae:0x3ffccd70 0x400e2c6a:0x3ffccda0 0x400846e2:0x3ffccdc0 0x400dbeae:0x3ffcce60 0x400e2c6a:0x3ffccec0 0x400e2d99:0x3ffccee0 0x40084775:0x3ffccf00 0x400dbeae:0x3ffccfa0 0x400e2c6a:0x3ffcd010 0x400e2d99:0x3ffcd030 0x40084775:0x3ffcd050 0x400dbeae:0x3ffcd0f0 0x400e2c6a:0x3ffcd120 0x400e2d99:0x3ffcd140 0x40084775:0x3ffcd160 0x400dbeae:0x3ffcd200 0x400e2c6a:0x3ffcd260 0x400e2c92:0x3ffcd280 0x400f06e2:0x3ffcd2a0 0x400f0a89:0x3ffcd330 0x400d4c8e:0x3ffcd350


ELF file SHA256: 00c1650b41669f66

Rebooting...
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x17 (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:2
load:0x3fff0030,len:4540
ho 0 tail 12 room 4
load:0x40078000,len:12344
ho 0 tail 12 room 4
load:0x40080400,len:4124
entry 0x40080680

[dpgeorge]

If you build the code yourself locally, you can use idf.py monitor like this:

$ idf.py -B build-GENERIC monitor

Then if it crashes during that session (it's a terminal session) it will show you the backtrace.

But I can actually decode the backtrace because you're using an official build. It is:

/home/micropython/esp-idf-v4.2/components/esp_system/panic.c:341
/home/micropython/esp-idf-v4.2/components/esp_system/system_api.c:106
/home/micropython/esp-idf-v4.2/components/newlib/abort.c:46
/home/micropython/esp-idf-v4.2/components/freertos/queue.c:1462 (discriminator 1)
/home/micropython/micropython-autobuild/ports/esp32/machine_i2s.c:809
/home/micropython/micropython-autobuild/extmod/moduselect.c:83
/home/micropython/micropython-autobuild/extmod/moduselect.c:248
/home/micropython/micropython-autobuild/extmod/moduselect.c:290
/home/micropython/micropython-autobuild/py/objfun.c:123
/home/micropython/micropython-autobuild/py/runtime.c:695
/home/micropython/micropython-autobuild/py/runtime.c:711
/home/micropython/micropython-autobuild/py/vm.c:1042
/home/micropython/micropython-autobuild/py/objfun.c:278
/home/micropython/micropython-autobuild/py/runtime.c:695
/home/micropython/micropython-autobuild/py/runtime.c:711
/home/micropython/micropython-autobuild/py/vm.c:1042
/home/micropython/micropython-autobuild/py/objfun.c:278
/home/micropython/micropython-autobuild/py/runtime.c:695
/home/micropython/micropython-autobuild/py/vm.c:957
/home/micropython/micropython-autobuild/py/objfun.c:278
/home/micropython/micropython-autobuild/py/runtime.c:695
/home/micropython/micropython-autobuild/py/runtime.c:711
/home/micropython/micropython-autobuild/py/vm.c:1042
/home/micropython/micropython-autobuild/py/objfun.c:278
/home/micropython/micropython-autobuild/py/runtime.c:695
/home/micropython/micropython-autobuild/py/runtime.c:711
/home/micropython/micropython-autobuild/py/vm.c:1042
/home/micropython/micropython-autobuild/py/objfun.c:278
/home/micropython/micropython-autobuild/py/runtime.c:695
/home/micropython/micropython-autobuild/py/runtime.c:711
/home/micropython/micropython-autobuild/py/vm.c:1042
/home/micropython/micropython-autobuild/py/objfun.c:278
/home/micropython/micropython-autobuild/py/runtime.c:695
/home/micropython/micropython-autobuild/py/runtime.c:669
/home/micropython/micropython-autobuild/shared/runtime/pyexec.c:120
/home/micropython/micropython-autobuild/shared/runtime/pyexec.c:683
/home/micropython/micropython-autobuild/ports/esp32/main.c:167

It's in main.py at boot. There are quite a few nested Python calls, and then it calls ipoll() on an I2S object. The I2S object crashes calling xQueueReceive(self->i2s_event_queue, &i2s_event, 0).

So it's something to do with I2S, most likely not being fully deinitialised on soft reset.

[zachmoshe]

Thanks! I wasn't aware of this tool. Definitely gives some hints.

I think I found the end-case where I don't deinit() the I2S. I'll see if it helps. I think we can close this for now and I'll reopen if it persists.

[robert-hh]

Better keep it open. If that is the reason, it must be fixed in the code to automagically deinit I2S on soft reboot.

[dpgeorge]

@zachmoshe please let us know if you fixed it by calling I2S.deinit(). If so then that can help us fix it properly.

[zachmoshe]

Seems like it helped. So far I haven't seen this happening again.

[dpgeorge]

Thanks for confirming. Should be fixed by 0ee877a20732039e603b41c63a221bfc2c8fbde9, which adds a finaliser to I2S.