Skip to content

Fix pin_backup_t missing the input routing of a pin - #349

Merged
lovyan03 merged 1 commit into
m5stack:developfrom
ainyan03:pin_backup_in_sel
Oct 13, 2026
Merged

lovyan03 merged 1 commit into
m5stack:developfrom
ainyan03:pin_backup_in_sel

Conversation

@ainyan03

Copy link
Copy Markdown
Contributor

Fixes #348.

What changes

pin_backup_t::backup() looks for the input signal routed from a pin by reading the input selector (IN_SEL) of the pin's output signal. It compared that selector with the signal number, but IN_SEL holds the GPIO number routed to the signal. So the match only happened when the two numbers were equal by chance, _in_func_num stayed -1, and restore() never put the input routing back.

  • Compare with the pin number, as proposed in ESP32: pin_backup_t::backup() が入力選択フィールドをピン番号ではなく信号番号と比較している #348, and only while SIG_IN_SEL is set. With SIG_IN_SEL clear the signal bypasses the GPIO matrix and IN_SEL is a stale value that does not belong to this pin. Matching it would let restore() undo routing that another pin owns.
  • Restore order. The input selector write was never reached before, and it sat before the pad registers. It now runs after IO_MUX, GPIO_PIN and the output selector are restored, and before output is re-enabled. This way the input is not reconnected to a pad still configured by the borrower, for example with its input buffer disabled.
  • matches_current() now also compares the input selector, so a pin whose input routing was changed while borrowed is reported as changed. Board detection uses it to decide whether a pin needs restoring.

Checked

  • Register layout against the ESP-IDF 5.5 headers for ESP32, S2, S3, C2, C3, C5, C6, C61, H2 and P4. IN_SEL holds a GPIO number on all of them. The constant inputs are above the GPIO range. GPIO_SIG0_IN_SEL / GPIO_SIG1_IN_SEL exist on each. On the P4, the GPIO_FUNC1_IN_SEL_CFG_REG based read and the GPIO.func_in_sel_cfg[] write hit the same register.
  • Hardware, with the internal I2C bus (M5.In_I2C). The test backs up SDA/SCL, routes their input signals to the constant-high input, calls restore(), and reads IN_SEL again:
Board Chip Before After
Core2 v1.3, Station ESP32 IN_SEL stays 0x38 back to 21/22
CoreS3 ESP32-S3 IN_SEL stays 0x38 back to 12/11
StopWatch, PaperMono ESP32-S3 IN_SEL stays 0x38 back to 47/48
Tab5 ESP32-P4 IN_SEL stays 0x3F back to 31/32
  • Board detection result and the resulting display/touch configuration are unchanged before/after on 9 boards: the 6 above plus Basic, ToughC5 and NanoC6.
  • Builds with Arduino 2.0.17 / 3.x and ESP-IDF 4.4 to 6.1 across ESP32, S3, C3, C5, C6, C61, H2 and P4.

Not tested

  • ESP32-S2, C2 and C3 hardware: register definitions and builds only.

backup() looks for the input signal routed from a pin by reading the input
selector of the pin's output signal. It compared that selector with the
signal number, but the selector holds the GPIO number routed to the signal,
so the match only happened when the two numbers were equal by chance, and
restore() left the input routing as the borrower had set it.

- Compare the selector with the pin number, and only while SIG_IN_SEL is
  set. With SIG_IN_SEL clear the signal bypasses the GPIO matrix and the
  selector is a stale value that does not belong to this pin.
- restore() now writes the saved input selector back. Do it after the IO
  MUX, GPIO_PIN and output selector registers are restored, so the input
  is not reconnected to a pad still configured by the borrower.
- matches_current() compares the input selector too, so a pin whose input
  routing was changed while borrowed is reported as changed.
@lovyan03
lovyan03 merged commit c09b635 into m5stack:develop Oct 13, 2026
25 checks passed
@ainyan03
ainyan03 deleted the pin_backup_in_sel branch October 13, 2026 03:25
ainyan03 added a commit to ainyan03/M5GFX that referenced this pull request Oct 13, 2026
@ainyan03 ainyan03 mentioned this pull request Oct 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants