How can I capture OpenOCD error information when it fails to start?

[laomaolaile]

When debugging a program using OpenOCD, if there are configuration errors or other issues, OpenOCD may terminate before reaching the expected output of Started by GNU MCU Eclipse In such cases, Eclipse waits for OpenOCD until a timeout occurs and then displays an error message. This behavior is normal under typical conditions, but in my situation, it prevents effective troubleshooting.

The error messages generated during my engineering work are as follows: These messages contain crucial information necessary for diagnosing and resolving the encountered issues. Unfortunately, Eclipse does not surface these error messages, hindering effective troubleshooting and analysis.

Info : libusb_open() failed with LIBUSB_ERROR_NOT_FOUND
Info : no device found, trying D2xx driver
Info : D2xx device count: 2
Info : Connecting to "(null)" using D2xx mode...
Info : clock speed 1000 kHz
Info : JTAG tap: riscv.cpu tap/device found: 0x10900a6d (mfg: 0x536 (Nuclei System Technology Co Ltd), part: 0x0900, ver: 0x1)
Info : coreid=0, nuclei debug map reg 00: 0x18010038, 16: 0x18010040, 32: 0x18010108
Info : [riscv.cpu] datacount=4 progbufsize=8
Info : [riscv.cpu] Vector support with vlenb=16
Info : [riscv.cpu] Examined RISC-V core
Info : [riscv.cpu]  XLEN=32, misa=0x4014952f
[riscv.cpu] Target successfully examined.
Info : [riscv.cpu] Examination succeed
Info : [riscv.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections
riscv.cpu halted due to undefined.
Info : Valid NUSPI on device Nuclei SoC SPI Flash at address 0x20000000 with spictrl regbase at 0x10013000
Info : SPI controller version 0x00000000

I would like Eclipse to capture and display these error messages from OpenOCD to assist in diagnosing the problem. Is there a way to enable this functionality, or are there plans to implement such a feature?"

[ilg-ul]

Is there a way to enable this functionality, or are there plans to implement such a feature?

No, but the usual way to diagnose these cases is to enable logging and possibly increase the debug level. Please check the OpenOCD manual for details.

[TommyMurphyTM1234]

In my experience ... In such failure cases it's often better to diagnose the issue standalone from the IDE - e.g. by running GDB/OpenOCD manually from command line terminals. Once the issue has been identified and fixed then you can revert to trying it using the IDE.

And, as implied by @ilg-ul, enabling verbose OpenOCD logging (e.g. openocd -d3) may be useful in such situations.

[laomaolaile]

I don't think so, but the current approach essentially hides the actual errors, which can easily confuse users. The exception being reported at this point is an OpenOCD startup timeout. However, the real situation is that OpenOCD does start, but an error occurs during the initialization process. This behavior is not reasonable and can mislead users into repeatedly trying to launch OpenOCD without addressing the root cause.

In most cases, the issue is related to the project itself or its configuration. If these errors were properly displayed, users could quickly identify the problem and fix it.

So I think it's necessary to display these information.

[TommyMurphyTM1234]

I don't think so

I don't understand.
Don't you get two sets of messages...

1. The Eclipse "Error in services launch sequence" error dialog
2. The OpenOCD logging messages to the Terminal view

[fanghuaqi]

Is there a way to enable this functionality, or are there plans to implement such a feature?

No, but the usual way to diagnose these cases is to enable logging and possibly increase the debug level. Please check the OpenOCD manual for details.

Hi @ilg-ul, it confuses IDE users into thinking the OpenOCD process is not running and prints nothing. If they don't run OpenOCD in the command line, they won't know this is caused by the OpenOCD process getting stuck at probing spiflash since there is no output of the OpenOCD log in the IDE.

For the current logic, the IDE will only dump the OpenOCD log when it captures Started by GNU MCU Eclipse. I understand that you are using this to let the IDE know the GDB server is ready and you can connect to it now, but if it is not ready, IDE users can still get some output of the OpenOCD process log to help them debug.

[SnowyTulip]

Hi @fanghuaqi
According to my observation, as well as the code logic of Eclipse Embedded, the IDE captures all logs and also prints some process logs. You can try this: if you can provide a situation where only the OpenOCD log is dumped when it captures "Started by GNU MCU Eclipse," I can attempt to debug the Embedded IDE to locate the issue.

@laomaolaile .However, note that the error occurs during the service launch sequence. The OpenOCD startup sequence consists of three steps.

Your sequence fails at the GDBServerStep, which means Eclipse considers your OpenOCD process to have failed to start. (This is not due to a configuration file error — if there is an OpenOCD configuration file error, it would still be regarded as a "running" state). In this case, since there is no OpenOCD process running, Eclipse does not print any log information.

Can you provide a set of steps to reproduce this issue? I will try to figure out where the issue might be.

[fanghuaqi]

Hi @SnowyTulip , in this case, the openocd hang at below

Info : Valid NUSPI on device Nuclei SoC SPI Flash at address 0x20000000 with spictrl regbase at 0x10013000
Info : SPI controller version 0x00000000
# openocd is trying to probe the spiflash, but this probing is still running and hangup there, so there will
# be no `Started by GNU MCU Eclipse` output, but eclipse will try to capture this Started by GNU MCU Eclipse
# so in the console, there will be no output even openocd is already running

[laomaolaile]

I checked the code and found that after the checkServer method, there is a fServerPipedProcess = new PushBackProcess(fServerProcess, outBuffer, errBuffer); When checkServer==false, there is no fServerPipedProcess, so there is no output in the console at this time.

// Check if the server started properly

success = checkServer(serverLaunchRequestMonitor, monitor, outBuffer, errBuffer);
if (success || serverLaunchRequestMonitor.isSuccess())
	// Create a wrapper for the original process, to have
	// some
	// control over the I/O stream.
	fServerPipedProcess = new PushBackProcess(fServerProcess, outBuffer, errBuffer);

So I tried to save it during timeouts as well fServerPipedProcess = new PushBackProcess(fServerProcess, outBuffer, errBuffer); Although it can output error messages, in other scenarios, other exceptions may occur, such as when there is a true timeout, there will be no output

// Register a timeout task, that should kill everything if the
// server
// did not start.
fTimeoutFuture = getExecutor().schedule(new Runnable() {

	@Override
	public void run() {

		if (Activator.getInstance().isDebugging()) {
			System.out.println("GdbServerStep.initialise() timeout run()");
		}

		if (fServerLaunchMonitor.fIsTimeoutEnabled) {

			// If not yet launched, the start job probably hanged,
			// and there
			// isn't much we can do to save it; interrupt thread and
			// destroy.

			fServerLaunchMonitor.fWasTimeout = true;

			Thread jobThread = startGdbServerJob.getThread();
			if (jobThread != null) {
				if (Activator.getInstance().isDebugging()) {
					System.out.println("GdbServerStep.initialise() timeout interrupt thread " + jobThread);
				}
				// Interrupt thread, in case it was blocked in a
				// read.
				jobThread.interrupt();
			}

			fServerPipedProcess = new PushBackProcess(fServerProcess, outBuffer, errBuffer);

			// Destroy the GDB server process.
			if (getServerProcess() != null) {
				getServerProcess().destroy();
			} else if (fServerProcess != null) {
				fServerProcess.destroy();
			}

			// Notify initialise(rm) directly.
			//						rm.setStatus(
			//								new Status(IStatus.ERROR, Activator.PLUGIN_ID, DebugException.TARGET_REQUEST_FAILED,
			//										getStartingServerJobName() + " timed out.", null)); //$NON-NLS-1$
			rm.done();
		}
	}
}, getServerLaunchTimeoutSeconds(), TimeUnit.SECONDS);

So, I think it should be able to solve the problem I mentioned. But I'm not sure how or where to solve it

[SnowyTulip]

Hi , @fanghuaqi
I have analyzed the code, and I found that whether OpenOCD outputs the string "Started by GNU MCU Eclipse" might indeed be the key to the issue.

In Eclipse, the typical OpenOCD startup sequence looks like this:

bin/openocd.exe -c gdb_port 2331 -c telnet_port 4444 -c tcl_port 6666 -f interface/jlink.cfg -f target/stm32f4x.cfg -c echo "Started by GNU MCU Eclipse"

If OpenOCD crashes for some reason before executing the echo command that outputs "Started by GNU MCU Eclipse", then Eclipse will not consider OpenOCD to have started successfully. As a result, Eclipse will not print any log output (since the PushbackInputStream won't be activated).

[SnowyTulip]

I have studied the OpenOCD startup logic in Eclipse Embedded.

For the checkServer method, Eclipse considers OpenOCD to have started successfully if any one of the following conditions is met:

• Condition 1: !canMatchStdOut() && !canMatchStdErr()
• Condition 2: canMatchStdOut() && checkServerStream
• Condition 3: canMatchStdErr() && checkServerStream
  These conditions are defined in the file GnuMcuGdbServerBackend.java. The OpenOCD server backend inherits from this class and implements some of its methods.

In the case of OpenOCD's ServerBackend, the following methods are implemented:

• canMatchStdOut() —> always returns false
• canMatchStdErr() —> returns true if "GDB Server" is selected in the configuration (which is almost always the case)
• matchStdErrExpectedPattern() —> determines success based on whether OpenOCD has output one of the following strings:
  "Started by GNU ARM Eclipse"

In essence, matchStdErrExpectedPattern() can be considered equivalent to the result of checkServerStream().

As you can clearly see, Conditions 1 and 2 are never satisfied in the OpenOCD launch scenario. Therefore, it's clear that matchStdErrExpectedPattern() — which checks whether the string "Started by GNU ARM Eclipse" has been printed — is the key factor in determining whether Eclipse considers OpenOCD to have started successfully.

If checkServer returns false, then the PushbackProcess(fServerProcess, outBuffer, errBuffer); will not be executed, and as a result, no information will be output to the eclipse console.

[SnowyTulip]

I believe you may want to try launching OpenOCD manually from the command line terminal using a command similar to the following:

openocd.exe -c gdb_port 2331 -c telnet_port 4444 -c tcl_port 6666 -f interface/jlink.cfg -f target/stm32f4x.cfg -c echo "Started by GNU MCU Eclipse"
Could you please check whether OpenOCD exits before printing the string "Started by GNU MCU Eclipse"?

If that is indeed the case, I believe it would be reasonable to consider that the logic in Eclipse might need to be adjusted accordingly.

[TommyMurphyTM1234]

Perhaps in a similar vein to this (closed) issue/question that I posted years ago?

• Question: gdb/openocd synchronization/possible race condition #186

[fanghuaqi]

If OpenOCD crashes for some reason before executing the echo command that outputs "Started by GNU MCU Eclipse", then Eclipse will not consider OpenOCD to have started successfully. As a result, Eclipse will not print any log output (since the PushbackInputStream won't be activated).

In this case, openocd is not crashed, it is just stubbed at probing flash step, so next steps like echo Started by GNU MCU Eclipse will not be done, so eclipse will think openocd server is not yet ready, and no output will be displayed in IDE console although openocd already output a lot.

[SnowyTulip]

Hi, @ilg-ul @fanghuaqi @laomaolaile
I did a deeper analysis, found that the situation where error messages are not printed occurs when the process is terminated due to a timeout.

I tested the following scenarios:
I will use "Started by GNU MCU Eclipse" as the passphrase.

Scenario 1: OpenOCD does not timeout

• OpenOCD terminates before the timeout period, without printing the passphrase. In this case, it exits normally, and an error message will be displayed on the console.
• OpenOCD prints the passphrase and exits before the timeout period. Similarly, it exits normally with an error message shown on the console.

Scenario 2: OpenOCD times out

• OpenOCD starts but due to internal configuration errors, it does not print the passphrase. In this situation, Eclipse gets blocked at checkServer (checking if OpenOCD has started) until a timeout error occurs. No error messages will be printed during this process.

Furthermore, based on analysis of the source code, it appears that the only case in which no error is reported is when a timeout occurs.In other scenarios, an error should be reported on the console.

[SnowyTulip]

Even if OpenOCD crashes unexpectedly, Eclipse is still able to print an error message. This is because the launch process can still complete its entire workflow and register the console output.

eclipse-plugins/plugins/org.eclipse.embedcdt.debug.gdbjtag.openocd.core/src/org/eclipse/embedcdt/debug/gdbjtag/openocd/core/dsf/Launch.java

Line 188 in 4ed6716

newProcess = DebugPlugin.newProcess(this, serverProc, label, attributes);

However, if OpenOCD times out due to certain issues, Eclipse will not print an error message. This occurs because the timeout checking process terminates both the OpenOCD process and the pushback process. It then sets the status to "error" when executing rm.done(), which causes the launch process to terminate.

eclipse-plugins/plugins/org.eclipse.embedcdt.debug.gdbjtag.core/src/org/eclipse/embedcdt/debug/gdbjtag/core/dsf/GnuMcuGdbServerBackend.java

Line 794 in 4ed6716

new Status(IStatus.ERROR, Activator.PLUGIN_ID, DebugException.TARGET_REQUEST_FAILED,