Closed 4eetah closed 7 years ago
That's strange. It looks like the driver is failing to load the firmware, then causing the driver to fall over after the ESP shows up in a consecutive bus probe.
Since it looks like you're using GPIO0 for the reset which doubles as SDA0 of the I2C0 bus. Is there anything in Yocto that tries to touch I2C0? I suggest GPIO0 since it is conveniently toggled when doing the hat probe when bootloading Linux on the Pi and never touched again once Linux starts. But if something in Yocto tries to probe or otherwise talk on that I2C bus then the ESP could be reset at an inconvenient time.
Is it possible to route the ESP reset to another GPIO instead to test this theory?
Thanks for the response, I resolved this one by disabling the loading of rpi tft overlay in raspberry boot config. The thing is that even though the wlan interface shows up, for some reason it still doesn't work properly on yocto, that is I am unable to associate to my access point and obtain a dhcp address while the same wpa_supplicant/interface settings work out just fine on raspbian system.
Could networkmanager be getting in the way of the interface? Does "iwlist scan" work on the interface?
There are no network manager and iwlist scan works fine. I've created a hostapd access point and captured some debug info from AP. It seems to constantly authenticates to my AP and also printing this sort of line which looks suspicious: Ignore Probe Request due to DS Params mismatch: chan=1 != ds.chan=3 Could you please take a glance on it or point me what can it be. (18:fe:34:d9:8a:6f is the esp interface mac address) Thanks! debug_hostapd.txt
While having driver work on raspbian (raspberry pi cm3) with 4.9.31(be4248369e9122f07240d83f803bc7add54508c5) I am having troubles loading the driver(sdio) with the same kernel/firmware with yocto build. Please find the debug log attached. esp_log_yocto_linux4.9.31.txt