Open xiaoyaoweizi opened 3 years ago
Hi @xiaoyaoweizi, If you want to load SDIO driver even after Linux host restart, then you can configure it as a service using supverisor , for help.
Thank you for your reply.I know what you mean. But my question is not that. If the esp32 always run normally and Linux host restart abnormally , I retype execute this command insmod esp32_sdio.ko
,The driver reported an erroresp_sdio: probe of mmc0:0001:1 failed with error -110
. It seem Linux host load SDIO error. So how to rescan SDIO on the Linux host driver?
Hi @xiaoyaoweizi , Meanwhile I am looking into your issue, can you tell me why cant you run rpi_init.sh
directly instead of executing each and every commands?
Hi @xiaoyaoweizi , This esp_sdio: probe of mmc0:0001:1 failed with error -110
error print even I also get while executing rpi_init.sh
script but it doesn't affect the probing of esp32_sdio
module. Below is my dmesg log while executing rpi_init.sh
script.
[ 97.346716] Bluetooth: Core ver 2.22
[ 97.346807] NET: Registered protocol family 31
[ 97.346813] Bluetooth: HCI device and connection manager initialized
[ 97.346832] Bluetooth: HCI socket layer initialized
[ 97.346842] Bluetooth: L2CAP socket layer initialized
[ 97.346860] Bluetooth: SCO socket layer initialized
[ 117.907172] esp32_sdio: loading out-of-tree module taints kernel.
[ 117.908271] ESP32: Resetpin of Host is 6
[ 117.908392] ESP32: Triggering ESP reset.
[ 117.908773] esp_sdio: probe of mmc1:0001:1 failed with error -110
[ 117.908842] esp_sdio: probe of mmc1:0001:2 failed with error -110
[ 118.554298] mmc1: card 0001 removed
[ 119.887498] mmc1: queuing unknown CIS tuple 0x01 (3 bytes)
[ 119.895972] mmc1: queuing unknown CIS tuple 0x1a (5 bytes)
[ 119.899340] mmc1: queuing unknown CIS tuple 0x1b (8 bytes)
[ 119.902340] mmc1: queuing unknown CIS tuple 0x80 (1 bytes)
[ 119.902480] mmc1: queuing unknown CIS tuple 0x81 (1 bytes)
[ 119.902622] mmc1: queuing unknown CIS tuple 0x82 (1 bytes)
[ 119.906528] mmc1: queuing unknown CIS tuple 0x80 (1 bytes)
[ 119.906670] mmc1: queuing unknown CIS tuple 0x81 (1 bytes)
[ 119.906810] mmc1: queuing unknown CIS tuple 0x82 (1 bytes)
[ 119.907089] mmc1: new SDIO card at address 0001
[ 119.907636] esp_probe: ESP network device detected
[ 120.135783] Features supported are:
[ 120.135805] * WLAN
[ 120.135816] * BT/BLE
[ 120.135827] - HCI over SDIO
[ 120.135838] - BT/BLE dual mode
[ 120.354297] esp_sdio: probe of mmc1:0001:2 failed with error -22
[ 120.421364] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 120.421377] Bluetooth: BNEP filters: protocol multicast
[ 120.421392] Bluetooth: BNEP socket layer initialized
It provides expected functionality of esp-hosted firmware
Hi @xiaoyaoweizi , are you still blocked on this issue? It will be very useful if you can provide any update.
Hi @ajita02, sorry for late to reply. My SDIO host is hisi3516 based on the Linux system. I configure and load SDIO driver in the /etc/init.d/rcS file. the conmand is insmod esp32_sdio.ko
.
When you don't let esp32 connect to AP, you are right. It can reload SDIO driver successfully. However, once the connection of esp32 to AP is successful, reloading SDIO driver will cause the crash of esp32.
Firstly,I load SDIO driver successfully and configure esp32 to connect AP successfully. Then I restart Linux system and reload SDIO dirver. It will cause the esp32 to crash and I use xtensa-esp32-elf-addr2line tool to check.
root@zhuyun7:/home/zy/esp/esp-hosted/esp/esp_driver/network_adapter# xtensa-esp32-elf-addr2line -pfiaC -e build/kaa_main.elf 0x4017d2ff:0x3ffbf5e0 0x40102d14:0x3ffbf600 0x40102d38:0x3ffbf630 0x4017cae7:0x3ffbf650 0x4017cb21:0x3ffbf680 0x4008541e:0x3ffbf6a0 0x401a7997:0x3ffbaf50 0x400d21bf:0x3ffbaf70 0x4009b7bd:0x3ffbaf90 0x4009cf89:0x3ffbafb0 0x4017d2ff: sdio_slave_recv_load_buf at /home/zy/esp/v4.1/esp-idf/components/driver/sdio_slave.c:682 0x40102d14: sdio_reset at /home/zy/esp/esp-hosted/esp/esp_driver/network_adapter/main/sdio_slave_api.c:264 0x40102d38: event_cb at /home/zy/esp/esp-hosted/esp/esp_driver/network_adapter/main/sdio_slave_api.c:72 0x4017cae7: sdio_intr_host at /home/zy/esp/v4.1/esp-idf/components/driver/sdio_slave.c:449 (discriminator 1) 0x4017cb21: sdio_intr at /home/zy/esp/v4.1/esp-idf/components/driver/sdio_slave.c:436 0x4008541e: _xt_lowint1 at /home/zy/esp/v4.1/esp-idf/components/freertos/xtensa/xtensa_vectors.S:1105 0x401a7997: esp_pm_impl_waiti at /home/zy/esp/v4.1/esp-idf/components/esp32/pm_esp32.c:484 0x400d21bf: esp_vApplicationIdleHook at /home/zy/esp/v4.1/esp-idf/components/esp_common/src/freertos_hooks.c:63 0x4009b7bd: prvIdleTask at /home/zy/esp/v4.1/esp-idf/components/freertos/tasks.c:3385 (discriminator 1) 0x4009cf89: vPortTaskWrapper at /home/zy/esp/v4.1/esp-idf/components/freertos/xtensa/port.c:143.
The crash address is in esp32 sdio driver. My esp32 version is 4.1.
Hi @xiaoyaoweizi , can you tell your esp-idf repo commit ID on release/v4.0? so that I can check issue at my end.
Hi @ajita02 ,my esp-idf repo commit ID is e599b794bebebe66c6bb6d0af31a9451510ad3d4
on release/v4.1
Hi @ajita02 ,today, I've tested it many times, and found that after esp32 connecting to AP and the Linux host acquiring IP, The Linux host (hisi3516) restart system and reload SDIO driver, the esp32 will crash and the error in interface sdio_slave_recv_load_buf()
.In the case, I wonder if network data communication causes SDIO's read-write queue to report an error?
Hi @xiaoyaoweizi , We are using and recommending release/v4.0 for SDIO transport. My esp-idf release/v4.0 commit ID is 41efdb0b34864d434ce144e8530a4a78dfd7cd9f. I dont see above mention crash at my end. Steps which I had followed,
Now I use SDIO driver to communicate the connection between Linux and esp32。The normal situation is that esp32 starts first and Linux host starts again, which can work normally. And my problem is when Linux host or esp32 restart abnormally,Linux host can't reload SDIO driver and can't work again. I do not how to handle the exception? Can Linux host reload SDIO driver?