BK7238: GPIO edge interrupts never fire (pulse_counter / hlw8012 / BL0937 read 0)

[blafois]

Summary

On the freshly-added BK7238 target, GPIO edge interrupts never fire. attachInterrupt()-based consumers (ESPHome pulse_counter, hlw8012/BL0937 energy metering) receive zero edges, even with a strong, continuous signal on the pin. The same wiring/config works on BK7231N.

This makes any interrupt/pulse-driven peripheral (energy meters, pulse counters, etc.) non-functional on BK7238, while polling-based GPIO (button input, relay/LED output) works fine.

Environment

• LibreTiny v1.13.0 (latest release; master is identical) — BK7238 support from [beken-72xx] Support BK7238 #360, BDK 3.0.78
• ESPHome 2026.8.0-dev (dev branch, native BK7238 support)
• Board: generic-bk7238-tuya
• Device: LSC Smart Plug w/ energy meter (Tuya T1-2S-NL module, BK7238, BL0937 metering chip)
• Flashed via UART (ltchiptool); app confirmed booting (correct build timestamp in logs)

What works vs. what doesn't

Function	GPIO	Mechanism	Works?
Relay	P24	digital output	✅
Status LEDs	P9, P11	digital output	✅
Button	P26	polling input	✅
BL0937 power meter	CF=P6, CF1=P8, SEL=P1	interrupt (pulse)	❌ reads 0

Minimal reproduction

Bare pulse_counter on the BL0937 CF (power) and CF1 (voltage/current) pins:

sensor:
  - platform: pulse_counter
    name: "CF pulses (P6 power)"
    pin: P6
    update_interval: 5s
  - platform: pulse_counter
    name: "CF1 pulses (P8 V/I)"
    pin: P8
    update_interval: 5s

Plug energized on live mains, relay ON, ~250 W resistive/inductive load (a running drill) drawing current. A BL0937 CF output at 250 W should pulse at several hundred Hz.

Observed — flat zero for 25+ seconds on both pins:

[pulse_counter:200]: 'CF pulses (P6 power)':  Retrieved counter: 0.00 pulses/min
[pulse_counter:200]: 'CF1 pulses (P8 V/I)':   Retrieved counter: 0.00 pulses/min
(repeats every 5 s, always 0.00)

hlw8012/BL0937 likewise logs Got power=0.0W, voltage=0.0V (exactly 0.0, not nan), i.e. the driver runs but counts no pulses.

Notes / where I looked

The Arduino IRQ shim (cores/beken-72xx/arduino/src/wiring_irq.c) looks complete and calls gpio_int_enable(...). In the BDK (beken378/driver/gpio/gpio.c), gpio_int_enable() does register the GPIO ISR (intc_service_register(IRQ_GPIO, PRI_IRQ_GPIO, gpio_isr)) and has CFG_SOC_NAME == SOC_BK7238 branches for the interrupt-level registers, so the path appears wired up — yet no user callback is ever invoked on BK7238. Something in the BK7238 GPIO interrupt enable/dispatch (e.g. ICU/INTC routing or the INT-enable register write) is likely not taking effect.

Happy to run further tests on real hardware (scope on CF pin, register dumps, etc.).

[blafois]

Update: narrowed down — GPIO input polling works, only edge interrupts fail

I validated the pins independently of interrupts by polling the raw pin state in a tight digitalRead() loop (no attachInterrupt) and counting level transitions over a 30 ms window, on the same BL0937 CF (P6) and CF1 (P8) pins.

pinMode(6, INPUT);
int last = digitalRead(6), changes = 0;
uint32_t t0 = micros();
while ((uint32_t)(micros() - t0) < 30000) {
  int v = digitalRead(6);
  if (v != last) { changes++; last = v; }
}
// same for pin 8

Results on live mains:

Pin	Signal	No load	~250 W load (drill)
P8 (CF1, voltage)	always present	~117 transitions/30 ms (~1.9 kHz)	~118 transitions/30 ms
P6 (CF, power)	load-dependent	0 transitions	8 transitions/30 ms (~130 Hz)

Both pins track exactly as a BL0937 should — CF1 constant with mains, CF proportional to load. So:

