A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://gnu-mcu-eclipse.github.io/debug/jlink/ below:

The J-Link debugging Eclipse plug-in

The J-Link debugging Eclipse plug-in Quicklinks

If you already know what are the features of the new plug-in and only want to know how to install/use it, you can directly skip to:

Why a new plug-in?

Until now, debugging with the J-Link probe in Eclipse was done via the GDB Hardware Debugging plug-in. For experimental projects it was more or less ok, but for serious development it was quite tedious. The missing features, that were added to this plug-in, are:

Prerequisites

Before being able to use the J-Link probe with the GNU MCU Eclipse plug-ins, you must separately install:

If you did not do it yet, please follow the instructions in the J-Link install page and return when completed.

The presence of a GDB as part of a GNU toolchain is mandatory, and it is recommended that the version of the GDB client matches the toolchain. Generally only debugging .elf applications is possible, and these applications must be compiled to include GNU compatible debugging information (like dwarf).

Non-GNU toolchains

Debugging applications generated by non-GNU toolchains (like the obsolete ARM CC), although not completely excluded, is not supported.

J-Link plug-in usage Define the J-Link folder location

Before starting work with the J-Link tools, it is required to define the path to the J-Link folder.

By default, the GDB server is defined as ${jlink\_path}/${jlink\_gdbserver}; these two macros are automatically set by the above preference page; for portability reasons, it is recommended to keep this definition in all your debug configurations, and also to have a single place to update the path when a new version of the J-Link tools is released.

Associate a device to the project

Although not absolutely mandatory, it is recommended to associate a device to the project, so that creating the debugger launch configuration will automatically fill-in the device name.

Follow the steps in the separate page Associate a device to the project and return to this page to continue.

Create the debugger launch configuration

Being a standard debugger, this plug-in also uses the Eclipse standard method of creating debugger configurations for each application. After you successfully build your application, you can create a new debug configuration following these steps:

With the above settings, the debug configuration will be saved in the project, not in the workspace storage.

Start a debug session

Before starting a debug session, be sure that:

With all the above steps completed properly, you can start the debug session:

Alternatively, on subsequent runs, you can use the bug specific icon. By default this will start the previously used debug launch configuration; to start a different configuration, use the down arrow button:

This will open a new window where you can select the desired debug configuration:

If everything is ok, after a few seconds required to start the server, to allow it to connect to the target, start the gdb client, download the application and start the debugging session, you should see something like this:

The new debug session, with three consoles.

Since the first breakpoint was set in the Debugger tab to main, the execution stopped right at the beginning of the main() function, which in this case is a tracing printf().

Debug operations

Once the debug session started and execution stopped in the first breakpoint (by default set at the beginning of the main() function), you can perform any debug operation you need.

The most common operations are:

For more details please read the Running and debugging projects section in the Eclipse documentation.

View consoles

Each debug process has a dedicated console, to display its standard output and standard error, or to get input for the standard input.

To see the console of any process, select the process in the top left window. For example the server console might look like this:

Similarly for the tracing console:

Show console when standard out/error change

This is the default Eclipse behaviour when multiple consoles are active, to automatically switch to the latest updated. In our case, especially when the Semihosting/SWV console is also active, the focus will jump between windows, making things impossible to follow.

This mode can be identified by the status of the buttons on the right side of the Debugging view.

To make the display stable on the desired console, disable both buttons. To switch between consoles, select them either in the top left Debug view, or using the right button, as shown above.

The Restart button

Apparently not a big deal, but quite useful for repeated debug sessions, the Restart button can be used at any time during a debug session, and the result is that a reset is dispatched to the target board via the JTAG/SWD interface and the debug session is restarted.

Note: Due to some bugs in Eclipse, the implementation of his simple button has encountered several problems. Depending on the version you are using, the first time you click this button you might get a message box informing that the button was not enabled. Ignore this message, close the message box and click the button again, this time it’ll be effective.

Using a remote GDB server

