Feature Request: Reset Detection via SWD/JTAG Connection Health Monitoring

[fxd0h]

Feature Request: Reset Detection via SWD/JTAG Connection Health Monitoring

Problem

Currently, detecting device resets requires either:

1. Firmware-dependent methods (monitoring data intervals) - unreliable
2. Accessing J-Link DLL directly via _dll attribute - not stable API

Solution

Add a method to check device connection health by reading hardware resources that are always accessible via SWD/JTAG:

• IDCODE (device identification code) - Universal, works for all architectures
• CPUID register (ARM Cortex-M at 0xE000ED00) - Architecture-specific, only for ARM Cortex-M
• Processor registers (e.g., R0) - Architecture-dependent but registers always exist

Note: CPUID address (0xE000ED00) is NOT universal - it's specific to ARM Cortex-M architecture. For other architectures (Cortex-A, RISC-V, etc.), CPUID read should be skipped. The method remains reliable because IDCODE and register reads are universal.

If all reads fail → reset detected. If any read succeeds → device is accessible.

Proposed API

# Option 1: Simple health check
is_accessible = jlink.check_connection_health()
# Returns True if device accessible, False if reset/disconnected

# Option 2: Read IDCODE directly
try:
    idcode = jlink.read_idcode()
    print(f"IDCODE: 0x{idcode:08X}")
except pylink.errors.JLinkException:
    print("Device reset detected")

# Option 3: Detailed health status
health = jlink.check_connection_health(detailed=True)
# Returns: {
#     'idcode': 0x12345678 or None,
#     'cpuid': 0x410FC241 or None,
#     'register_r0': 0x00000000 or None,
#     'all_accessible': True/False
# }

Benefits

• ✅ Firmware-independent: Works regardless of firmware reporting intervals
• ✅ Reliable: Uses hardware-level resources always accessible via SWD/JTAG
• ✅ Fast: Can check every 200ms for quick reset detection
• ✅ No false positives: Doesn't depend on firmware behavior

Real-World Validation

Successfully implemented in my production RTT Monitor application:

• Detects resets within 200ms
• Zero false positives (tested with firmware reporting every 5 seconds)
• Distinguishes reset (< 2s) from disconnection (> 2s)
• Works with any firmware implementation

Implementation Details

Requires wrapping JLINKARM_ReadIdCode() from J-Link SDK. Can leverage existing memory_read32() and reg_read() methods.

Reference Implementation: See tools/rtt_monitor/rtt_monitor.py in my repository for working example.

Current Workaround

# Access internal DLL (not stable)
dll = jlink._dll
idcode = dll.JLINKARM_ReadIdCode() if hasattr(dll, 'JLINKARM_ReadIdCode') else None
cpuid_ok = False
try:
    jlink.memory_read32(0xE000ED00, 1)
    cpuid_ok = True
except:
    pass
# ... check if any succeeded ...

This works but relies on internal _dll attribute which may change.

[hkpeprah]

Do you have a link to the RTT example? Could you give some examples about the use case for this? I assume if one wants to take action on a reset, they want to do it immediately (i.e. actively polling for reset), but I'm not sure if one can read memory/registers actively like that when the target is running.

[fxd0h]

Yes! Here are the examples:

Examples:

• RTT Monitor with auto-reconnection - This one shows active polling
• Full README with all 6 examples - Complete use cases

About reading memory/registers while the target is running:

Yes, you can poll actively while the CPU is running. That's the point of this method.

The check_connection_health() method checks in this order:

1. IDCODE (via TAP controller) - This is the lowest level SWD/JTAG read. If SWD is broken (reset/disconnect), this fails first.
2. CPUID register (0xE000ED00) - Memory-mapped, always accessible on ARM Cortex-M when SWD is working, even when CPU is running
3. Processor registers (e.g., R0) - Only read if CPU is halted, but not needed since IDCODE + CPUID are enough

How it works:

When a reset happens, the SWD connection itself becomes temporarily unavailable. The IDCODE read (which is at the TAP controller level) fails immediately, so we detect the reset right away. Once the device comes back online, IDCODE succeeds again.

# Active polling every 200ms - works fine with CPU running
while True:
    if not jlink.check_connection_health():
        # Reset detected - SWD connection was lost/broken
        handle_reset()
    time.sleep(0.2)