• ✅ Pins are correct, signals are physically present on the GPIOs
• ✅ GPIO input reading works on BK7238 (via polling)
• ❌ Only the interrupt / edge-detection path is dead — the exact same pins produce 0 pulses via pulse_counter / hlw8012 (interrupt-driven), but poll fine

This narrows the bug considerably: pinMode(INPUT) + digitalRead() clearly reach the correct GPIO input register, so the config/input register mapping is fine. The failure is specific to attachInterrupt → gpio_int_enable() and the GPIO interrupt registers (REG_GPIO_INTEN / REG_GPIO_INTLV0/1 / REG_GPIO_INTSTA, defined as GPIO_BASE_ADDR + 33..36*4 with no BK7238-specific guard) and/or the ISR dispatch. A plausible cause is those interrupt registers being at different offsets on BK7238 than on BK7231N.

I'm going to instrument the interrupt-enable/status registers on hardware and attempt a fix; will follow up with findings.

[blafois]

CORRECTION + full root cause: LibreTiny interrupts are fine — the bug is in-ISR digital_read() edge classification

I was wrong that BK7238 interrupts don't fire. After extensive on-hardware instrumentation, the whole LibreTiny interrupt path works correctly. The real issue is elsewhere (and mostly on the ESPHome side). Full evidence:

Everything at the LibreTiny/HW level works (tested on P8 = BL0937 CF1, an always-present ~4 kHz voltage waveform on mains, no load needed):

Test (raw, bypassing ESPHome)	Result
digitalRead() polling in a tight loop	✅ ~118 transitions/30 ms
Manual GPIO INT regs: enable + poll INTSTA	✅ INTSTA bit latches the edge
ICU: ICU_INTERRUPT_ENABLE bit7	✅ set
attachInterrupt(RISING) ISR callback count	✅ ~2000/s
attachInterrupt(FALLING)	✅ works
attachInterrupt(CHANGE)	✅ ~2× (both edges)
attachInterruptParam(CHANGE) + digitalRead() in ISR	✅ fires ~4000/s

The actual failure — ESPHome pulse_counter/hlw8012 still read 0 on the same pin/signal. Root cause found by instrumenting the exact ISR idiom:

in-ISR digitalRead():  HIGH=0   LOW=72124     // always reads LOW at ISR entry

ESPHome's BasicPulseCounterStorage::gpio_intr classifies the edge with:

mode = isr_pin.digital_read() ? rising_edge_mode : falling_edge_mode;

With the default (rising=INCREMENT, falling=DISABLE), and digital_read() always returning LOW inside the ISR, every edge is treated as falling → DISABLE → nothing counts. Confirmed: setting both edges to INCREMENT immediately yields ~240 000 pulses/min on the same pin.

Why digital_read() always reads LOW: on BK7238 the edge interrupt reaches the ISR after the pin has already settled back to idle for a fast pulse train (IRQ latency > pulse high-time). I checked both the config-reg INPUT bit (bit0) and INPUT_MONITOR bit (bit7) from within the ISR — both read 0. There is no separate fast GPIO input-data register (unlike ESP8266's GPI, whose ISRInternalGPIOPin::digital_read() reads the live pad register directly and so classifies edges correctly).

Implications / fix options:

• This mainly affects ESPHome (pulse_counter, hlw8012, cse7766, etc.) on LibreTiny/BK7238 — any consumer that uses INTERRUPT_ANY_EDGE and infers direction via in-ISR digital_read().
• Options: (a) ESPHome: for the common ANY_EDGE + one-mode-DISABLE config, don't gate on digital_read() — count the edge unconditionally, or arm a single hardware edge (RISING/FALLING both proven reliable) instead of CHANGE; (b) LibreTiny: since its CHANGE emulation already tracks which edge it armed (data->irqMode), it could expose that to the callback so consumers don't need to re-read the pin.

Happy to test a candidate patch on hardware. Apologies for the misleading original title — shall I retitle/repurpose this issue toward the digital_read()-in-ISR classification problem?

[blafois]

Fix proposed in #394 — cache the edge-implied level in the GPIO ISR and return it from digitalRead() while the handler runs. Verified on BK7238 + BL0937: ESPHome pulse_counter 0 → 120k pulses/min, hlw8012 0 W → live ~3065 W / 9.9 A / 373 V.