SPI Read on ESP32 shifting bits

[mr-sven]

On receving data the SPI buffer is read to early. I've connected a device via SPI3 and I read the following data, the 8th bit is always in the next byte

Read:   21 7f 81 01 0f 350f 4000 05 18 88
Should: 21 ff 01 01 0f 350f 4000 05 98 08

It looks for me the buffer is read before the 8th bit is shifted into. If I run a C app on the same device with I think same SPI setup, everything is fine.
I'm using esp-idf-hal 0.40.1
The Logicanalyzer is correct, so on buslevel it is valid

[mr-sven]

I've looked on the analyzer in detail and I've seen the SCK Low time it to short. Low is 41.67 ns and high is 83.33 ns. The SPI Device requires min 50 ns low/high.
I found the following https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/spi_master.html#_CPPv4N29spi_device_interface_config_t14input_delay_nsE
Is it possible to ajust this value from Rust? Maybe that helps.

[Vollbrecht]

I have to check but my clk output is symmetric in respect to low high/speeds. So you are using the SPI at 8Mhz clk speed in your config correct? Furthermore please still try to do the thing i described in the other issue. Its not a problem of an ChipSelect but you have to understand, as i stated, that the problem is fixed for the SpiSoftCsDeviceDriver. So you can check it if its really the issue here. Regarding your question about the possible delay, i think if you dont use it in your c code this is not a problem. In your C solution do you also write an continuous clkout to your connected device or are you writing in chunks? Can you share what type of device you are talking to?

[mr-sven]

I connected a SX1231H, and yes, CS is not the problem. I checked out the esp-idf-hal and screwed up the input_delay_ns in the spi.rs to 50 ns, now the data is looking good.
Here you can see the detailed SCK timing, maybe it's a bug in the ESP itself.

I scanned also the C program and the SPI Transfer is much slower, there is a 2 µs delay between each byte, so the issue is not a problem there.
I've added the input_delay_ns to the Config struct so I can setup it from external. I can create a Pull for this.

[Vollbrecht]

you probably writing each byte individual in you c code. what we do here in the rust code by default writing up to 64bytes continuous, without a gap. as you can see without further adjustment this can cause sometimes problems on the receiving end. if the input_delay_ns works for you it sounds good. otherwise i also made a PR that crates an chunked version of the data similar how the data is send in your c code to mitigate the problem on devices that are sensitive to the length of an transmission. you can check it here : #168

[mr-sven]

Oh yes, maybe the chunked version is also working. I will check that.

[Vollbrecht]

what chip mode of transmission are you using? single / burst / fifo access

[mr-sven]

I'm reading the fifo buffer so FIFO is used. The chunked mode is working, but is it possible to reduce the gap between the chunks?
I've done more analyses on the ESP and the device. The RF module needs 41.67 ns or 83.34 ns to setup the new data at SPI between bytes. Looks like a strange behavior of the device.
Continuous transfer:

• At 4 MHz the high and low are similar at 125 ns
• At 6 MHz now it gets strange, 7 periodes at 83.33 ns high and low, 41.67 ns high, 125 ns low, 41.67 ns high and 83.33 ns low and continue, so the evilnes moves bit by bit.
  
• At 8 MHz 83.33 ns high 41.67 ns low

So for my point of view it would be great to reduce the gap between the chunks or I need the input_delay_ns to move the capture point.

[Vollbrecht]

the delay is intrinsic to the mechanism used to write data from your application memory to the spi registers. in polling mode and in isr_driven mode this is the time the FreeRtos needs to copy the data from your buffer to the registers. it may see some improvements depending on your opt lvl but its an intrinsic limitation. to improve this you can give the driver an chunk of up to 64bytes that is send in one transaction ( in non DMA mode -> DMA allows up to 4kb). The chunkyfication creates smaller transaction but with the drawback of multiple transaction that always needs this memory copy.
You should try calculating what's your minimal speed needed to not let your FIFO fill up.
At a glance the speed of your transmitter / recv is at best 300kb/s ? so even with an 1us delay between each byte transaction this should not let the FIFO overflow assumming the following rough calculation: 300kb/s -> 38kbyte/s . (1usdelay+ 0.125*8 us per byte) -> 500kbyte/s.
So yeah the simple solution is to use the chunked variant. Otherwise you can try play with the input_delay_ns. PR's are always welcome