ESP32C3: SPI errors due to late MISO sampling

[danielkucera]

Board

ESP32C3 super mini

Device Description

Qorvo DW1000 UWB module via SPI

Hardware Configuration

SPI running at 16Mhz

Version

v2.0.17

IDE Name

platformio

Operating System

Ubuntu

Flash frequency

no idea

PSRAM enabled

no

Upload speed

460800

Description

I noticed (often) random errors when reading from SPI when communicating with DW1000.

See attached screenshot:

Logic analyzer (PulseView) reads the value correctly (0xDC) but C3 does not (0x9C - highlighted in terminal).

Here you can see the MISO went down about 26ns after clock rise:

When I migrated the project from C3 to good old ESP32 all errors were gone.

So I prepared a test bed to find out the sampling delay (data latch-in after CLK rise).
It is a breadboard with a series of logical inverter pairs in 74AC04 package. Each inverter introduces about 4ns delay so 1 pair gives 8ns delay (detailed numbers on scope pictures). Then the signal is fed back to MISO and read by the module.

Now the results comparison for ESP32 and ESP32C3

number of inverter pairs	ESP32 read value	ESP32C3 read value	note
0 - SPICLK connected directly to MISO	0xFF	0xFF
1 pair	0x00	0xFF	Scope 1.
2	0x00	0xFF
3	0x00	0xFF
4	0x00	0x80	Scope 2.
5	0x7F	0x00	Scope 3.
6	0x7F	0x00

Oscilloscope pictures follow. CH1 - CLKOUT, CH2 - MISO

Scope 1.:

Scope 2.:

Scope 3.:

From this data it is obvious that ESP32 samples data less than 9ns after clock rise. 👍
ESP32C3 samples data somewhere around 27ns after clock rise which explains why the bit from the module was read as 0.

The api reference explains some settings for sampling but how can this be configured from Arduino?

Sketch

simply read from SPI at 16Mhz

Debug Message

N/A

Other Steps to Reproduce

No response

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[me-no-dev]

Have you tried with SPI MODE 1 or 2? Looks like it should sample on the falling edge

[danielkucera]

I haven't tried because the device is configured for MODE 0. The sampling should happen on the rising edge but it is obviously happening 27ns after.

[me-no-dev]

The point of sampling is done inside the hardware and can only be controlled by switching the mode. We do not have other way to influence it. I suggest you try another mode and see if that will make the device work

[danielkucera]

Chapter 27.8 GP-SPI2 Timing Compensation in ESP32-C3 Technical Reference Manual Version 1.2 show some comprehensive options to configure the timing, especially this diagram:

So I believe there should be some way to configure it.

[Jason2866]

Maybe, but if only in espidf. Arduino code does no low level code to control hardware.

[danielkucera]

I suspect this might be a HW bug. Did/could someone from espressif validate the SPI hardware?
Why else would it perfectly work on ESP32 but not on ESP32C3?

[danielkucera]

I spent some more hours on this. It seems it all boils down to Register 27.12. SPI_CLOCK_REG (0x000C)
For 16Mhz:

• ESP32 on Arduino has value 0x80003043 - 0 read with 1 delay
• C3 on Arduino has value 0x4002 - 0x0 read with 5 delays
• C3 on esp-idf has value 0x4044 - 0x0 read with 3 delay! so esp-idf does something better here.

My question now is, how this value should calculated? There is no mention in C3 TRM.
I also looked into esp32-hal-spi.c but it does not give me much sense.

Ideally, I would like to read 0x0 with 1 delay also on C3 and I feel this should be doable.

[danielkucera]

There is no explanation for SPI_CLKCNT_L and SPI_CLKCNT_H in C3 TRM.
It says, for example, that SPI_CLKCNT_L ... must be equal to SPI_CLKCNT_N which is not true for Arduino as I have shown in above examples.
SPI_CLKCNT_H In master mode, this field must be floor((SPI_CLKCNT_N + 1)/2 - 1). - which is not true again...

[danielkucera]

Ok, I think I understand the clock config now:

clk_hclk -> [ clock divider by value SPI_CLKDIV_PRE ] - > [ timer ] -> CLK_OUT

timer config:

• SPI_CLKCNT_N - reset value
• SPI_CLKCNT_H - value which triggers falling edge
• SPI_CLKCNT_L - value which triggers rising edge

Now these are the measured values with C3:

• register value 0x4004 - 1 interval high, 4 low, MISO latched before 8ns

• register value 0x4044 - 2 high, 3 low, MISO latched before 20ns

• register value 0x4084 - 3 high, 2 low, MISO latched before 32ns

Now the ultimate question: Why does the sample delay changes with moving falling edge? It should be only related to rising edges in MODE0.

[Jason2866]

@danielkucera In your opinion is the observation you made "something" that can be changed / fixed in Arduino Core code? Or should this better moved to IDF where low level code access is possible?

EDIT: Is the seen behaviour still there in actual Arduino core? The underlying IDF version has changed!