XM125 (Qwiic) SCL line hard-clamped to ~0.05V when powered — suspect faulty unit

Other
1

Hi, I’m hoping for help diagnosing what looks like a hardware fault on my SparkFun XM125 Qwiic Pulsed Radar breakout (SEN-24540).

Setup: RAK3272S (STM32WL-based) as host MCU, software (bit-banged) I2C on PA11 (SDA) / PA12 (SCL), 4.7k external pull-ups to 3.3V, WAKE_UP to PA5, INTERRUPT to PA7, shared 3.3V/GND rails on a breadboard. WU jumper on the XM125 board has been cut (confirmed via continuity test — no beep between WU pads). Powering via USB-UART adapter into the RAK.

Symptom: I2C bus scan never finds any device, including the expected default address 0x52. Scan loop times out on every address indefinitely.

Diagnostics performed so far:

  1. Continuity GND-to-GND across the whole breadboard: confirmed common ground.
  2. Continuity PA11→SDA pad and PA12→SCL pad: confirmed correct, no swap, pull-up resistors correctly placed (one leg 3.3V, other leg on signal node).
  3. Powered voltage check: RAK 3.3V/GND and XM125 3.3V/GND both read ~3.30V — supply is healthy on both boards.
  4. Idle bus check (unpowered): SDA-to-GND and SCL-to-GND — no continuity/short. Wiring is clean with no power applied.
  5. Idle bus check (powered): SDA reads 3.3V (healthy, pulled up). SCL reads 0.03–0.05V — hard clamped to ground.
  6. Isolation test: disconnected only the XM125’s SCL wire (left PA12 + pull-up resistor connected to everything else) — that node then reads a clean 3.3V. Reconnecting the XM125’s SCL wire immediately collapses the node back to ~0.05V. This isolates the clamp to the XM125 board itself, not the RAK or the breadboard wiring.
  7. Full power removal test: disconnected XM125 3.3V for 15–20+ seconds (not just a quick reset) to rule out a boot-sequencing/race condition with WAKE_UP. Re-tested with a firmware wake sequence that holds WAKE_UP low for 300ms+ after power-stable delay before ever asserting it high. SCL is still clamped low both before and after the wake sequence, and after manual I2C bus-recovery clock pulses.
  8. Onboard I2C jumper (3-way, top of board): confirmed continuity across all 3 pads — consistent with documented default-closed state, no solder bridge to an unrelated net.
  9. Onboard ADDR jumper: pads 1 and 3 show continuity to each other; pad 2 does not connect to either — appears consistent with documented “not yet implemented” open state, no anomaly found.
  10. Current draw on XM125’s 3.3V supply line: reads ~0mA at idle (note: I understand this doesn’t rule an internal I2C-pin fault in or out, since the clamped current flows through the SCL/GND loop via the external pull-up, not through the main VCC/GND path).

Based on this, SCL is only pulled to near-0V when the XM125 is both powered and physically connected to that node — not before power, not when isolated. This points to a fault internal to the module’s I2C interface rather than my wiring, pull-ups, or firmware sequencing.

Has anyone seen this failure mode before? Is there a known firmware/bootloader mode on the XM125 that could cause this (e.g., needing a specific first transaction, or a stuck bootloader state), or does this look like a hardware defect warranting RMA? Happy to run any further tests. Thanks!

2

Can you try testing the xm125 plugged in via usb by itself to isolate variables?

3

it works when connected with usb like I can see results on acconear exploration tools for presence and distance detection. But still when powered with usb, scl still gives 0.02V and sda 3v3. scl to gnd shows 77ohm resistance.

4

Thanks for the extremely thorough troubleshooting…that’s about as clean a fault isolation as we could ask for :slight_smile:

This does look like a hardware defect, not a wiring, pull-up, or sequencing issue. I’d recommend an RMA (file similar if purchased from a distributor) rather than continuing to troubleshoot. You’ve already ruled out everything on the host and wiring side.

Before you do, it could be worth a quick visual check under magnification around the module’s SCL pad/solder joints in case there’s a visible bridge that you might be able to fix faster

5

I tried using esp32-s3-wroom1 and still similar issue. May I confirm if wakeup pin should be connected to 3v3 and int pin not connected anywhere then it should detect device? I tried connecting to mcu pins as well but still no luck.

6

WU is tied to 3.3v by default (you mentioned leaving it intact…this is so the default design prevents it from entering low-power mode)

INT can be left unconnected for i2c (it is an interrupt output pin from the module)

7

I had another customer with a similar issue who was able to solve it by re-flashing the module