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

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.

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.

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

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.

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.

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. https://github.com/ARMmbed/mbed-os/issues/3919

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/targets.py" 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: https://www.eclipse.org/forums/index.php/t/1082988/ https://community.nxp.com/thread/359757

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.

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).