Closed manuelbaez closed 7 months ago
I can't see what esp-hal version your using, but ensure it includes https://github.com/esp-rs/esp-hal/pull/1286 if you're using the second core at all. For the original ESP32, you will also want to have https://github.com/esp-rs/esp-hal/pull/1289 included.
Hey, thanks for your answer! I pulled again from main and it seems to have fixed the issue, also it fixed the I2c frequency that was way off before. The I2c still crashes with AckCheckFailed when used in the second core and the SCL line locks forever, though for my use case, I can just run that task in core 0 as it works fine. I think I'll open an issue in the esp-hal about this later.
This is what I meant about the SCL line:
Hi, first I'd like to thank anyone who takes the time to read this, sorry about misspellings and any weird things I'm new to Rust and English is my second language :)
I'm trying to make a flight controller with an esp32 using embassy, I started with the esp idf std template but decided to move to no_std out of curiosity and maybe to get more performance and a lighter binary for the app.
I have my application sectioned into three main tasks at the moment:
I can run those three tasks just fine if I use only one core, but that introduces some unwanted spikes in the latency for the flight controller and I want it to be as performant as possible, so that's why I want to use the second core exclusively for that. But I'm facing the following issue when trying to use the second core for any of the tasks and also spawn the flight_controller simultaneously:
Exception occured 'LoadProhibited' Context PC=0x400dc1b8 PS=0x00060930 0x400dc1b8 - embassy_executor::raw::util::SyncUnsafeCell<T>::get at /mnt/disk-2/repos/embassy/embassy-executor/src/raw/util.rs:55 0x00060930 - ?? at ??:??
This only occurs when I try to spawn any of the tasks in the second core, it runs just fine when everything is in just one. At first, I thought it was the way I was sharing the user input data between the tasks, I'm using a struct of atomic values:
So I removed that to test and the executor, where the flight controller is, kept crashing (also I use relaxed ordering, not sure if that's important), so I started to comment code to see at what point it crashes, and I found out it was crashing on an async function that used the I2C but interestingly when I made the function sync it stopped crashing at that point, but when I added some code back it started crashing again.
Then I saw in the docs about the task arena and I enabled the nightly feature, this Increased the amount of my code that I could put back into the function but still crashed at some point on some random arithmetic function, nothing that should cause problems. This is why I think this has something to do with the size of the task( call stack? or Future) since it seems to be trying to access memory out of bounds for the executor.
I decided to clone the embassy repo and tracked down the crash to this function call:
This is line 405 of the src/raw/mod.rs in the embassy-executor, but I'm at a loss here since I'm quite new to rust(I picked this project to start learning it) and I don't understand much of what's going on here, but I guess that wherever that poll_fn is getting assigned for that task it's assigning it a pointer that leads to some wrong memory address.
Important to note, This only happens in a release build, somehow debug builds are fine but the code runs 20 to 30x slower so that might be something worth mentioning, no idea why though.
This is the function that crashes in the executor.
Here is the full app code that's crashing.
This is what my main looks like when spawning to the second core:
This is the full console output when the app crashes:
Again thanks in advance for your time and any comments!