RiscFree v25.1.1 no longer finds BSP and compiler headers files when editing

[BrendenB]

A fresh project imported into RiscFree v25.1.1 never resolves the header from the BSP or compiler while editing. For example:

This means that autocomplete of functions does not work. It works in RiscFree v23.4.1. I have tried using the new "Import Nios V CMake project ..." and directly importing it myself with the same result.

In RiscFree v23.4.1 under "Project > Properties > C/C++ General > Preprocessor Include Paths" all the paths to the BSP and compiler headers have been discovered:

Working in v23.4.1.

The same screen in RiscFree v25.1.1 shows none of the headers. Its like the CMake integration is not working. 

Broken in v25.1.1.

Both of these screens is viewed after I have compiled the project successfully. It seems like the CMake integration in RiscFree v25.1.1  is not working correctly.

Is this a bug or have I missed some configuration step?

[BrendenB]

I also found this exception in .metadata/.log which looks related:

!ENTRY org.eclipse.cdt.core 4 0 2025-03-21 17:55:48.923
!MESSAGE Error: org/slf4j/LoggerFactory
!STACK 0
java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
at org.eclipse.jetty.util.log.Log.getLogger(Log.java:31)
at org.eclipse.jetty.util.ajax.JSON.<clinit>(JSON.java:90)
at de.marw.cmake.cdt.language.settings.providers.CompileCommandsJsonParser.tryParseJson(CompileCommandsJsonParser.java:258)
at de.marw.cmake.cdt.language.settings.providers.CompileCommandsJsonParser.shutdown(CompileCommandsJsonParser.java:612)
at org.eclipse.cdt.internal.core.ConsoleOutputSniffer.closeConsoleOutputStream(ConsoleOutputSniffer.java:162)
at org.eclipse.cdt.internal.core.ConsoleOutputSniffer$ConsoleOutputStream.close(ConsoleOutputSniffer.java:70)
at org.eclipse.cdt.internal.core.ProcessClosure$ReaderThread.close(ProcessClosure.java:101)
at org.eclipse.cdt.internal.core.ProcessClosure.isAlive(ProcessClosure.java:194)
at org.eclipse.cdt.core.CommandLauncher.waitAndRead(CommandLauncher.java:248)
at org.eclipse.cdt.core.CommandLauncherManager$CommandLauncherWrapper.waitAndRead(CommandLauncherManager.java:161)
at org.eclipse.cdt.internal.core.BuildRunnerHelper.build(BuildRunnerHelper.java:284)
at org.eclipse.cdt.managedbuilder.core.ExternalBuildRunner.invokeExternalBuild(ExternalBuildRunner.java:140)
at org.eclipse.cdt.managedbuilder.core.ExternalBuildRunner.invokeBuild(ExternalBuildRunner.java:73)
at de.marw.cdt.cmake.core.internal.CMakeBuildRunner.invokeBuild(CMakeBuildRunner.java:129)
at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.build(CommonBuilder.java:783)
at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.build(CommonBuilder.java:533)
at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.build(CommonBuilder.java:471)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:1077)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:47)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:296)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:352)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:441)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:47)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:444)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:555)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:503)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:585)
at org.eclipse.core.internal.resources.Workspace.buildInternal(Workspace.java:594)
at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:490)
at org.eclipse.ui.actions.BuildAction$1.runInWorkspace(BuildAction.java:288)
at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:43)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: java.lang.ClassNotFoundException: org.slf4j.LoggerFactory cannot be found by de.marw.cmake.cdt_1.2.1.202501301848
at org.eclipse.osgi.internal.loader.BundleLoader.generateException(BundleLoader.java:562)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass0(BundleLoader.java:557)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:434)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:174)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
... 32 more

[BrendenB]

I think I have tracked down the problem. The  de.marw.cmake.cdt_1.2.1.202501301848.jar plugin from RiscFree v25.1.1 has an embedded version of jetty-util-10.0.15.jar. It uses this embedded library when loading org.eclipse.jetty.util.log.Log. However, org.eclipse.jetty.util.log.Log has a dependency on org.slf4j.LoggerFactory which it can't access because de.marw.cmake.cdt_1.2.1.202501301848.jar does not import org.slf4. The OSGi instructions in the embedded jetty-util-10.0.15.jar are ignored.

The de.marw.cmake.cdt_1.2.1.202311041909.jar from RiscFree v23.4.1 just OSGi imports org.eclipse.jetty.util.log (i.e. it does not embed the jetty-util jar) which means it uses the jetty-util-10.0.15.jar that is shipped as an OSGi plugin. The jetty-util-10.0.15.jar plugin itself OSGi imports org.slf4j so it all works.

There are a couple of fixes for this:

1.  Make de.marw.cmake.cdt_1.2.1.202501301848.jar import the jetty-util dependency through OSGi rather than embedding the JAR file (and stop embedding the jar file). This seems like the most logical thing to do as RiscFree v25.1.1 still ships org.eclipse.jetty.util_10.0.21.jar as an OSGi plugin (which should be compatible).
2. Make de.marw.cmake.cdt_1.2.1.202501301848.jar import all the dependencies that are needed by the embedded jetty-util jar. This really only makes sense if its necessary to embed the jetty-util jar in the plugin.

