ESP32-S3 SPI slave clock only stable on GPIO43

[hberntsen]

I tested, the interrupts are not the problem. When I provide my own CS with the generator it still has the same issues with the SPI peripheral counting one clock too many, sometimes.

Reducing the interrupts is a nice improvement indeed. It was on my list but low prio, since it does not seem to hurt anything in practice. Some units have different timings so the timer value should be representative. Instead I was thinking of using the RMT as clock idle detector.

I added that in an RMT variant of the signal tester. The interesting thing is: the RMT does count 264 pulses consistently on either pin 43 or 21. At the same time, the SPI peripheral does count 265 regularly when 21 is used. I'm switching with esp_rom_gpio_connect_in_signal. So it must be some GPIO specific configuration but as far as I see it is the same. Or the extra clock pulse is quicker than the RMT's 10 MHz.

[MicroController]

Do you have the correct SPI mode (CPOL/CPHA) selected?

[hberntsen]

Yes, I have the correct SPI mode selected (3, CPOL=1, CPHA=1).

[hberntsen]

I just tested with the ESP32-S3-DevKitC-1 using my signal generator and it works fine on that one. I also found that the ESP32-S3-MINI-1 has a resistor on the U0TXD line internally, so I guess that might filter out some glitches and that's why it works?

I also looked at lowering the clock of the GPIO glitch filter. That must be done by changing the whole CPU's clock source. The problem with that is that going too low will break stuff like USB serial console. The dedicated UART pin kept working but without the USB serial console active it is hard to reproduce the issue. The issue is also present without it when using it with ESPHome in Home Assistant but with the lowered CPU clock it crashes in esp_cpu_wait_for_intr (did not investigate that further).

For reference:

Code: Select all

#include "hal/clk_tree_ll.h"

// switch RMT to xtal so it is not affected by APB change
rx_cfg.clk_src           = RMT_CLK_SRC_XTAL;

// Setting the CPU clock to XTAL switches APB clock to CPU_CLK
clk_ll_cpu_set_divider(1);
clk_ll_cpu_set_src(SOC_CPU_CLK_SRC_XTAL);

Another experiment: the board has a 10K resistor in between IO9 and 10 (was intended for chip select emulation, now obsolete because I do that through the GPIO matrix. I connected a small bodge wire in between that resistor and the level shifter 3V3 side, both GPIO9 and 10 still are problematic. I removed that, added a 10pf (I don't know how to determine the best size) capacitor between the 3V3 side and ground, still problematic.

Somehow the pin 43, with its internal 499 ohm resistor and my external 10k ohm resistor is perfect on this specific board.

[MicroController]

Sounds like it might be an issue with signal rise/fall times. The MOSFET level shifter definitely has a limited bandwidth, and may in this case not be quite up to the task of delivering clean enough edges.
Might be worth trying a stronger pull-up resistor, maybe 1k or so.

[hberntsen]

Thanks, I've tried that by putting a 1.2K resistor in parallel to the 10k on the mosfet (3v3 side). This compares the 10k+1.2K situation (white line) to the stock of just 10k (blue). I do see that the curve starts to bend at around 2.5V, which is also around 0.75 * VDD, the high-level input voltage. All measurements here are when using the actual AC.

0005.PNG (8.74 KiB) Viewed 107 times

Unfortunately, this does not fix it, still getting a lot of frame errors.

So these are the frame error statistics I got:

• 0 with and without 10k ohm resistor connected from pin 21 to pin 43 (using 2cm wire on each leg). Using pin 43 as CLK
• 30% stock
• 0.5% with 10pf capacitor (between pin 21 and ground, directly on the mosfet and nearby capacitor)
• 11.5% with the extra 1.2k ohm resistor between pin 21 and 3v3.
• 18.5% when I soldered the 10pf capacitor back again, with small 0.5cm wires in between
• 62% when I soldered it back again, directly to the component)
• 45% back to stock
• 0 when I soldered the bridge from the mosfet on pin 21 with 10K resistor to pin 43.Using pin 43 as CLK. EDIT: for about 30 minutes this time. After that, a constant frame error rate of 1%

I opened up the log in the 62% situation, errors are about the transaction length. mostly about the transaction length being 265 or 267 bits. Lower exceptions are there as well, like 98 or 9,

It seems every time I solder to it things change unpredictably. Not sure what is going on (temperature?). The frame errors I measured here were averages over multiple minutes, with about the same per minute. Measured over a longer period it is linear:

screenshot-2026-04-05-165331.png (14.77 KiB) Viewed 96 times

[hberntsen]

It was a hardware defect. With a new board with 500 ohm resistor in series it works perfectly. Thanks a lot for thinking along @MicroController!