Resume a Halted Target over J-Link with pylink: restart vs reset for true debugger-like continue

Learn why pylink reset restarts from the entry point and how restart resumes a halted core over J-Link. Get debugger-like continue behavior with correct API.

Resuming a halted target over J-Link with pylink can be confusing at first glance. If you try to keep execution going from the current program counter and reach for reset, you will see the core start from its entry point instead. Here is the minimal distinction that matters and how to apply it correctly.

Problem overview

You need a debugger-like continue behavior from pylink while the CPU is halted. The first instinct is to call reset, but according to the documentation it restarts execution from the entry point, not from the current halted location.

Problematic snippet

The following fragment illustrates the behavior that does not match a debugger’s continue.

import pylink

probe = pylink.JLink()
# ... target is already halted at some PC ...

# This starts the core from its entry point, not from the halt location.
probe.reset()

What’s actually going on

In pylink, reset is intended to start the core from its entry point. If you need to simply resume execution from the current halted state, reset is the wrong tool for the job. The method aligned with a continue-like action is different.

Solution

Use restart to resume the core when it is halted. This is the behavior you want when replicating a debugger’s continue.

import pylink

adapter = pylink.JLink()
# ... target is already halted at the desired breakpoint/PC ...

# This resumes execution from the current halted point.
adapter.restart()

Why this matters

Choosing between reset and restart directly impacts where execution continues. If you intend to proceed from the current halted state, invoking reset will unexpectedly jump to the entry point. Using restart avoids that mismatch and aligns with the intended resume flow.

Takeaways

If the goal is to run from the current halted point, call restart. Avoid reset in this scenario, as it starts the core from its entry point by design. Keeping this distinction in mind saves time and prevents surprises during low-level debugging with pylink and J-Link.