Fix SPI bus detach issue on ESP32-C3 with Arduino 3.x - #176
Open
hallard wants to merge 1 commit into
Open
Conversation
On ESP32-C3 with Arduino 3.x (IDF 5.x), SPI.end() fully detaches the SPI bus and releases GPIO pins. Since SpiStart()/SpiEnd() are called around every single SPI transaction, this causes the bus to be repeatedly torn down and rebuilt, which breaks GPIO pin assignments and hangs the firmware. Fix by: - Only calling SPI.begin() once (on first use) instead of every transaction - Removing SPI.end() from SpiEnd(), keeping only SPI.endTransaction() This fixes CC1101 operation on ESP32-C3 boards while remaining compatible with ESP32, ESP32-S3, and ESP8266. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1technophile
added a commit
to 1technophile/OpenMQTTGateway
that referenced
this pull request
Aug 9, 2026
…fore probe On the platform we ship (pioarduino 55.03.39 / arduino-esp32 3.3.9) the pinned SmartRC-CC1101-Driver-Lib v2.5.7 does not work with the CC1101 at all. Core 3.x's peripheral manager owns SCK/MISO/MOSI once SPI.begin() has run, so the driver's digitalWrite() calls on those pins become silent no-ops, and it starts and stops the SPI bus around every single register access (LSatan/SmartRC-CC1101-Driver-Lib#176). Bench result on an ESP32 DevKit + CC1101 running esp32dev-pilight-cc1101: setup hangs in the driver's unbounded `while(digitalRead(MISO_PIN));` before any C1101 log line is emitted, and TG1WDT reboots the board in a loop. The same build on espressif32@6.8.1 (core 2.0.17) initialises normally, so this is the core, not the wiring. Every ZradioCC1101 ESP32 environment is affected: Pilight, RF, RF2 and Somfy. The RTL_433 CC1101 path goes through RadioLib and is unaffected. V3.0.x re-engineered the SPI core for ESP32: gpio_get_level() with a timeout instead of the unbounded digitalRead() wait, SPI.begin() once instead of per transaction, and no digitalWrite() on peripheral-owned pins. It also moved SPI.begin() out of getCC1101() and into Init(), so the connection probe has to run after Init() rather than before it — reported in #2348. Both changes are needed together: the reorder alone does not help on core 3.x, and V3 cannot work without it. Verified on the bench, core 3.3.9, esp32dev-pilight-cc1101: N: C1101 SPI connection OK on attempt 1 N: C1101 tuned RX to 433.92 MHz plus a live round trip — an arctech_switch frame published to MQTTtoPilight was transmitted and decoded back by the board's own receiver on PilighttoMQTT. Note for review: this bumps the pin for the ESP8266 CC1101 environments too. They are not affected by the core 3.x breakage and V3 is untested there, so the pin may be worth splitting per environment before this lands. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
3 tasks
1technophile
added a commit
to 1technophile/OpenMQTTGateway
that referenced
this pull request
Aug 15, 2026
…fore probe (#2353) On the platform we ship (pioarduino 55.03.39 / arduino-esp32 3.3.9) the pinned SmartRC-CC1101-Driver-Lib v2.5.7 does not work with the CC1101 at all. Core 3.x's peripheral manager owns SCK/MISO/MOSI once SPI.begin() has run, so the driver's digitalWrite() calls on those pins become silent no-ops, and it starts and stops the SPI bus around every single register access (LSatan/SmartRC-CC1101-Driver-Lib#176). Bench result on an ESP32 DevKit + CC1101 running esp32dev-pilight-cc1101: setup hangs in the driver's unbounded `while(digitalRead(MISO_PIN));` before any C1101 log line is emitted, and TG1WDT reboots the board in a loop. The same build on espressif32@6.8.1 (core 2.0.17) initialises normally, so this is the core, not the wiring. Every ZradioCC1101 ESP32 environment is affected: Pilight, RF, RF2 and Somfy. The RTL_433 CC1101 path goes through RadioLib and is unaffected. V3.0.x re-engineered the SPI core for ESP32: gpio_get_level() with a timeout instead of the unbounded digitalRead() wait, SPI.begin() once instead of per transaction, and no digitalWrite() on peripheral-owned pins. It also moved SPI.begin() out of getCC1101() and into Init(), so the connection probe has to run after Init() rather than before it — reported in #2348. Both changes are needed together: the reorder alone does not help on core 3.x, and V3 cannot work without it. Verified on the bench, core 3.3.9, esp32dev-pilight-cc1101: N: C1101 SPI connection OK on attempt 1 N: C1101 tuned RX to 433.92 MHz plus a live round trip — an arctech_switch frame published to MQTTtoPilight was transmitted and decoded back by the board's own receiver on PilighttoMQTT. Note for review: this bumps the pin for the ESP8266 CC1101 environments too. They are not affected by the core 3.x breakage and V3 is untested there, so the pin may be worth splitting per environment before this lands. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
SPI.end()now fully detaches the SPI bus and releases GPIO pins on newer ESP32 Arduino coresSpiStart()/SpiEnd()wrap every single SPI transaction, this caused the bus to be repeatedly torn down and rebuilt, hanging the firmwareChanges
SpiStart(): Only callSPI.begin()andpinMode()once (first use), skip on subsequent callsSpiEnd(): RemoveSPI.end(), keep onlySPI.endTransaction()Testing
🤖 Generated with Claude Code