SPI0 and DLEN in non-DMA mode (errata)

[piras77]

Hi there,

The DLEN description in the datasheet (p.156) says: "This field is only valid for DMA mode (DMAEN set)".

However, it appears to me, the value has also an impact to non-DMA transfers. I.e. SPI0.SCLK is suspended (i.e. stays low) in non-DMA mode for the duration of a single clock pulse at the end of each byte-transfer if DLEN=0 or DLEN=1. There is no suspension with other values.

Attached are two pictures monitoring the transfer of 4 bytes (0x1,0x3,0x7,0xf); first with DLEN=0; second with DLEN=2. Channel 4 is MOSI, channel 5 is SCLK. The peripheral is directly controlled from user land.

DLEN=0

dlen0.png (39.28 KiB) Viewed 2726 times

DLEN=2

dlen2.png (39.22 KiB) Viewed 2726 times

Can anybody confirm or refute? Is this already documented somewhere? Thanks for your feedback!

[joan]

That is very interesting.

I will check later with pigpio.

I was aware of the inter byte gap (I time it at 1.5 clocks) but was not aware DLEN made any difference. If I can remove the gap from the pigpio implementation I would like to do so.

[joan]

I can confirm this behaviour with the main SPI peripheral and setting DLEN=2.

I now use that value in pigpio so there should no longer be inter-byte gaps with the main SPI device.

[dbosk]

I can confirm this behaviour with the main SPI peripheral and setting DLEN=2.

I now use that value in pigpio so there should no longer be inter-byte gaps with the main SPI device.

I'm having a similar issue. Did you set DLEN=2 from the pigpio library?

[juj]

Thanks a million for discovering this hardware quirk! About 6 months ago I was also observing this 9th clock sleep in my application with logic analyzer. Being able to author an easy perf win such as this made my day: https://github.com/juj/fbcp-ili9341/com ... d2a192945b .

Observed the 9th clock to disappear and so far have not seen any downsides to this, and mixing DMA and Polled SPI seems to work cleanly as well. The often discussed hypothesis about Polled SPI needing one clock to work its FIFO does not seem valid, and I'm starting to think this stall was added to do some kind of synchronization/stall for the DMA hardware when it's clocking in the last two bytes of its SPI transfer (it counts down the DLEN register live when transmitting), in order to paper over some timing issue or some other hardware fluke, and they might not have realized the effect it had to overall non-DMA transfers. Just a random guess though..