J-Link Commander CLI Scripting for Indian Production Lines and CI Test Rigs

Indian engineering teams that have only ever driven a J-Link probe through an IDE often miss the fact that SEGGER Microcontroller GmbH ships a complete set of command-line companion tools in every J-Link Software Pack. Those CLI tools, J-Link Commander, J-Link GDB Server, J-Link RTT Logger, J-Link Remote Server, and a few others, are the right tools for production-line automation, hardware-in-the-loop CI test rigs, and headless bring-up. They are free to use with any licensed J-Link probe, they run on Linux, macOS, and Windows, they are documented in the SEGGER wiki, and they are the bridge between an IDE-driven developer workflow and an automated shop-floor or Jenkins-driven pipeline. GSAS Micro Systems is an authorized engineering partner in India for SEGGER Microcontroller GmbH and supplies J-Link probes, Flasher hardware, and CI/production integration support to Indian teams in Bengaluru, Chennai, Hyderabad, Pune, Mumbai, and Delhi NCR.

This post walks through what J-Link Commander can do, the other CLI tools every Indian production engineer should know, two detailed Indian use cases (an EMS production line and a CI HiL rig), and where to escalate from J-Link Commander to Flasher hardware when the volumes demand it.

J-Link Commander: the CLI you should know

J-Link Commander is the command-line companion to every J-Link probe. The binary is JLinkExe on Linux and macOS, and JLink.exe on Windows. It is included in every SEGGER J-Link Software Pack download, if you already have the pack installed, the tool is already on your machine at /opt/SEGGER/JLink/JLinkExe (Linux) or C:\Program Files\SEGGER\JLink\JLink.exe (Windows).

What J-Link Commander can do, in plain terms:

• Connect to a target over SWD or JTAG. The connect command asks for the device, the interface, and the speed, and brings up the debug connection.
• Erase flash. The erase command clears sectors or the whole flash.
• Load a binary, hex, or ELF image. loadbin filename address writes a raw binary. loadfile filename loads an ELF, hex, or srec with addresses extracted from the file. verifybin checks the programmed content against a host file.
• Read and write memory and registers. mem32, mem16, mem8 read memory at arbitrary widths. w4, w2, w1 write memory. regs dumps the core register set.
• Reset the target. The r command issues a reset with the strategy configured in the probe settings, hardware, software, or vector-reset.
• Halt and resume the CPU. h halts, g resumes.
• Dump memory regions to a file. savebin filename address length writes a region of target memory to a host file.
• Run a script file. The -CommandFile option points J-Link Commander at a text file of commands. Every interactive command is scriptable. This is how production lines and CI rigs drive the probe.
• Output is plain text. Every response is ASCII that a shell script, a Python driver, or grep can parse.

That list is the ~80% of J-Link Commander that matters for production and CI. The full reference is in the SEGGER wiki under the J-Link User Guide.

The companion CLI tools every Indian production engineer should know

J-Link Commander is not the only CLI tool in the J-Link Software Pack. The full set:

J-Link Commander (JLinkExe / JLink.exe). Interactive and scripted control of the probe. The workhorse.

J-Link GDB Server (JLinkGDBServer / JLinkGDBServerCL). Runs a GDB remote protocol server on a TCP port that external GDB clients (the IDE, Ozone, arm-none-eabi-gdb, VS Code’s cortex-debug extension) can attach to. The CL variant is the command-line-only build, the right choice for headless CI runners.

J-Link RTT Logger (JLinkRTTLogger). The headless RTT capture tool. Point it at a target and it streams RTT output to a file until you stop it. This is the right tool for long-duration soak tests and production-line functional tests, it runs for hours or days unattended and produces a log file you can post-process.

J-Link RTT Viewer (JLinkRTTViewer). The interactive RTT terminal. Shows RTT output in a scrolling window and lets you send input over RTT. The GUI cousin of JLinkRTTLogger.

