Unexpected resets when debugging netX 90 with netX Studio - how to fix this?

Q

When debugging a netX 90 application with netX Studio, we observe that the netX 90 gets reset several times while the debug session is started. A "hidden" reset is performed even when the debug settings mode is set to 'Attach', which is completely unexpected. Is that intended? Is there a workaround?

A

This behavior is not intended. The expected behavior depending on the debug settings mode is this:

Run mode - attach to the running CPU, perform a reset and then halt the CPU at the first instruction
Attach mode - attach to the running CPU and halt it at the current instruction

In netX Studio V1.0900 the unexpected resets are caused by three unrelated issues, all of which have been addressed with the maintenance release netX Studio V1.0910:

Spike at JTAG SRST signal causes an unexpected reset on attach with OpenOCD
More than one reset command is executed while the debug session is being started
The hardware reset performed by OpenOCD asserts SRST twice resulting in a "double reset"

If you are affected by any of these issues, please see the resolutions below.

Spike at JTAG SRST signal causes an unexpected reset on attach with OpenOCD

This has been observed with the netX 90 evaluation boards using the on-board FTDI chip. The spike was caused by using the wrong parameters for the ftdi_layout_init command, which resulted in an unexpected reset when OpenOCD attaches and starts the communication over the JTAG interface.

The parameters were adjusted and the spike issue is fixed in netX Studio V1.0910.

More than one reset command is executed while the debug session is being started

When starting a debug session in Run mode, netX Studio would execute more than one 'reset' command via OpenOCD.

With netX Studio V1.0910 the extra resets have been removed and only a single 'reset' command is executed, after which the application CPU is halted and ready to be debugged.

Error "The application CPU is not enabled"

After the extra resets have been removed, you may get the error "The application CPU is not enabled" from OpenOCD. This may happen if you attempt to debug the application directly after running the flasher, without resetting the netX first. A reset is always required after running the flasher, because the application CPU needs to be enabled in order to debug it.

Click here to see screenshot...

Debugging the application first run after flashing

How about debugging the absolute first run of the application after flashing?
Currently this is not possible. We are working on a solution for upcoming versions of netX Studio.

The hardware reset performed by OpenOCD asserts SRST twice resulting in a "double reset"

When starting a debug session in Run mode, netX Studio will execute the OpenOCD 'reset' command exactly once, but the netX will be reset twice quickly one after another. This is caused by the default implementation of the hardware reset handling in OpenOCD which asserts the SRST signal twice resulting in a "double reset".

The default behavior of OpenOCD performs a "stronger" reset than necessary, in order to make sure that the target is properly reset. This is why OpenOCD allows you to customize the reset handling according to your needs and the specific target hardware. You can use the example script below which customizes the reset handling in order to avoid the "double reset":

openocd_config.cfg

# Reset will be handled by init_reset
$_TARGETNAME_COMM configure -event reset-assert { }
$_TARGETNAME_APP configure -event reset-assert { }

# This is the default init_reset implementation which 
# calls arp_init-reset to do the actual reset.
proc init_reset { mode } {
    jtag arp_init-reset
}

Download: openocd_config.cfg

See How to override the default OpenOCD reset handling? for more information on how to use the script.

See also...