The method tries IDCODE first - if SWD is broken (reset/disconnect), this fails immediately. CPUID and registers are only checked if IDCODE succeeds (meaning SWD is working).

Real use cases:

1. RTT Monitor - Auto-reconnect when device resets during monitoring
2. Test Automation - Detect resets during automated tests
3. Production Monitoring - Background monitoring for unexpected resets
4. Flash Verification - Verify device resets properly after programming

Validation:

I've been using this in production with:

• 200ms polling interval
• Zero false positives (tested with firmware reporting every 5 seconds)
• Distinguishes reset (< 2s) from disconnection (> 2s)
• Works with any firmware

The example 1 (example_1_rtt_monitor.py) shows exactly this - active polling every 200ms while CPU is running, detecting when SWD connection breaks (reset) and automatically reconnecting RTT.

[fxd0h]

Following up on this - I've implemented the reset detection and it works great!

One thing I noticed: the reconnection logic after reset detection is something that many users will need. Would it make sense to add this directly to pylink?

Proposal: Add an optional auto_reconnect=True parameter to rtt_start() that automatically handles RTT reconnection after resets are detected via check_connection_health().

The logic I'm using (see example_1_rtt_monitor.py) includes:

• Exponential backoff for reconnection attempts
• Device stability verification before attempting RTT reconnect
• Handling firmware initialization delays

This would make it much easier for users - they wouldn't need to implement this logic themselves. What do you think?

[hkpeprah]

Thanks for the examples. I think for this to be used, it would have to be implemented in a manner similar to this example you have here. Namely, we would have to:

1. Spin up a background worker.
2. Have the background worker periodically check for a "reset signal".
3. Have the background worker invoke a callback on detection.

Then to have that used with auto_reconnect, the rtt_start() would need to have the background worker trigger re-connection after a reset is detected by passing its own callback. I'm not sure if we need a connection_health() method, given, as you outlined, it wouldn't be usable across all targets, but a reset API would be.

One issue I see with a background thread is it's not inherently thread safe. If we're handling RTT re-start while the user is in another thread doing something else, then it could lead to unexpected behaviour. To that end, I think we would have to create a thread-safe version of the Library() such that a background worker (or task) could "lock" the library while performing tasks.

Alternatively, we could just implement the signal and let the caller handle that in a thread-safe manner from their own main thread.

I'm leaning more towards the second, as I don't want to break anyone's workflow today that might rely on the instance not having locks around accesses. That would mean de-scoping the auto-reconnect, but the caller could signal their main thread using a semaphore to handle re-connection. So implementing something like set_reset_handler().

[fxd0h]

that also sounds good to me, maybe mimicking what segger do , a server listening for ipc or telnet connections juggling with the clients /* Jumping Flowers */

…

On Mon, 10 Nov 2025 at 19:33 Ford Peprah ***@***.***> wrote: *hkpeprah* left a comment (square/pylink#252) <#252 (comment)> Thanks for the examples. I think for this to be used, it would have to be implemented in a manner similar to this example <https://github.com/fxd0h/pylink-nrf54-rttFix/blob/feature/252-reset-detection-swd-jtag/issues/252/example_3_production_monitoring.py> you have here. Namely, we would have to: 1. Spin up a background worker. 2. Have the background worker periodically check for a "reset signal". 3. Have the background worker invoke a callback on detection. Then to have that used with auto_reconnect, the rtt_start() would need to have the background worker trigger re-connection after a reset is detected by passing its own callback. I'm not sure if we need a connection_health() method, given, as you outlined, it wouldn't be usable across all targets, but a reset API would be. One issue I see with a background thread is it's not inherently thread safe. If we're handling RTT re-start while the user is in another thread doing something else, then it could lead to unexpected behaviour. To that end, I think we would have to create a thread-safe version of the Library() such that a background worker (or task) could "lock" the library while performing tasks. Alternatively, we could just implement the signal and let the caller handle that in a thread-safe manner from their own main thread. I'm leaning more towards the second, as I don't want to break anyone's workflow today that might rely on the instance not having locks around accesses. That would mean de-scoping the auto-reconnect, but the caller could signal their main thread using a semaphore to handle re-connection. So implementing something like set_reset_handler(). — Reply to this email directly, view it on GitHub <#252 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANUYBNCSD4LFR2ZKBZDGAD34EHB3AVCNFSM6AAAAACLWCP7PWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMJUGE3TQOJTGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>