If, for any reason, you need to run the GDB server on a remote machine (for example the development board is connected via J-Link to a machine in your office, but you are in another location), you can still use the plug-in to run debugging session. For this to work, just disable Start the GDB server locally in the Debugger tab and instead of localhost for the Host name or IP address, enter the name or address where the GDB server can be accessed.

Then you must manually start the JLinkGDBServer process on the remote machine and only then you can start the debugging session.

Connect to running target

This is an advanced feature, allowing debugging of a target that was started outside the debugger.

To make this possible, enable the Connect to running target option in the Debugger tab:

With this option, the J-Link plug-in will no longer reset the target and will no longer download the code into the target’s memory, leaving the target virtually unaffected, even after the debug session is started.

To start interacting with the target, it must be halted, using the debugger’s Halt command. After examining the target’s memory, setting breakpoints, etc, execution can be resumed, and the debug session terminated, leaving the target running.

Using multiple J-Link probes at once

For advanced applications it is sometimes required to start multiple debug sessions, with multiple J-Link probes, on the same computer. SEGGER J-Link is perfectly capable of doing this, both over USB or TCP/IP.

For this, multiple instances of Eclipse are required, and each one must be configured with different TCP/IP ports for the GDB/SWO/Telnet services, and also each must be configured with the serial number of the specific J-Link probe, printed on the back of the probe. For TCP/IP connected J-Link, instead of the serial number, use the IP address.

No GDB initialisation files loaded

For having a total control of the debugging session, the debugging plug-ins start the GDB client process with the --nx option, which prevents the execution of the commands found in any initialization file; none of the standard files (system.gdbinit, ~/.gdbinit, ./.gdbinit) are loaded.

To add more commands to the GDB initialisation sequence, use the Commands: field in the GDB Client Setup section:

All commands listed here are passed to the GDB client. By convention, commands prefixed with mon will be further passed from the GDB client to the GDB server, in this case the J-Link GDB server.

Troubleshooting Missing or wrong jlink_path

The first failure to start a debug session is missing to enter the J-Link path. Without it, the launching sequence will complain Cannot run program “/JLinkGDBServer”.

Define the jlink_path as instructed above and the session should start properly.

Wrong device selection

If the devices that you selected in the plug-in does not match the device physically connected, the GDB server session fails and the entire debug session is cancelled. You can identify this case by studying the GDB server log.

Select the device properly and the session should start properly.

J-Link hangups

Although SEGGER took special measures to avoid J-Link firmware hangups, in case you suspect such a situation (the JLinkGDBServer refuses to connect to the USB device, or to the target), it might help to power cycle the J-Link, by disconnecting and reconnecting the USB cable.

Cannot start applications running from RAM

Please be sure you disable the Pre-run reset and halt option in the Startup tab, this usually does not preserve the RAM content.

Error while launching command: gdb –version

If you kept the GDB client executable defined as ${cross_prefix}gdb${cross_suffix}, the above error means that the macros could not be substituted with the correct prefix/suffix. There can be several reasons for this. One might be that you did not associate the debug launcher to a project. Check the Main tab and be sure the field Project: refer to the correct project. Next time when you create the debug configuration, be sure you follow the above suggestions (select .elf, Debug Configurations, double click on GDB SEGGER J-Link Debugging. Another reason is presented below.

Using a different build plug-in or not supported compiler

Another reason for not being able to start the debug session is that your project was not build with the GNU MCU Eclipse managed build plug-in. If you are using another build plug-in, or an exotic/obsolete toolchain, you need to replace ${cross_prefix}gdb${cross_suffix} with the actual name of the gdb client available in your toolchain, since the ${cross_*} macros are available only in projects managed by the GNU MCU Eclipse build plug-in.

More info

Although the plug-in takes care of most of the configuration options, and provides reasonable defaults for the usual cases, it is recommended to read the SEGGER manuals, available from the Doc folder in the installation location or directly from the SEGGER J-Link page.


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4