-
Notifications
You must be signed in to change notification settings - Fork 863
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Guru Meditation Error: Core 0 panic'ed (LoadProhibited) #872
Comments
In the meantime I've seen that the AT log port contains an unhandled exception |
@mdeloof Hi, could you please enable AT logs for us to see what happened, we will try to reproduce that.
in the compile steps, you can choose |
Hi, I have enabled the AT logs and rerun the tests, and it appears that the extra logs significantly lower the data rate. So far we have not seen the
Here you can find the full AT log: esp-at-sdio-task-watchdog-log.log |
Answers checklist
AT+GMR
ESP-AT Firmware Source
Cloned from GitHub
Hardware Information
ESP32-WROOM-32E on custom PCB communicating to STM32F746 over SDIO
Power Supply used
External 3.3V
What is the expected behavior?
We're using the ESP32 in SoftAP mode as well as passthrough mode to stream data over wifi to a single client. Communication between our microcontroller (STM32F746) and the ESP32 happens over the SDIO bus. Before sending data to the ESP32 we read out the
rtoken_data
register to know how many buffers are available to be written. When there are no buffers available we keep reading thisrtoken_data
until new buffers are available. In ideal conditions we've been able to consistently stream at ~400KB/s for multiple hours.What is the actual behavior?
We have observed that if the ESP32 is not able to push out data fast enough over wifi to the connected client (be it due to a poor connection or an arbitrary delay introduced in the receiving code) the ESP32 stops responding to our SDIO command to read
rtoken_rdata
and we have not found a way to recover from this.Here is the full trace that was captured with Logic 2
Probability of recurrence
We can reliably reproduce this behavior by introducing a small delay between each TCP
recv
on the connected client.AT+SYSRAM?
We're not able to execute this command when the bug occurs.
Steps to reproduce
Configure ESP32 in SoftAP mode, start listening on TCP port, wait for incoming connection, enable passthrough mode, start sending data from microcontroller to ESP32 over SDIO, on the client side perform
recv
operations with a small delay inbetween.AT command port output
AT log port output
More Information.
We've had to change the configuration of the SDIO timings on the ESP32 to make it clock the SDIO bus on the correct edge.
// init sdio slave configuration sdio_slave_config_t config = { .sending_mode = SDIO_SLAVE_SEND_STREAM, .send_queue_size = CONFIG_AT_SDIO_QUEUE_SIZE, .recv_buffer_size = CONFIG_AT_SDIO_BLOCK_SIZE, + .timing = SDIO_SLAVE_TIMING_NSEND_PSAMPLE };
The text was updated successfully, but these errors were encountered: