debugging USB VBUS with battery

[robbiemu]

While trying to upgrade to 0.5.8 (I have a couple of minor changes to the driver to expose LOD toggling, sensor mode, etc) I noticed a failure state. Actually, I think I noticed it earlier but just hadn't resolved it correctly. Quick partial backstory on that:

Earlier, I had my trackball working just fine after a battery replacement. A few days later, I unplugged the USB and was working on Bluetooth, then plugged it back in to usb and noticed that the bluetooth connection was automatically connecting still. To debug/understand that (I actually think the automatic reconnect is largely a normal behavior and quirk of the OS more than anything else), I had my Mac forget the device. Suddenly it wasn't working. Eventually I had it disassembled and disconnected the battery and USB started working. I plugged the battery back in, and it kept working. Connected bluetooth, it still was working. So I figured it was just not well seated or something and forgot it from there.

But now, working on the 0.5.8 driver, I noticed the same behavior again. We have a nRF52833 MCU and it may be an mcu that does not power up USB if it doesn't detect VBUS in time [1]; I’m looking for verification on whether this behavior points to a sequencing/VBUS-detect problem rather than a higher-level USB/HID problem.

So, again, the observed behavior:

• If the device boots with USB already connected, USB works normally.
• If I then connect the battery, USB continues working normally.
• If I unplug USB after that, plugging USB back in does not enumerate again.
• If the device is battery-powered first, then I plug in USB, it also does not enumerate.
• In the "failed state", a normal reboot does not recover USB.
• If I disconnect the battery while USB is plugged in, the board reboots and then USB is discovered correctly.

I added diagnostics in firmware and captured these snapshots:

Failed boot:

previous: boot=3 uptime_ms=6736 vbus=0 raw=0 usb_status=11 conn=0 hid_ready=0 transport=1 event=3 usb_evt=0 rr=0x00000001 cause=0x00000001 usbreg=0x00000000 pdet=0 prem=0 prdy=0 pint=0x00000380 usbd_en=0x00000000 pull=0x00000000 evcause=0x00000000 addr=0x00000000

Recovered boot:

current: boot=4 uptime_ms=8486 vbus=1 raw=2 usb_status=3 conn=2 hid_ready=1 transport=0 event=2 usb_evt=1 rr=0x00000001 cause=0x00000001 usbreg=0x00000003 pdet=0 prem=0 prdy=0 pint=0x00000380 usbd_en=0x00000001 pull=0x00000001 evcause=0x00000000 addr=0x00000001

Interpretation so far:

• In the failed boot, the Nordic USB regulator block reports:
  • usbreg=0x0
  • raw=0
  • no USB event seen
  • USBD disabled / no pullup
• In the good boot, it reports:
  • usbreg=0x3
  • raw=2
  • USB event seen
  • USBD enabled / pullup active

So this looks like the nRF52833’s USBREG/VBUS-detect path never sees valid VBUS in the failing battery-first / replug sequence, even though the cable is physically present.

What I’m trying to verify:

• Does this look like a known nRF52 VBUS/USB sequencing issue?
• Is it expected that the USB block can get stuck not seeing VBUS in a battery-powered scenario unless power sequencing is just right? (You could almost look at it as intended behavior in that, once the battery is fully discharged, it will fail over to usb, recharging the battery as well, but obviously that is suboptimal)
• Does this point more toward board-level VBUS delivery to the MCU’s VBUS pin (chatgpt wants to know -- I think that 5V is coming from the usb itself and has to be there for it to ever work, right?), bias path holding the USB VBUS, or early-init/power sequencing around the USBREG block?

I’ve already tried, without success:

• delayed USB stack restart
• delayed usb_dc_detach()/attach()
• re-arming Nordic USB power events
• delaying some board PM init

What I want verified is whether the diagnostics above are enough to say "this is below ZMK/HID and already failing at the nRF USBREG/VBUS-detect layer"

refs:
#https://community.particle.io/t/does-the-boron-require-vbus-to-program-via-usb/66299/3

[robbiemu]

You'd think "maybe a short", still,

I'm not seeing any physical issue on the board here (don't mind the hair on the ribbon, that was just transient dust)

[efogdev]

Hi! Thanks for the great report.

Are you using USB A-to-C or C-to-C cable? For rev4, that would be important.
I have a suspicion that it's your host might be to blame (partially). rev4 doesn't have pulldown resistors on CC lines, and there is no driver for the on-board AXP2585. Detection might be inconsistent. I've tried to make a driver for AXP2585 but didn't have much time and thus much luck. Also, just in case, if you are using some kind of USB hub, try connecting directly.

If you are using A-to-C, it would be a different story. I haven't had any similar reports so far, for either of the fw version.
rev4 hardware has USB_VBUS connected directly to the MCU, so it's not realistic that the chip "misses" the connection. Did you try to measure USB_VBUS somewhere on the board to confirm that it's 5V once USB becomes unavailable?

P.S. The most relevant version is v0.5.11 :)