esp32s3: System freeze when interrupt is triggered after WiFi enabled

[Yanok35]

Describe the bug

Using the wifi_shell application sample enhanced by a basic button interrupt handler (source code attached), it is observed the Wifi activation can break the interrupt handler in app.

Application freeze after WiFi has started and interrupt handler is triggered.

This has been reproduced on 4.0.0 tag release and also on "main" branch as of today when those lines are written ( 2cea407 ).

Environment

1. Apply the patch ( 0001-sample-combine-wifi-shell-and-basic-button-apps.patch ) to enhance wifi_shell app with button interrupt handler.

2. Build & Flash the sample app on the DevkitC:

   west build -b esp32s3_devkitc/esp32s3/procpu
   west flash
   

To Reproduce

Steps to reproduce the behavior:

1. Press Boot0 button and observed the handler is working correctly with its logs visible in console
2. Activate Wifi stack using "wifi scan" operation for example,
3. Press Boot0 button again

Issue

• Shell become unresponsive (app freeze) when button BOOT0 is pressed after the wifi scan.
  Note: this has been reproduced using other gpio than gpio0 and BOOT0 button (at least: gpio0, gpio3, gpio5),
  This can also be reproduced using "wifi connect" operation and is not related to scan itself.

Expected behavior

• wifi activation should not break interrupts handlers.
• Gpio interrupt handler is called, and "Button pressed at " log is displayed

Impact

• The overall system become unusable after Wifi started & interrupt handler is trigged.

Logs and console output

uart:~$
 <---- User press "BOOT0" button on DevKit ---->
Button pressed at 2733555169
uart:~$ wifi scan
Num  | SSID                             (len) | Chan (Band)   | RSSI | Security        | BSSID             | MFP
1    | midea_c3_0187                    13    | 1    (2.4GHz) | -61  | WPA2-PSK        | 80:76:C2:XX:XX:XX | Disable
 < -- snip -- >
Scan request done
uart:~$
 <---- User press "BOOT0" button on DevKit ---->
uart:~$

[github-actions]

Hi @Yanok35! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[sylvioalves]

@Yanok35 We have already fixed. Will submmit soon. Thanks for reporting.
In case you want to test it prior being merged, you can check zephyrproject-rtos/hal_espressif#383

[Yanok35]

Hi @sylvioalves .
Thanks for your feedback.

We slightly adapt the fix you mentioned in zephyrproject-rtos/hal_espressif#383 to match the "esp32s3" SoC using this : https://gist.github.com/Yanok35/96add12bd4d311aa4015b93cf257211a

We checked on esp32s3 devkitC1. Whereas this seems to fix the behavior for "wifi scan", this unfortunately does not for "wifi connect -s [ap] -p [psk] -k 1" command.
After entering the 'connect' sequence, the UART console become unresponsive (app freeze).

(reproduced on v4.0.0 & main top branch).

[sylvioalves]

I think you missed applying the full change. You have got to add both lines as in the below:

	esp_intr_alloc(0, 0, f, arg, NULL);
	esp_intr_alloc(2, 0, f, arg, NULL);

Can you give it a check?

[Yanok35]

Sorry, we have been confused with the "review" display of Github and missed a part of your initial patchset.

We have just retried with the both lines and confirmed this is now Ok for "wifi scan" and "wifi connect" on the DevkitC1.
Thanks you very much!

[EricNRS]

@sylvioalves - could you explain the issue and fix a bit more? Any chance this is related to the nested interrupt issue I was seeing on v3.5 that involved the CAN interrupt?

[sylvioalves]

@sylvioalves - could you explain the issue and fix a bit more? Any chance this is related to the nested interrupt issue I was seeing on v3.5 that involved the CAN interrupt?

Sounds it could indeed be related, I guess only testing to make sure. It seems a new issue though.
Wi-Fi adapter was (is) setting its ISR directly bypassing the interrupt allocator call. It means that the same isr slot mapping could be set for Wi-Fi+Peripheral, causing this issue. I'll bisect it to find when it started to happen as it was not before. Anyway, this is a good fix and I shall backport it accordingly.