ArtInChip D125 cJTAG Debugging with FT232H and OpenOCD
This article documents a board-verified ArtInChip (匠芯创) D125 E907 / FT232H / SiFive OpenOCD 2020.11.0 connection, with configuration, captured logs and a GDB attach guide. The project confirms physical-board validation of the cJTAG connection: D0 → PA11 (TCKC), D1/D2 → PA10 (TMSC).
Scope
The project confirms that the cJTAG wiring and OpenOCD connection were tested on hardware; the logs record IDCODE/DTMCS reads and CPU examination. This does not establish validation of every step in the added GDB guide. This setup uses the two-wire mode enabled by ftdi_oscan1_mode on, not ordinary four-wire JTAG. Other OpenOCD builds or FTDI modules are not automatically compatible.
Hardware connections
D125 pins
The supplied excerpt from the official D125 datasheet lists two pin groups using mux function 8. Select one group according to board routing and firmware pinmux; do not connect both groups simultaneously. Package pin numbers below are not board header numbers.
| cJTAG signal | MCU pin | D125CxS package pin | D125ExS package pin |
|---|---|---|---|
| JTAG_MS / TMSC | PA10 | 79 | 53 |
| JTAG_CK / TCKC | PA11 | 80 | 54 |
| JTAG_MS / TMSC (alternative) | PC0 | 61 | 23 |
| JTAG_CK / TCKC (alternative) | PC5 | 66 | 28 |
FT232H wiring
| FT232H signal | Connection | Purpose |
|---|---|---|
| D0 / ADBUS0 | D125 JTAG_CK: PA11 or PC5 | Debug clock output |
| D1 / ADBUS1 | D125 JTAG_MS: PA10 or PC0 | Data output from FT232H to target |
| D2 / ADBUS2 | Same JTAG_MS node | Data input to FT232H from target |
| GND | D125 GND | Common ground |
In this setup, D1 and D2 are tied at the same JTAG_MS node. Use D0 → PA11 and D1/D2 → PA10 for the PA group, or D0 → PC5 and D1/D2 → PC0 for the PC group.
Wiring correction
The earlier text reversed the PA10/PA11 clock and data assignments. It now correctly states PA11 for clock and PA10 for data. The project confirms physical-board validation of cJTAG debugging; this documentation correction should not be described as an untested connection. Other packages, the PC pin group and different adapters still require hardware-specific checks.
Do not connect D0 and the D1/D2 pair to the same pin. The D1/D2 tie is specific to this adapter and driver mode, not a general JTAG wiring rule.
Power off before wiring. Verify the module's VCCIO and signal levels against the target IO domain. USB supply voltage is not the IO voltage; do not apply 5 V to debug signals or connect an adapter power output without checking the board power design. Power the target normally.
The retained TMS and JTAG_SEL layout definitions do not instruct you to wire D3 or JTAG_SEL to the target JTAG_MS or JTAG_CK. Check the adapter schematic and driver implementation before changing hardware.
OpenOCD configuration
Save as openocd-d125-ft232h.cfg, or download the configuration.
Markdown asterisks and escaped underscores from the pasted source have been removed. The original bindto 0.0.0.0 is changed to bindto 127.0.0.1 for local-only debugging; key probe parameters are preserved. Prefer an SSH tunnel for remote access rather than exposing debug ports.
# D125 E907 / current FTDI adapter, SiFive OpenOCD 2020.11.0.
# Preserve the interface layout used for the successful TAP/DTMCS scans.
# This does not establish electrical compatibility with other FTDI modules.
# Wiring (mux function 8): D0 -> PA11; D1/D2 tied -> PA10; common GND.
# Alternative group: D0 -> PC5; D1/D2 tied -> PC0. Use one group only.
adapter driver ftdi
ftdi_vid_pid 0x0403 0x6014
ftdi_channel 0
# For multiple adapters, uncomment and fill in the actual serial number:
# ftdi_serial "YOUR_FT232H_SERIAL"
ftdi_oscan1_mode on
transport select jtag
ftdi_layout_init 0x0008 0x001b
ftdi_layout_signal TCK -data 0x0001
ftdi_layout_signal TDI -data 0x0002
ftdi_layout_signal TDO -input 0x0004
ftdi_layout_signal TMS -data 0x0008
ftdi_layout_signal JTAG_SEL -data 0x0100 -oe 0x0100
if {![info exists ADAPTER_KHZ]} { set ADAPTER_KHZ 100 }
adapter speed $ADAPTER_KHZ
reset_config none
# Observed on this board: IDCODE=0x10000b6f, DTMCS=0x000040a1.
# Keep standard IR validation enabled: the initial capture warning remains visible.
jtag newtap d125 cpu -irlen 5 -expected-id 0x10000b6f
target create d125.cpu riscv -chain-position d125.cpu -defer-examine
# Local-only default; original test configuration used 0.0.0.0.
bindto 127.0.0.1
gdb_port 3333
telnet_port 4444
tcl_port disabled
gdb_breakpoint_override hard
# No flash algorithm, RAM initialization, hardware reset or automatic halt.
# The old driver fails its initial IR-chain validation on this connection.
# Validate explicit register reads before asking the RISC-V driver to examine.
init
irscan d125.cpu 0x01
set d125_id [drscan d125.cpu 32 0]
irscan d125.cpu 0x10
set d125_dtmcs [drscan d125.cpu 32 0]
echo "D125 IDCODE=0x$d125_id DTMCS=0x$d125_dtmcs"
if {$d125_id ne "10000b6f" || $d125_dtmcs ne "000040a1"} {
error "D125 probe mismatch; refusing CPU examination."
}
d125.cpu arp_examine
echo "D125 CPU examination complete; GDB port 3333. Attach GDB to halt."No Flash programming algorithm, RAM initialization or hardware-reset sequence is provided. The script does not explicitly halt the CPU. The recorded 100 kHz is a starting speed, not a maximum-speed claim.
Run OpenOCD
From the configuration directory in Windows PowerShell:
.\OpenOCD-SiFive-0.10.0\bin\openocd.exe -f .\openocd-d125-ft232h.cfgCheck the executable's startup banner: the folder's 0.10.0 name and the build's 2020.11.0 identifier are not interchangeable.
To try a lower clock, define the variable before loading the file:
.\OpenOCD-SiFive-0.10.0\bin\openocd.exe -c "set ADAPTER_KHZ 50" -f .\openocd-d125-ft232h.cfgProject-supplied log
This is the original connection record, not a new test performed for this article:
Open On-Chip Debugger 0.10.0+dev (SiFive OpenOCD 0.10.0-2020.11.0)
Licensed under GNU GPL v2
For bug reports:
https://github.com/sifive/freedom-tools/issues
force hard breakpoints
Info : clock speed 100 kHz
Info : JTAG tap: d125.cpu tap/device found: 0x10000b6f (mfg: 0x5b7 (<unknown>), part: 0x0000, ver: 0x1)
Error: d125.cpu: IR capture error; saw 0x00 not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : starting gdb server for d125.cpu on 3333
Info : Listening on port 3333 for gdb connections
D125 IDCODE=0x10000b6f DTMCS=0x000040a1
Info : datacount=1 progbufsize=2
Info : Examined RISC-V core; found 1 harts
Info : hart 0: XLEN=32, misa=0x40901125
D125 CPU examination complete; GDB port 3333. Attach GDB to halt.
Info : tcl server disabled
Info : Listening on port 4444 for telnet connectionsInterpreting the result
- The recorded IDCODE is
0x10000b6f; the explicit DTMCS read is0x000040a1. - CPU examination is attempted only after both values match. Do not remove the guard to force examination on a mismatch.
- One RV32 hart was examined, but the IR capture error remains. This is not a clean scan-chain validation.
- Successful explicit reads after the initial failure describe this particular session, not a universal workaround for IR errors.
- A listening GDB port does not establish successful halt, register access, breakpoints or Flash programming.
Connect with GDB
Use a GDB build compatible with the target RISC-V architecture and an ELF matching the running firmware, including debug information. The executable name below is illustrative; select your SDK's actual RV32-capable GDB.
Keep OpenOCD running and launch a second terminal:
riscv64-unknown-elf-gdb.exe .\firmware.elfAt the GDB prompt:
target extended-remote 127.0.0.1:3333
monitor halt
info registers
x/8i $pc
btOpening the ELF loads host-side symbols; it does not program the target. Attachment and halting affect execution, so put motors and other controlled hardware into a safe state first. Backtraces depend on symbols, compiler optimization and execution state.
For a breakpoint, replace the placeholder with a real firmware function:
hbreak your_function
continuePress Ctrl+C to request an interrupt while running. Hardware breakpoint resources are limited. A breakpoint does not rerun an initialization function that has already completed.
Before finishing, remove breakpoints and explicitly resume if that is the intended target state:
delete breakpoints
monitor resume
detach
quitDo not blindly use load, run or monitor reset halt: this configuration does not establish download, RAM initialization or board-reset support.
General command references: OpenOCD GDB guide and general commands. These references do not validate the D125 wiring or this old driver build.
Frequently asked questions
How do PA10 and PA11 connect to an FT232H?
PA10 is JTAG_MS / TMSC and connects to the shared D1/D2 data node. PA11 is JTAG_CK / TCKC and connects to D0. Select mux function 8 and connect grounds.
Has this ArtInChip D125 cJTAG setup been tested on hardware?
Yes. The project confirms board validation, with logs for IDCODE, DTMCS and RV32 CPU examination. This does not automatically validate other adapters, every GDB operation or Flash programming.
Can this configuration program D125 Flash?
No Flash algorithm is provided. This is a connection and CPU-examination configuration with a separate GDB attach guide, not a Flash programming recipe.
Related guide: ArtInChip D126 Wi-Fi / BLE.
Troubleshooting
| Symptom | Check first |
|---|---|
| FTDI device not found | USB enumeration, VID/PID, driver and other applications; select a serial number for multiple adapters |
| Unknown ftdi_oscan1_mode | OpenOCD fork and build version |
| IDCODE / DTMCS mismatch | PA10/PA11 wiring, ground, IO levels, pinmux, target power and clock speed |
| IR capture error | Preserve logs and assess explicit reads and CPU examination; do not simply disable validation |
| GDB cannot connect | OpenOCD process, port 3333 availability and local address |
| Halt or register access fails | Debug state, link stability, firmware pin multiplexing and old-driver compatibility |
| Wrong symbols or backtrace | Matching ELF and debug information |
