Closed tomkcook closed 7 years ago
I might misremember this, but I think I had the same/similar issue, when I accidentally had the ESP's reset pin already used for some other peripheral.
It could also be the internal pulldown for CH_PD not being sufficient. I've run across a number of ESP-12F modules where it wouldn't come out of reset or would initialize but flake out in the manner you described unless I put a 10k pulldown on CH_PD.
Hey, thanks for getting back to me so quickly. It does look like something of that sort -it usually crashes but sometimes it'll just fail with "no such device" and sometimes it fails to initialise in some other way.
If the pull-down on CH_PD is not enough, do you ever need pull-downs on the other pins? I've got 33 ohm resistors in line with them, but should i have a pull-down on each sdio pin as well?
A few things to report back:
Any pointers on debugging this would be greatly appreciated!
(slightly) more information: the kernel crash is not happening in esp_sdio_probe
but elsewhere as a result of a failure in that function. esp_sdio_probe
is failing because the call to esp_download_fw
in esp_pub_init_all
is returning -84
. AFAICT, this value comes out of the MMC driver, being the return value of mmc_io_rw_extended
.
False alarm, folks: A badly-soldered resistor on the D3 line.
Glad to hear you have it working now!
When I get some time, I'll look into why this causes a kernel crash; it should handle it cleanly. That should about 2025 some time...
I've got this building for an old-type raspberry pi zero, but when the module loads, it dies with a null pointer dereference somewhere in
esp_sdio_init
. I've got kgdb connected to the target, but it's rather difficult setting a breakpoint in that function as it's not possible to know its address until the module is loaded... when it's too late.Do you have any tips for debugging this? Things I can think of that might help:
Thanks for any help.