diff options
| author | goodhoko <[email protected]> | 2025-09-15 15:34:07 +0200 |
|---|---|---|
| committer | goodhoko <[email protected]> | 2025-09-16 09:47:23 +0200 |
| commit | 8ed1e796bad7b3dbf6e78ea5e5d89b7257571d06 (patch) | |
| tree | ec600c8b8fb91cbd5979ac13832851890c21dca7 /embassy-executor-timer-queue/Cargo.toml | |
| parent | fe95e338617d28116e38af6b8c5a5be37c6c24a0 (diff) | |
Handle OSPI address errors
We were using OSPI in indirect mode via DMA and noticed that the transfer future would never resolve. It was forever busy-looping in `finish_dma()` on the `while !regs.sr().read().tcf() {}` line.
After some debugging we noticed that the the `TEF` flag is set. The data sheet says the following about this flag:
> The following errors set the TEF flag in OCTOSPI_SR and generates an interrupt if enabled (TEIE = 1 in OCTOSPI_CR):
> - in indirect or automatic status-polling mode, when a wrong address has been programmed in OCTOSPI_AR (according to the device size defined by DEVSIZE[4:0]).
> - in indirect mode, if the address plus the data length exceed the device size: TEF is set as soon as the access is triggered.
Indeed we were configuring our device size to 0 while specifying a non-zero address.
Detect this condition and return an error early - as soon as we configure the registers (which, according to the data sheet, should be enough to raise the flag)
Also document this behavior on the respective TransferConfig and Config fields.
Testing
-------
See https://github.com/goodhoko/spi-error-test/blob/main/src/main.rs
Diffstat (limited to 'embassy-executor-timer-queue/Cargo.toml')
0 files changed, 0 insertions, 0 deletions
