Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Import Macro Repair
Panel
bgColor#ffffff
titleQ

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?

After running the flasher or auto-flasher, a reset has to be performed in order to be able to debug the application side. Before the patch, netX Studio would always perform a reset before starting a debug session in 'Run' mode, and this would ensure that the application CPU is started. After the patch, this extra reset is removed, and the netX needs to be reset manually when required

. 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.

Panel
bgColor#ffffff
titleA

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

Currently, the netX Studio debugger performs some unexpected resets in both modes:

Run mode - the CPU is reset more than once before


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 started, which results in unwanted executions of the program currently residing in the application internal flashAttach mode - the CPU is reset once before the debugger attaches, which makes it impossible to debug an application which was already running for some time (so far observed only with the NXHX 90-JTAG and NXHX 90-MC evaluation boards when 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

)

These are known issues that will be fixed in upcoming versions of netX Studio.

Part of these issues are related to the OpenOCD reset configuration which is currently configured to use a hardware reset. Until this is resolved, the workaround is to switch to a software reset. If using a software reset is not an issue for you, then you can patch your existing netX Studio installation as described below.

How to apply the patch?

Download and unzip the patch to a temporary location:
  • netX Studio CDT V1.0900 → netxstudio_netx90_reset_config_patch_V1.0900.zip
  • netX Studio CDT V1.0700 → netxstudio_netx90_reset_config_patch_V1.0700.zip
  • Run the batch script inside to apply the patch:
    netxstudio_netx90_reset_config_patch.bat
  • What does the patch do?

    The patch updates some of the existing OpenOCD configuration files which are located inside the BuildTools folder:

    Code Block
    C:\ProgramData\Hilscher GmbH\netX Studio CDT\BuildTools\openocd\config
    Note

    After applying the patch, netX Studio will switch to using a software instead of a hardware reset when debugging netX 90.

    Note
    Info
    titleError "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.

    Expand
    titleClick here to see screenshot...

    Image Added

    Info
    titleDebugging 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":

    Code Block
    languagetext
    titleopenocd_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.


    Panel
    bgColor#ffffff
    titleSee also...

    Filter by label (Content by label)
    showLabelsfalse
    spaces@self
    showSpacefalse
    cqllabel = "faq" and space = currentSpace ( )
    labelsfaq