Async SPI transaction with [write, read] operation broken on esp32

[plaes]

I have a driver that does spi.transaction with sequential write and read operations.

let write_buffer = [0; 1];
let mut read_buffer = [0xa; 4];
let mut ops = [Operation::Write(write_buffer), Operation::Read(read_buffer)];
spi.transaction(&mut ops).await?;

It seems that whenever the read_buffer is longer than one byte, it doesn't get updated with read data, ie with this code read_buffer still contains [0xa, 0xa, 0xa, 0xa] after transaction.

This is issue is present with 0.20.1 and current HEAD c5e342a

[Dominaezzz]

Thanks for the snippet, mind making it bigger? Is that with DMA? If so, how big are the buffers?
A full MVP would be appreciated then I'll be able to run it and see what's going on later this evening.

[plaes]

Thanks for the snippet, mind making it bigger? Is that with DMA? If so, how big are the buffers? A full MVP would be appreciated then I'll be able to run it and see what's going on later this evening.

Yes, with async fullduplex DMA with buffer length of 1024.
I'll see whether I can whip up something, as I was blocked by the xtensa-lx-rt issue.

edit: I can't seem to reproduce this with single device based HIL test though.

[plaes]

@Dominaezzz I managed to find some kind of "anomaly":

    let write_buf = &[0xaa];
    let mut read: [u8; 2] = [0xff; 2];
    let mut ops = [Operation::Write(write_buf), Operation::Read(&mut read)];
    let _ = spi_dev.transaction(&mut ops).await;
    defmt::info!("Test 1... result: {:?}", read);
    // why do we get 0xff, 0xff here?
    assert_eq!(read, [0xff, 0xff]);


    let write_buf = &[0xaa];
    let mut read: [u8; 1] = [0xffu8; 1];
    let mut ops = [Operation::Write(write_buf), Operation::Read(&mut read)];
    let _ = spi_dev.transaction(&mut ops).await;
    defmt::info!("Test 2... result: {:?}", read);
    // ... but 0x00 here?
    assert_eq!(read, [0xff]);

Self contained test-case can be found from here: https://github.com/plaes/rust-lilygo-ttgo-lora32/blob/c79b7f0cb16310beaee593b894472bdf5e45adb0/src/spi_dma_transaction.rs#L79-L93

[Dominaezzz]

Try changing let mut read: [u8; 2] = [0xff; 2]; to let mut read: [u8; 2] = [0xab; 2];.

I'm curious to see if the driver isn't writing anything to the buffer at all or if it's write 1s (from a pull up or something).

[plaes]

Well, no pullup issue:

[INFO] - Test 1... result: [171, 171]
[INFO] - Test 2... result: [0]
[INFO] - Test 1... result: [171, 171]

[Dominaezzz]

Does the same happen for blocking mode?

[plaes]

Does the same happen for blocking mode?

I haven't yet figured out blocking + DMA + transaction, but blocking + transaction gives following output:

[INFO] - Test 1... result: [0, 0]
[INFO] - Test 2... result: [0]
[INFO] - Test 3... result: [0, 0]

[Dominaezzz]

I've been able to reproduce it. (Without your full example I wouldn't have been able to, it only comes out in particular circumstances it seems)

[Dominaezzz]

Basically, it seems once a write happens, reads stop working correctly. Only one byte is read.

Happens in both blocking and async mode at least, and it seems the peripheral itself just won't return more data to the DMA.

transfer also doesn't work correctly after a write is done

With a larger buffer to read, the read works as expected until the last 8 bytes....

I'm able to reproduce this with older commits, I can reproduce it before the DMA Move Api PR at least 😅 .
Even before #1894 landed, I can still reproduce this issue. I fear this may have always been broken...

transfer then read is fine, but write then read is not.... hhmmm

[Dominaezzz]

It appears to be a silicon bug in the base ESP32.
espressif/esp-idf@366e439
(An ESP32 #ifdef was added later. espressif/esp-idf@0c3653b)

This stuff should really go in the errata.

Looks like the ESP32 will need special logic in the SPI driver.... 😞

[Dominaezzz]

To reproduce, take the embassy_spi example and change it from transfer to write + read.

[bjoernQ]

I also see problems on ESP32-S2: there a write and read only succeeds once - then it fails