xiao_nrf52: move Wire to NFC pins to unblock BLE pairing

[Strykar]

Problem

On Xiao_nrf52* envs, PIN_WIRE_SDA=D7 / PIN_WIRE_SCL=D6 collide with PIN_SERIAL1_RX/TX defined in variants/xiao_nrf52/variant.h:

#define PIN_SERIAL1_RX  (7)
#define PIN_SERIAL1_TX  (6)

With Wire muxed onto the same pads, the BLE companion advertises briefly after boot and then stops. The MeshCore Android app intermittently fails to pair, and Serial output is unreliable.

Fix

Move Wire to the NFC pads (P0.30 NFC1, P0.31 NFC2). The Adafruit BSP exposes them as Arduino pins 30/31 and they aren't claimed by another peripheral on this board. Same approach Meshtastic uses for the same baseboard (their seeed_xiao_nrf52840_kit/variant.h).

Diff

+5/-2 in variants/xiao_nrf52/platformio.ini. No code changes.

Tested

• Hardware: XIAO nRF52840 Sense + Wio-SX1262 for XIAO Kit
• Confirmed: BLE advertises stably, MeshCore Android app pairs and stays connected
• Tested on dev (current meshcore-dev/Adafruit_nRF52_Arduino fork) and on main with the stock framework-arduinoadafruitnrf52@1.10700.0 — both work

[446564]

I can't reproduce this on a xiao nrf w/ wio. I think it's a red herring the AI dreamed up

[Strykar]

The Serial1 framing in the PR is wrong. Serial1.begin is never called in the BLE companion build, so the symbolic overlap with PIN_SERIAL1_RX/TX in variant.h has no runtime effect.

The actual symptom on this unit: SCL on the original D6 (P1.11) is held low. Internal pull-up (~13kΩ) loses to it; the chip's S0S1 drive overpowers it cleanly, so it's a moderate ~1–5kΩ external pull, not a hard short. With SCL low, TwoWire::endTransmission in the Adafruit nRF52 BSP spins forever at while(!_p_twim->EVENTS_TXSTARTED && !_p_twim->EVENTS_ERROR); (no timeout). The first I2C probe is in AutoDiscoverRTCClock::begin(Wire) inside radio_init(), before BLE init runs, so advertising never starts.

Both the Wio-SX1262 for XIAO carrier (V1.0) and the Seeed XIAO nRF52840 Sense schematics show nothing on P1.11. Multimeter check still to do, but the most likely cause is a unit-specific defect on this Sense board (a P1.10/P1.11 solder bridge is the leading candidate; P1.10 is MIC_PWR on the adjacent QFN ball). That's consistent with your "can't reproduce".

If it holds up as a unit-specific issue, the PR shouldn't apply to everyone on Xiao_nrf52*. Happy to withdraw. The more generally-useful change is adding TWIM stuck-bus recovery before Wire.begin() so a held-low line doesn't silently kill BLE init regardless of cause. Would you prefer that as a separate PR?