ESP32 Forum

Hi,

I'm running into a problem: on the ESP32-S3, using the SPI slave often generates transactions with too many bits received. In a rare case I get less bits.

* It is a 30KHz clock with 160 or 264 bits of data (configurable), sending 20 transactions per second.
* The code is over here: https://github.com/hberntsen/mhi-ac-ctrl-esp32-c3 . I'm now testing it out with the S3. I'm using ESPHome 2026.2 with ESP-IDF framework
* It runs rock solid when using pin 43 (normally TXD). Can run for a week without any issue. Same as my C3. Unless I connect the USB port and open the serial console. Then I have the same problem.
* I'm using this board, v1.2: https://www.tinytronics.nl/en/developme ... r-esp32-s3 . I connected pin 21 and 43 together with a wire.
* This is how the signal looks: https://github.com/hberntsen/mhi-ac-ctr ... 2695634858

When I reflash over WiFi to 21 the problem appears and with 43 disappears. Pins 39, 40, 41, 44 behave the same as 21. I checked the signal with an oscilloscope and it looks clean. So this feels like a software issue but I don't know where to look. I've dumped the GPIO pin configuration after configuring, both 21 and 43 get the same: Note that the code does a pull-up, this was when testing pulldown.

Any hints on what to check? I already tried disabling the logger component and that did not make a difference.

What genuis decided it'd be a good idea to connect the same USB data lines to two USB connectors plus two other connectors, then also put pull-up resistors on them, label them as "TX" and "RX", and wire them together to two IO pins each?! That board is a mess!

Your use of GPIO43 ("TXD0") may be conflicting with the default UART0 (logging/bootloader) output; in turn pulling the SPI master's clock line low, which the master may not be fond of. Don't know why GPIO21 would not work though - unless there's something else hooked up to/messing with the "CLKH" input.

@MicroController I did! :)
Actually it has to do with the use case, in this case as many AC units as possible. On quite a few AC units a USB-A connector is misused as a UART connector. So in fact they are not USB data lines (only DN and DP are), but UART signals. The other two connectors are a JST-GH connector (for Haier AC units) and common JST-XH footprint to either solder a XH connector, regular pin headers, cables, etc. The latter may be used for UART, or in this case SPI. Also note that D1 does not connect the UART signals with the USB signals, as it is just a TVS diode array.

To be clear though, with GPIO43 the implementation mentioned by @hberntsen does work, just not with GPIO21 (or any other GPIO for that matter). The thing is, we want to have GPIO43 available to use as UART0, and thus to make it work with another GPIO like GPIO21.

What genuis decided it'd be a good idea to connect the same USB data lines to two USB connectors plus two other connectors, then also put pull-up resistors on them, label them as "TX" and "RX", and wire them together to two IO pins each?! That board is a mess!

As the webshop says:

A USB-A connector hat needs to be soldered (this is not included). Various air conditioner brands such as (older) models from Haier, Midea, Electrolux, Comfee, Qlima, Electrolux, etc. use this connector. This pinout is generally universal, but always verify this with your own air conditioner.

Your use of GPIO43 ("TXD0") may be conflicting with the default UART0 (logging/bootloader) output; in turn pulling the SPI master's clock line low, which the master may not be fond of. Don't know why GPIO21 would not work though - unless there's something else hooked up to/messing with the "CLKH" input.

Yeah pin 43 isn't great. I'm just unable to find the reason why it behaves differently in practice. After my code runs, the pin configuration is the same as the other pins I tried.

As the webshop says:

A USB-A connector hat needs to be soldered (this is not included). Various air conditioner brands such as (older) models from Haier, Midea, Electrolux, Comfee, Qlima, Electrolux, etc. use this connector. This pinout is generally universal, but always verify this with your own air conditioner.

More reason not to hook up these signals to the ESP's USB pins. Especially when you still have another dozen unused IOs available...

Also note that D1 does not connect the UART signals with the USB signals, as it is just a TVS diode array.

Oh dang! I clearly missed that the signals are actually not connected to the same TVS diodes. I'm sorry for mistakenly criticizing your board.

@hberntsen : If you don't get an SPI CS signal, how does your code 'bootstrap' the communication, i.e. sync with the start of the first transaction from the master after reset/power-up?

@MicroController I've put an interrupt on the CLK signal that resets a timer. When the timer reaches 1 millisecond that means the clock is idle and I toggle the CS. I originally did that by physically connecting two GPIOs together, that is now done internally through the GPIO matrix (using the constant 1 and 0 input). That works very reliable.

I've created two test projects to demonstrate the issue. One of them generates the signal and the other one reads it:
* https://github.com/hberntsen/mhi-ac-spi ... -generator
* https://github.com/hberntsen/mhi-ac-spi-signal-tester

Hmm.

Probably not related to your actual problem, but you may want to turn off the SCLK GPIO interrupt in the ISR to not have to handle and interrupt on every bit transferred (@30kHz!). Basically, in the GPIO ISR, disable GPIO interrupt, start timer, done; in the timer ISR, toggle CS, stop+reset timer, enable GPIO interrupt.