J-Link RTT Client (JLinkRTTClient). A thin Telnet-style client that attaches to an already-running J-Link GDB Server or J-Link Commander RTT channel.

J-Link SWO Viewer (JLinkSWOViewer). The CLI tool for capturing SWO trace output, printf-over-ITM, DWT event trace, exception trace. Runs headless and writes to a file.

J-Link Remote Server (JLinkRemoteServer). Shares a J-Link probe over a TCP network so that another J-Link Commander instance (or an IDE) on a different machine can drive it. This is how a CI runner in a datacentre reaches a probe physically attached to an HiL rig PC on the lab bench, and how a small Indian team can share one J-Link PRO across multiple developers without swapping cables.

J-Flash and J-Flash Lite. Project-file-driven flash programmers. J-Flash is the full tool, project configuration, flash algorithms, erase/program/verify workflows. J-Flash Lite is a stripped-down version. Both expose a command-line interface (JFlashExe / JFlashLite) for scripted use.

Every tool above ships in the J-Link Software Pack. J-Flash Lite and the rest of the tools need no extra licensing beyond the probe itself; the full J-Flash requires a license, which is included with J-Link PLUS and above or available as a paid upgrade for J-Link BASE.

The Indian production line use case

Scenarios in this article are illustrative, common patterns Indian engineering teams encounter, not specific named customers.

A typical Bengaluru-area consumer IoT brand contracts a mid-sized EMS in the same city to assemble a wearable product at 300 units per day per line. The board carries an nRF5340 with a small BOM of sensors and a battery-management IC. The EMS uses a fixture PC on the line running a Python test driver. The workflow for each board:

1. Board insertion. A fixture sensor detects that a board has been placed on the test fixture. The Python driver triggers.

2. Erase + program + verify. The Python driver invokes JLinkExe -CommandFile flash_and_test.jlink. The script file contains:

• connect with the device set to nRF5340_xxAA, interface SWD, speed 4000 kHz
• erase to clear the flash
• loadfile firmware.hex to programme the application
• verifybin firmware.bin 0x00000000 as a post-programming read-back check
• r to reset
• q to exit

Exit status from JLinkExe is captured by the Python driver; non-zero means the board failed the programming step and is diverted to the rework bin.

3. Unique device-ID capture. Before exiting, the script reads a known memory region (the nRF5340’s FICR device-ID registers) with mem32 and the output line is parsed by the Python driver. The device ID plus the programming timestamp and the operator ID are uploaded to the EMS MES (manufacturing execution system).

4. Functional self-test. The Python driver starts JLinkRTTLogger as a background process, targeted at the same probe. The script kicks off the firmware’s self-test routine by writing a sentinel value to a known memory address via JLinkExe. The firmware sees the sentinel, runs the self-test, and prints TEST_PASS or TEST_FAIL followed by a fault code over RTT. The Python driver tails the RTT log, waits for the pass/fail line, and returns the result.

5. Operator signal. A green light on the operator station means the board passed; a red light means it failed and carries the fault code for diagnosis.

For Bengaluru consumer IoT lines at 300 units/day, this is a workable setup. The probe is a J-Link PRO (for its reliability under continuous use), the fixture PC runs Linux with the J-Link Software Pack pre-installed, and the Python driver and the .jlink script are version-controlled in the EMS’s production SOP repository. When the firmware image changes, the production engineer updates the hex in the fixture’s file share and the next board gets the new image.

For higher volumes, say, a Pune automotive Tier-1 running 2000 units/day of an ECU with parallel programming across 10 targets simultaneously, the right answer is not J-Link Commander on a fleet of fixture PCs; it is Flasher ATE2, SEGGER’s production-grade parallel programmer. J-Link Commander is the right tool for low-to-medium volumes where a host PC on the line is acceptable.

The CI HiL rig use case

A typical Pune-area Tier-1 automotive supplier runs a Jenkins CI pipeline for a body-control ECU. The developer workflow builds with Embedded Studio and emBuild on a Linux Jenkins agent, produces a signed image via emSecure, and then needs to verify the image on real hardware before merging.

