eclipse-plugins

eclipse-plugins copied to clipboard

Packs plugin not usable alone

Steps to Reproduce

1. Install only the Packs plugin
2. Create a managed C++ project
3. open the "error log" view
4. open the project properties
5. (Try to) Enter the Board/Device in C/C++ Build -> Settings

Expected behaviour:

Being able to select a Chip for my Project (this worked some versions ago), or even being able to select the chip during debugging (like for example this plugin manages to to this without all the drama: http://embsysregview.sourceforge.net/)

In short, the packs plugin being usable standalone without requiring some builder/toolchain plugins or special settings. And ideally without a specific debugger plugin aswell

Actual behaviour:

Since a couple versions it appears that you have to choose ARM Cross GCC to be able to specify the Board/Device, you need to install another MCU plugin to be even able to choose this option.

If the GNU MCU RISC5 or GNU MCU ARM Toolchain plugins are not installed you get a ton of errors like this:

null
org.eclipse.core.expressions
Error
Tue May 15 14:47:14 CEST 2018
No property tester contributes a property ilg.gnumcueclipse.managedbuild.cross.riscv.isGnuRiscv to type class org.eclipse.core.internal.resources.Project

org.eclipse.core.runtime.CoreException: No property tester contributes a property ilg.gnumcueclipse.managedbuild.cross.riscv.isGnuRiscv to type class org.eclipse.core.internal.resources.Project
	at org.eclipse.core.internal.expressions.TypeExtensionManager.getProperty(TypeExtensionManager.java:127)
	at org.eclipse.core.internal.expressions.TestExpression.evaluate(TestExpression.java:97)
	at org.eclipse.core.internal.expressions.CompositeExpression.evaluateOr(CompositeExpression.java:65)
	at org.eclipse.core.internal.expressions.OrExpression.evaluate(OrExpression.java:22)
	at org.eclipse.core.internal.expressions.CompositeExpression.evaluateAnd(CompositeExpression.java:51)
	at org.eclipse.core.internal.expressions.AndExpression.evaluate(AndExpression.java:31)
	at org.eclipse.ui.internal.dialogs.RegistryPageContributor.failsEnablement(RegistryPageContributor.java:306)
	at org.eclipse.ui.internal.dialogs.RegistryPageContributor.isApplicableTo(RegistryPageContributor.java:248)
	at org.eclipse.ui.internal.dialogs.PropertyPageContributorManager.contribute(PropertyPageContributorManager.java:111)
	at org.eclipse.ui.internal.dialogs.PropertyDialog.createDialogOn(PropertyDialog.java:62)
	at org.eclipse.ui.dialogs.PropertyDialogAction.createDialog(PropertyDialogAction.java:174)
	at org.eclipse.ui.dialogs.PropertyDialogAction.run(PropertyDialogAction.java:155)
	at org.eclipse.jface.action.Action.runWithEvent(Action.java:473)
	at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:565)
	at org.eclipse.jface.action.ActionContributionItem.lambda$4(ActionContributionItem.java:397)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:86)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5348)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1348)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4602)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4183)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1150)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1039)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153)
	at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:680)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:594)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:151)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:653)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:590)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1499)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1472)

Versions

• GNU MCU C/C++ J-Link Debugging 4.3.2.201804191501
• GNU MCU C/C++ Packs (Experimental) 2.2.2.201804191501
• eclipse 4.7.3.M20180330-0640
• java 9.0.4+12-Debian-4
• Debian 10 "Buster"
• custom

Unfortunately the logic to assign a device to a project and to use this setting in the Peripheral viewer during a debug session is tightly coupled with the build plug-ins and the debug plug-ins, thus standalone usage is problematic.

Then wouldn't it preferable if the packs plugin depend on those plug-ins?

I mean I would not be happy, but at least there would be no illusion of being able to use the "Peripheral viewer" alone.

Then wouldn't it preferable if the packs plugin depend on those plug-ins?

yes, but this is a bit tricky, since it should depend on either the ARM build plug-in or the RISC-V build plug-in, which is a complex condition, and I'm afraid it is not possible to define it.

I agree with you that the current solution is not ideal; I'll leave this issue open, if I can find a better solution, I'll implement it.

yes, but this is a bit tricky, since it should depend on either the ARM build plug-in or the RISC-V build plug-in, which is a complex condition, and I'm afraid it is not possible to define it.

I think unless both are installed you will get the errors above.

Completely stupid question, but how about defining an ELF Section to denote the chiptype?

That would allow to seperate

• injecting the chip information
• debugging an ELF File with fitting Information (even a standalone firmware without project!)

eg, the toolchain/project would do something similar to this (can be done with linker-commands awell, just dont have them ready):

#define DEFINE_GDB_CHIPTYPE(chipspec) \
  __asm__("\
.pushsection \".debug_gdb_chiptype\", \"MS\",@progbits,1\n\
.byte 1 /* Version */\n\
.asciz \"" chipspec "\"\n\
.popsection \n\
");

DEFINE_GDB_CHIPTYPE( "STM32F303CB\0" "STM32F303\0" )

the debugger plugin would read the section and try to find fitting device descriptions, configuring the peripherial view

No stupid questions, all suggestions are welcome, but in this case I'm afraid the suggestion must be addressed to the toolchain maintainers to standardase on such a new elf section.

Aslong the section does not conflict with one of the standardized ones, you are free to use whatever you want. IDE`s regularly do that for special checksum and other functionality. The example above is taken verbatim from a section gdb defined on its own: https://sourceware.org/gdb/onlinedocs/gdb/dotdebug_005fgdb_005fscripts-section.html

eclipse would have to extract the infos from ELF section and setup the debugger/peripherial view. I have no idea how easy or complex this would be to implement. Usecases could be numberous, the chip description to the debugging method and wire speed supported could all be embedded into the ELF File for a simple one-click debugging.

Hi @ilg-ul , I am trying to associate a new riscv based board to the devices option in eclipse option. Is it possible to only to add it through xPack?If so, Can you please how to go about it.?

Thanks. Sreyas