feat(xtensa): add support for esp32s3 with xtensa arch #399
Conversation
| // The xtensa-lx-rt does this when calling the exception handler using | ||
| // call4, which shifts the window by 4. | ||
| // See `xtensa_lx_rt::exception::asm::__default_naked_exception`. | ||
| // (At least that's what I assume is happening) |
There was a problem hiding this comment.
| // (At least that's what I assume is happening) |
|
@elenaf9 do you mind rebasing this? |
Move `waiti` out of `THREADS` closure. The esp-hal implementation of critical-section doesn't disable all interrupts. So another interrupt handler could run while we waiti, and cause a panic if it tries to borrow `THREADS`.
| // The esp-hal implementation of critical-section doesn't disable all interrupts. | ||
| // Thus we should release our hold on `THREADS` before we `waiti`, to prevent | ||
| // that another interrupt handler will try to borrow it while we still have it borrowed. | ||
| unsafe { core::arch::asm!("waiti 0") }; |
There was a problem hiding this comment.
It can still happen right now that an esp_hal::embassy interrupt interrupts a running thread that is currently accessing THREADS. If that interrupt is then also accessing THREADS (e.g. because it's a _pender), it panics.
We could instead disabled all interrupts when accessing THREADS on xtensa. esp-hal originally disabled all interrupts in their critical section, but changed it to only disable interrupts with prio <=5 so that the debugging at interrupt level 6 still works (see esp-rs/esp-hal#360).
So if we'd change it, debugging wouldn't work inside critical sections anymore I think.
The closures for accessing THREADS are very short, so I don't know.
Either way the waiti here still would need to be outside of the closure, because IIUC it only returns if an interrupt at the currently enabled level occurs. If all interrupts are disabled, it will never return.
Description
xtensaarch inriot-rs-threadsesp32s3chip inriot-rs-embassy(cc @ROMemories given that these are minimal changes, I don't think there will be many merge conflicts with refactor(embassy)!: extractarchmodules as crates #392. I'll rebase once that PR is in)espressif-esp32-s3-wroom-1boardlaze-project.ymlbased on prio work from @kaspar030.Testing
Rust on xtensa requires the installation of the esp toolchain and setting up the environment correctly. See the Rust on ESP Book. It can then be run as usual with
Issues/PRs references
Fixes #359.
Open TODOs
There are still linker issues that have to be fixed. Right now I simply worked around them by commenting out the conflicting parts, and somehow it worked. See self-review.
Change checklist