I have tested that 1 works by taking the de.marw.cmake.cdt_1.2.1.202311041909.jar from RiscFree v23.4.1 and installing it over the version in RiscFree v25.1.1. This fixes the problem. 

[BrendenB]

I also wanted the mention that you can use the "Project > Properties > C/C++ General > Preprocessor Include Paths > CDT User Setting Entries" as in the images above to manually enter in all the paths. You may need to enable the "CDT User Setting Entries" on the "provider" tab before manual paths can be configured in the "entries" tab.

[JingyangTeh]

Hi

Thanks for debugging the issue further and found the root cause.

That could be due to RiscFree 25.1.1 version is not release officially to download and use.

Where did you download the RiscFree 25.1.1?

In the Intel download website only has RiscFree 24.3.1.

Regards

Jingyang, Teh

[BrendenB]

I have been using the versions specified in the UI of RiscFre which in no way seem to match the Quartus versions they are shipped with.

---

Where did you download the RiscFree 25.1.1?

---

This is the version of RiscFree installed when installing Quartus 24.1 through the installer. The actual download file is versioned as "Ashling* RiscFree* IDE for Altera 24.1std.0.1077". However, when you look at the version through the "Help > About" menu it reports the version as:

In the above it works in Quartus Lite 23.1 (i.e. RiscFreeSetup-23.1std.1.993-linux.run) and is broken in Quartus Lite 24.1 (i.e. RiscFreeSetup-24.1std.0.1077-linux.run).

I have also tested with the version of RiscFree shipped with Quartus Pro 24.3.1 (i.e. RiscFreeSetup-24.3.1.102-linux.run) and discovered the exact same problem.

[JingyangTeh]

Hi

Thanks for raising this issue.

I have tried downloading the Quartus 24.1 Standard and the downloaded version is v25.1.1.

Confirm with our technical team that it is intended.

We managed to see the unresolved warning of the headers in the IDE and trying to take a look at this.

Please give us some time and will get back to you by this week.

Regards

Jingyang, Teh

[JingyangTeh]

Hi

There is an option for the Project Reference.

In the application project you could reference the BSP project in the "Project Reference" tab:

Regards

Jingyang, Teh

[JingyangTeh]

Hi

Did you managed to try out the suggestion in the previous comment?

Regards

Jingyang, Teh

[BrendenB]

Sorry for the delay.

The suggested approach of linking the projects provides a workaround for linking the headers to the BSP project. However, it does not solve the problem of linking to the compiler headers.

Still not linked.

Additionally, it also triggers a build of the BSP before the APP. This is not necessary. The CMake scripts in the APP will build the BSP automatically when the APP is compiled. But now under this configuration we have:

1. BSP compiled in bsp/build.
2. BSP compiled in app/build/bsp.
3. APP compiled in app/build and linked against app/build/bsp.

Step 1 is not necessary. Note that in the version where 23 where this works we don't have to link the projects. In version 23 only steps 2 and 3 are performed as the projects are not linked.

As I mentioned in a previous post (https://community.intel.com/t5/Nios-V-II-Embedded-Design-Suite/RiscFree-v25-1-1-no-longer-finds-BSP-and-compiler-headers-files/m-p/1676845#M53544) this all seems to stem from the fact that the CMake plugin gets an exception when trying to parse JSON output from CMake. The way this used to work cleanly is that:

1. CMake is used to build the project.
2. CMake is told to dump all the compile commands it used in a JSON file in the build directory. These compile commands contain the location of the headers etc used to perform the build.
3. The CMake plugin in Eclipse parses out the JSON file and works out where all the headers are located. 
4. The CMake plugin tells Eclipse about these include paths via CMAKE_EXPORT_COMPILE_COMMANDS parser pre-processor option in the project configuration.

The problem is that the CMake plugin is getting an exception while trying to parse the JSON file and as such is unable to find the include headers. I noted the cause of the exception is some bad OSGi configuration.

Has this bug been reported? I have been using https://community.intel.com/t5/Nios-V-II-Embedded-Design-Suite/RiscFree-v25-1-1-no-longer-finds-BSP-and-compiler-headers-files/m-p/1676846#M53545 as a workaround to get the compiler headers. It would be good if this could be fixed.

Also, note this is currently a problem in the professional version of Quartus as well.

[JingyangTeh]

Hi

As we did not receive any response from you on the previous question/reply/answer that we have provided. Please login to ‘https://supporttickets.intel.com/s/?language=en_US’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.

Regards

Jingyang, Teh

[Kenny_Tan]

case, reopening

[JingyangTeh · Accepted solution]

Hi

Thanks for raising this issue and providing the workaround.

I have raised this issue to our technical team.

At the meantime please bare with the tool and use the workaround you found.

Regards

Jingyang, Teh

[JingyangTeh]

Hi

I will now transition this thread to community support. If you have a new question, Please login to ‘https://supporttickets.intel.com/s/?language=en_US’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.

Regards

Jingyang, Teh