Board: nRF9151 DK, PCA10201 rev 1.1.0
Serial number: 1052048398
J-Link OB firmware: J-Link OB-nRF5340-NordicSemi, compiled Jul 8 2025 10:15:34
NCS / Toolchain: nRF Connect SDK v3.4.0 (bundled toolchain), Toolchain Manager
nrfutil device: 2.19.3 / nrf-device-lib 0.22.21 / SEGGER J-Link JLink_V9.24a
nrfjprog: bundled with nRF Command Line Tools
--- Symptom ---
No data whatsoever is received on either VCOM0 (COM3) or VCOM1 (COM4) via USB-CDC,
regardless of firmware, tool, cable, or USB port used. SWD programming, verification,
reset, and Board Configurator communication all work perfectly on the same USB
connection, ruling out a dead/undetected board.
--- What was tested (all with identical result: 0 bytes received) ---
1. Custom minimal Zephyr app (board target nrf9151dk/nrf9151/ns, sysbuild+TF-M),
printk() loop every 2s, CONFIG_CONSOLE=y / CONFIG_UART_CONSOLE=y in prj.conf.
Built and flashed via `west build` + `nrfjprog --program ... --chiperase --verify --reset`
(tfm_merged.hex), and separately via VS Code nRF Connect extension (nrfutil runner).
Both build+flash+verify reported success.
2. Official `zephyr/samples/hello_world` sample from the SDK tree, same board target
(nrf9151dk/nrf9151/ns), same NCS v3.4.0 install. Build+flash+verify reported success.
Same result: no output.
3. Monitored with nRF Connect for Desktop "Serial Terminal" v1.6.5, both COM3 and COM4,
115200 baud / 8N1 (default settings), across multiple board resets (via
`nrfjprog --reset` and via re-flash-triggered reset). Console remains empty in both
cases; only local input echo appears, no data from the device.
4. Two different USB cables and two different USB ports on the host PC tested —
identical result each time.
5. `nrfjprog --readregs` / nRF Connect Programmer both report
"Application core protection status 'NRFDL_PROTECTION_STATUS_ALL'" after every
reset+run (AP-Protect engaged) — consistent with TF-M's normal secure-boot lock,
not itself the issue. Cleared via `nrfjprog --recover` before every reflash attempt,
which completes successfully each time ("Writing image to disable ap protect" / OK).
6. In Board Configurator: VCOM0 and VCOM1 "Connect port" are both enabled (toggled ON),
"Write config" completes successfully (confirmed in the app's log: "Configuration
written").
7. VDD (nPM VOUT1, labeled "VDD GPIO" on header P20) tested at both 1.8V and 3.3V via
Board Configurator. After setting 3.3V + Write config + reset, physically measured
with a multimeter at P20 pin "VDD GPIO" vs the adjacent GND pin: **3.36V**, matching
the configured value. This rules out a stuck/incorrect VDD_GPIO rail as the cause
(unlike a similar-looking unresolved case: devzone.nordicsemi.com/f/nordic-q-a/128774).
8. Devicetree confirmed correct: `nrf9151dk_nrf9151_ns.dts` / common dtsi has
`&uart0 { status = "okay"; current-speed = <115200>; ... }` with
`zephyr,console = &uart0;`, matching documented default routing (UART0 = VCOM0,
non-secure/application console).
--- What works normally ---
- SWD connection, chip ID detection, flashing, verification, reset — all succeed
consistently via both nrfjprog and nrfutil.
- Board Configurator detects the board, reads/writes configuration correctly (voltage
change was physically verified with a multimeter, confirming IMCU communication and
control over the SiP's power rails is functional).
--- Question ---
Given that SWD/programming/Board Configurator communication is fully functional and
VDD_GPIO is confirmed correct, but literally zero bytes are ever received on VCOM0 or
VCOM1 regardless of firmware (own app vs. official sample) — is this indicative of a
hardware fault specific to this unit (e.g. UART bridge on the interface MCU side, or a
solder-bridge/board-revision-specific routing issue on PCA10201 rev 1.1.0)? Is there a
board-controller firmware update or a specific solder bridge (SB) I should check for
this exact revision? Happy to provide additional logs, close-up board photos, or run
any specific diagnostic command.
