nRF5340 DK not powering correctly over USB — only works on coin cell (dim/blink behavior).

I have an nRF5340 DK that exhibits unusual power behavior. When I plug in the IMCU USB port (USB connected to onboard debugger), the board briefly flashes all LEDs, including LED5 and the four user LEDs — but only for a split second. The flash is very dim, and all LEDs then remain off. Flipping the power switch ON/OFF while USB remains connected causes the same brief dim impulse.

I've verified the following:

  • White check mark USB cable is known good (verified for both power and data with my phone)

  • White check mark Behavior is identical using both PC USB ports and a high-current USB wall adapter

  • White check mark Flipping the 3-way power selector switch between USB, VDD, and Li-Po makes no difference in this case — USB power remains non-functional

However, when I connect USB to the nRF5340 USB port (the target SoC's USB peripheral), and set the 3-way selector to USB, the 4 user LEDs begin blinking — but again, they are extremely dim. LED5 remains off.

Here's the interesting part:

When I removed the plastic tab from the coin cell, set the 3-way selector to VDD, and powered the board from the coin cell, the four user LEDs cycle at normal brightness, and the blinking behavior appears stable. This seems to confirm that the board and MCU are functional, but the power circuitry from USB and Li-Po inputs may not be working correctly.

I also tested:

  • White check mark Attaching 3.8V to the Li-Po header (P27) and selecting Li-Po power = same brief dim impulse blink

  • X PC does not detect the board in Device Manager when connected via IMCU USB (no J-Link or COM port)

  • X No mass storage device (e.g., JLINK drive) appears

  • X LED5 (power/status LED) never stays on when using USB or Li-Po sources

This suggests to me that the onboard power regulation or the debugger section may not be functioning correctly. Am I missing a required jumper or switch for enabling USB power regulation or debugger power path?


TL;DR:

Condition Result
USB into IMCU (PowerSelector=USB) All LEDs blink dimly once, then dead
USB into nRF5340 USB (PowerSelector=USB) User LEDs cycle dimly, LED5 off
Wall power into either USB Same as above
3.8V to P27 (PowerSelector=Li-Po) One dim blink on all LEDs, then dead
Coin cell (PowerSelector=VDD) White check mark User LEDs blink bright and properly, LED5 still off (expected?)
PC never detects J-Link/debugger No device shows in Device Manager
Parents
  • Follow-Up (Power Issue Diagnosis):

    Quick update based on voltage measurements:

    • VDD rail measures only 1.5–1.8V under all power sources (USB, Li-Po, coin cell).

    • USB 5V input is present, but LED5 never stays on and the board does not enumerate via IMCU USB.

    • On coin cell (PowerSource = VDD), the board runs normally — 4 user LEDs blink at full brightness. The cell drops briefly to ~2.7–2.8V under load, then recovers to 3.0V when removed, suggesting no excess draw.

    • USB_VDD line near the nRF5340 USB port reads ~1.8V, possibly due to backfeed while on coin cell?

    This points to a likely power regulation or switching fault on the board, preventing proper VDD. Please advise if further steps are recommended or if this warrants replacement.

  • Hi,

    Which version of the DK do you have? (The info on the sticker)

    Regards,
    Sigurd Hellesvik

  • Hi Sigurd,

    My sticker says:
    PCA10095

    2.0.2

    2024.3

    1050012970

  • I ask becaues there are two types of debugger chips on the DKs. You got the new one.

    With this one, you can perhaps try this:

    "nrfutil device x-update-debug-probe-firmware"

    It is a long shot, but worth a try.

    Other than that, the symptoms you see can perhaps be due to a short between VDD or 5V and GND. Can you try to measure that?

  • Following your recommendation, I investigated the board’s power behavior since it never enumerates over USB and cannot reach the point where a debug MCU firmware update is possible. Here's a summary of my findings:

    Key observations:

    • USB power (VBUS) reaches U10 (boost converter) and is correctly boosted to ~5V (V5V).

    • U11 (buck converter) successfully generates ~3.0 V (VREG) from V5V.

    • Power from VREG is gated through U13 then U14 (TCK106AG load switchs), which is controlled by the VSUPPLY_EN signal.

    • VSUPPLY_EN fails to reach a valid logic-high level except briefly (~2.6 V) during startup in “VDD” switch mode. Once the switch is moved to “USB,” or if power is cycled with the switch in USB mode, VSUPPLY_EN drops to 0.4 V or 0 V and does not recover unless the board is fully power-cycled in with SW9 in VDD mode.

    • The VSUPPLY_EN net is pulled low by Q9, an NMOS transistor whose gate is driven by the drain of Q3, another NMOS or by the switch SW9 its hard to tell if Q3 is overriding the VDD_NRF_SENSE net causing the collapse I am seeing.

    • Q3’s gate is tied to VSUPPLY_EN which can be grounded out by Q9.  It's not readily apparent to me what the Q3/Q9 circuit is supposed to do but it is definitely able to be put in a strange state it cannot recover from unless you power cycle the board.  (strange state meaning it goes to 2.6v or 0.4v and decays to 0v never to recover until you power cycle SW8)

    • When VDD_NRF_SENSE changes state (e.g., when USB mode is selected), Q9 turns ON, pulling Q3’s gate low and turning it OFF — which in theory should allow VSUPPLY_EN to rise.

    • However, the signal behavior does not align cleanly: VSUPPLY_EN consistently fails to rise above 0.4 V in USB mode, and the board never fully powers up or enumerates.

    • It appears that the logic between VDD_NRF_SENSE, Q9, and Q3 is preventing U12 from enabling, which leaves VDD and the debug MCU under-powered. (IMCUs VDD ~ 1.6v)

    At this point, the board appears to be blocked by internal power control logic that fails to enable the core voltage rail (VDD_IMCU) necessary for USB operation. It does not draw high current, it just locks itself out.  I’ve confirmed that all power rails before the switching logic are functional and that none are shorted to ground or any other net.

    One other bit of information, since my engineering goal is to talk to more than one chip over bluetooth, I bought a second board.  I plugged the new one in today and it powered right up without issue and enumerates on the USB bus on the exact same cables and computer. 

    Please let me know if you’d like additional signal traces, or whether this board may be eligible for RMA.

    Best regards,

    Peter

  • Peter - I am the RSM for Texas. Please send me an email at [email protected] with your address and I will ship you a new kit. 

Reply Children
No Data
Related