The HiL rig setup:

• A dedicated rig PC running Linux in the lab, attached to a J-Link PRO probe and an ECU-under-test with CAN, UART, and power rails controlled by a benchtop programmable supply
• Jenkins SSHes into the rig PC as part of the post-build stage

The rig PC pipeline:

1. Receive the freshly built signed hex from the Jenkins artefact store
2. Run JLinkExe -CommandFile bringup.jlink to erase, programme, verify, and reset the ECU
3. Start JLinkRTTLogger in the background, targeting the same probe, capturing RTT output to rtt.log
4. Run the Python test driver which issues CAN messages and asserts ECU responses
5. After the functional test completes, stop JLinkRTTLogger and archive rtt.log as a Jenkins artefact
6. Return pass/fail to Jenkins

The clean division of labour: JLinkExe handles the flashing, JLinkRTTLogger handles the observability, the Python driver handles the functional assertions, and Jenkins handles the orchestration and reporting. None of these steps touch an IDE.

For teams where the rig PC is in one lab and the developer is in another building, J-Link Remote Server sits on the rig PC so that developers can reach the probe from their workstation for interactive debugging outside of CI hours.

Indian use case patterns at a glance

• Bengaluru consumer IoT EMS: Parallel J-Link Commander scripts on bench PCs for assembled-board validation at 200-500 units/day per line
• Pune automotive Tier-1 HiL: JLinkExe + JLinkRTTLogger driven from Jenkins for per-commit regression on a body-control ECU
• Chennai medical device production: J-Link Commander for ISO 13485-traceable per-unit programming records; pair with Flasher Secure
• Hyderabad defence electronics small-batch production: J-Link Commander as a quick alternative to Flasher-class hardware for 20-100 unit runs

When to escalate from J-Link Commander to Flasher

J-Link Commander is the right tool when the line has a host PC per fixture, the line runs at low-to-medium volumes, and each board takes seconds to programme. Signals that you have outgrown it: more than 500-1000 units/day, more than 2-3 targets being programmed in parallel from one host, a need for standalone operation without a host PC, or a need for authenticated encrypted programming with central authorisation. At that point the answer shifts to Flasher Pro, Flasher ATE2 for parallel production, or Flasher Secure for authenticated production.

Further reading

• SEGGER J-Link product page at segger.com, authoritative product documentation
• SEGGER J-Link User Guide (UM08001), PDF reference for the full CLI command set
• SEGGER J-Link BASE at GSAS, J-Link PLUS, J-Link ULTRA, J-Link PRO
• Choosing the right J-Link model for India, model selection guide
• SEGGER J-Link STM32 complete guide for India, STM32-specific workflow
• SEGGER Flasher ATE2 for Indian EMS production, when volumes outgrow J-Link Commander
• SEGGER Flasher Secure encrypted firmware, authenticated production workflow
• SEGGER Cortex-M HardFault debug with RTT, RTT observability companion
• SEGGER at GSAS

Buy J-Link probes and Flasher hardware in India from GSAS

GSAS Micro Systems is an authorized engineering partner in India for SEGGER Microcontroller GmbH and supplies J-Link BASE, J-Link PLUS, J-Link ULTRA, J-Link PRO, J-Trace PRO, and the full Flasher product line to Indian engineering teams. Whether you are a Bengaluru consumer IoT EMS building a fixture-PC production line, a Pune automotive Tier-1 wiring a J-Link probe into a Jenkins HiL rig, a Chennai medical device team building ISO 13485-traceable programming records, or a Hyderabad defence electronics house running low-volume production, we will help you pick the right probe for the volume, scope the CLI integration, and arrange a workshop with a SEGGER application engineer. Contact us at any of our Bengaluru, Chennai, Hyderabad, Delhi NCR, Mumbai, or Pune offices, or visit our SEGGER India partner page for the full portfolio.