STM32 那个 SDSPI 的 demo 是对应 ESP32 使用 SDIO AT 的。
对于 C3 SPI 来说，我们没有提供 STM32 的 master 示例，只是提供了 ESP 作为 master 的示例（https://github.com/espressif/esp-at/tree/master/examples/at_spi_master/spi/esp32_c_series），对于 STM32 来说，你需要自己开发， 可以参考我们的协议文档（https://docs.espressif.com/projects/esp-at/zh_CN/latest/esp32c3 ...

20M 的理论最大速率也就是 10 +Mbps，而不是 10MB，这涉及 BYTE 和 BIT 的区别。
以下是我们使用 SDSPI 使用 20M 和 40M 在 Kingston UHS-1 128GB 卡上，使用 FAT32 文件系统读取一个 1MB 文件的速率表：
20 MHz, 4kB read block size: 754.835ms (10.598Mib/s)
20 MHz, 32kB read block size: 643.622ms (12.430Mib/s)
40 MHz, 4kB read block size: 541.091ms (14.785Mib/s)
40 ...

OK，那问题基本上就找到了，跟light sleep没关系，如果我没猜测的话，你们这个局域网段存在一个 192.168.11.xx 的路由器，可能这个路由器是作为 LAN口连到主路由器的，或者它作为更上级的路由器。
这个问题原因在于我们在某一次DHCP request的时候没有收到回复，因此我们重新发送了 DHCP discover报文，但是这个 192.168.11.xx 的路由器DHCP server给我们分配了IP，所以你才会看到这种情况。
你可以试着把网段内这个路由器的 DHCP server给关掉，试试还会不会有这个问题

我发现 SPI 驱动的工程师已经在 github 上推送了一个 fix 方案 （https://github.com/espressif/esp-idf/co ... 05f7290a1f），请问问题目前还存在吗

你想调节成 10000，我估计你是想实现 us 级的延时或者定时，这块建议你使用 ets_delay_us 和 esp_timer。
至于为什么不能调节，这部分涉及到 system tick 的实现，最小只能到1000，也就是 1ms，而且这个时间也不会精确，不建议做精确时间

你下载的固件有问题，你可以把OTA区域的固件通过esptool读出来（https://docs.espressif.com/projects/esp ... read-flash），和原始ota固件对比

从LOG看，似乎是 DHCP 的流程太长了，最好能够抓个WiFi的包看看这时候发生了什么，抓包如果用MAC可以直接抓（https://zhuanlan.zhihu.com/p/498119076?utm_id=0），如果ubuntu 或者windows，则需要专门的抓包卡才可以

应该不冲突的，你在采集的时候，如何使用其他GPIO的。
你那个 abort 下面的 backtrace 看看是 IDF 哪些函数（需要配置项使能 ESP_SYSTEM_USE_EH_FRAME，然后使用 idf.py monitor会直接显示，如果没有的话，请使用 riscv32-esp-elf-addr2line去查）

你可以在IDF搜一下这个warning是哪里打印的，是什么条件没有满足。

一个 gatt_client demo ，一个 gatt_server demo