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

虽然超过120字节就会跑一次事件，但实际上你可以不使用 uart_read_bytes 去读取，这时候数据会缓存到 receive buffer 里面，等后面再触发事件后一起读取。
不过这里更建议在应用层封装一定的数据格式，这样你即使收到第一包数据，解析下来看到还有数据，也可以继续等待，等全部收到之后再集中处理

有看过 idf example/protocols/modbus/serial 的demo吗？这个里面包括了 master 与 slave 的串口通信