2 years, 3 months ago.

Eclipse indexer errors

I have recently started using eclipse to develop offline with mbed-os 5. However there are index errors everywhere. Everything builds using mbed-cli, but what do I need to change in the eclipse environment for it to recognize the mbed methods, structs and consts?

In fact it doesn't recognize functions such as "sprintf" either.


Comment on this question

1 Answer

2 years, 3 months ago.

Hey Marcus,

Correctly updating the indexer for the exporters is on my todo list. Someone else pointed this out to me as well here:

It might be that your eclipse configuration is missing both the symbols defined on the command line to the compiler and the mbed_config.h symbols. You can take a look at what is provided to the compiler on the command line by passing the `-v` flag to `mbed compile`

If you fix your indexer please post the steps here so that other can find them, and so that I can automate them as part of the export process.

Thank you for replying. I doubt I will get this working. I am first trying to figure out how to point the indexer to the toolchain used by the compiler, since the projects are created using "No Toolchain" in Eclipse. But no luck so far

posted by Marcus Lee 23 Feb 2017

You could give the gnuarmeclipse exporter (recently merged) a try. I think that exporter spends a lot of time making sure that it has the indexing correct.

posted by the other jimmy 23 Feb 2017

A year later and this still seems to be an issue. I understand a lot of work has been done on the eclipse_gcc_arm exporter, but for those of us using the mDot or other unsupported targets are still stranded (because "MTS_MDOT_F411RE not supported by eclipse_gcc_arm").

Eclipse is pretty horrendous to use in general, but without the Indexer working it's the pits. I spent a couple of hours trying to manually add all the necessary include folders, but failed, and hadn't even started on trying to add the preprocessor defines.

Anyway we could help ourselves? Switch to IAR maybe, but just not feasible at the moment.

posted by Heath Raftery 06 Apr 2018

The reason that the MTS_MDOT_F411RE is refusing to export is that there is a post build step that the exporter cannot replicate. You can work around this to generate an export by applying the following diff:

diff --git a/targets/targets.json b/targets/targets.json
index edfe8ce3e..094a47823 100644
--- a/targets/targets.json
+++ b/targets/targets.json
@@ -1917,10 +1917,6 @@
         "core": "Cortex-M4F",
         "extra_labels_add": ["STM32F4", "STM32F411RE"],
         "macros_add": ["HSE_VALUE=26000000", "USE_PLL_HSE_EXTC=0", "VECT_TAB_OFFSET=0x00010000"],
-        "post_binary_hook": {
-            "function": "MTSCode.combine_bins_mts_dot",
-            "toolchains": ["GCC_ARM", "ARM_STD", "ARM_MICRO", "IAR"]
-        },
         "device_has_add": [],
         "release_versions": ["2", "5"],
         "device_name": "STM32F411RE"

At this point, you're taking full responsibility for making sure that the exported project does the same steps as this post-build script, or that you have some other method to ensure that the target is flashed correctly.

You may find that making this change for the export, and then reverting it and making the build step of the exporter use mbed complie would yield a working indexer and build

posted by the other jimmy 06 Apr 2018

Thanks for the response Jimmy. Unfortunately I have no idea how to take advantage of it. I could find no file of that length anywhere in mbed-os/tools/export/ let alone one with the correct contents. The advice about making the build step use mbed compile makes sense. I'd be happy to have some manual method that updates the index from time to time, without affecting the build or debug configs. I guess that's not really the way Eclipse was designed.

posted by Heath Raftery 08 Apr 2018

Sorry about that Heath. It looks like the formatting ate my diff. That's "targets/targets.json" in mbed-os. Good guess on the tools/export directory. I have a note on my todo list to add a method for querying more detailed info for a build, like what files are included, what are the include paths, and so on.

posted by the other jimmy 09 Apr 2018

Jimmy, that's terrific. Sorry for long radio silence - I didn't realise you'd responded. My journey was long and tricky, but the result was startlingly simple and stunningly effective, so hang on:

I made the change to targets/targets.json you suggested and ran "mbed export -i gnuarmeclipse -m MTS_MDOT_F411RE" from the root of my project. That replaced my .project (simple changes) and .cproject (major changes) and added a .mbedignore and replaced the mbed_config.h.

I then ran into this bug, but deleting the .temp folder and refreshing fixed that.

That gave me 3 functioning builds, Debug, Develop (what for?) and Release, and the moment we've been waiting for... a functioning index! About 3000 squiggly red lines suddenly disappeared once I re-built the index.

Next I looked at re-instating the post build hook I've removed from targets.json. I first thought I'd just add additional build configurations by recreating the old "mbed compile" configs, but the new build configs looked so good I thought I'd try the opposite and add the post build hook to the new configs.

Turns out the post build hook just runs "MTSCode._combine_bins_helper" in "tools/" which is a pretty straight forward bit of Python that concatenates the built bin with a bootloader bin. So I added a call directly to that Python script as a post-build step in the build configuration.

I than ran into these problems:

That is, the post-build step in CDT actually runs before the Create Flash Image (bin file) step, so has no bin file to work on. There's a couple of non-ideal workarounds and eventually the one that worked for me was to include the Create Flash Image step in my own post-build step. So it ends up running twice, but it's the least bad solution.

So my post-build step (which I only applied to the Release config) looks like this:

${cross_prefix}${cross_objcopy}${cross_suffix} -O binary "${BuildArtifactFileName}" "${BuildArtifactCombinedFileName}"; cd ${ProjDirPath}/mbed-os; python -c 'import tools.targets; tools.targets.MTSCode.combine_bins_mts_dot(None, None, None, "${PWD}/${BuildArtifactCombinedFileName}")'

Where I've added BuildArtifactCombinedFileName as a Build Variable with value "${BuildArtifactFileBaseName}_Combined.bin" (no quotes).

I'm delighted to say I have well-functioning Debug and Release builds in Eclipse. I'm also further convinced that Eclipse pleases those people who like fiddling with things rather than getting things done.

posted by Heath Raftery 06 May 2018

That's great to hear! Thanks for documenting the details publicly, so that others can find them (maybe less than easily, but it's still possible).

posted by the other jimmy 07 May 2018

To post an answer, please log in.