Add support for MCUXpresso inside mbed exporter

[mmahadevan108]

Add support for MCUXpresso inside mbed exporter

Status

**READY

[ ] Tests
Tested with the LPCXpresso54114 board

[mmahadevan108]

@theotherjimmy @maclobdell

[theotherjimmy]

This is a good start: from https://github.com/ARMmbed/Handbook/blob/5.5/docs/cont/adding_exporters.md
We get the following checklist, with things that you have done checked off:

• takes input from the resource scan
• uses the flags in the build profiles (I don't see any flag passing in your ctx variable) It's there, but not used as far as I can tell.
• has a single template file for each file type (you have a single template designed only to work with a single target; instead this should be a single template for working with many targets)
• Does not call mbed CLI

[theotherjimmy]

RE: flags

You should be able to get the flags provided to the complier by mbed CLI in your exporter class through the variable flags. Since you are inheriting from the GNUARMEclipse class, you may want to take advantage of the method process_options, which should structure compiler flags into many of the gui switches in eclipse.

[theotherjimmy]

RE: single template

I would do this after the flags requirement. It looks like you have a project xml escaped within the .cproject file. This file-in-a-file looks like it contains a tonne of configuration for the MCU. I would see how much of this can be inferred by the plugin using this configuration. I would guess that it really only needs the MCU name and family, and could generate the rest of that information in some way (it does this when you create a project after all).

[JojoS62]

• mcuxpresso is compatible with LPCXpresso projects, so this exporter could be used also (when it is fixed)
• single template: I tried already with lpcxpresso to omit the target xml. During the first build the IDE asks for the target MCU and adds the necessary MCU resources

[theotherjimmy]

@JojoS62 I was asking about what happens when you only provide the MCU, without any of that other configuration. That is useful info though.

[theotherjimmy]

Also, I think LCPXpresso and KDS are being merged into MCUXpresso. In that case, it makes sense to drop the old versions of the IDEs, and support the new, unified IDE.

[JojoS62]

yes, I agree. I could already verify (and this is also documented by NXP) that a LPCX project can be read by MCUX. In reverse, you get some errors when trying to import a project in LPCX that was saved by MCUX.
So my idea was to use the template from LPCX for both. But when this approach is working already I would try it also.

[Nodraak]

Hi JojoS62 mmahadevan108 !

First of all, thank you for your contribution!

I try to watch closely mbed-os's Python code because I believe it could be greatly improved. Therefore here are a few tips to make your code more Pythonic:

• L28: since TARGETS is not modified, you can use an immutable tuple instead of a mutable list:

       TARGETS = (
          'LPC54114',
      )

• L48: please add a trailing coma, this is encouraged in Python

  'symbols': self.toolchain.get_symbols(),

[theotherjimmy]

@Nodraak You tagged the wrong person. @mmahadevan108 is the author. @mmahadevan108 Please take note of @Nodraak's comment.

[JojoS62]

@mmahadevan108 @theotherjimmy
I have also started to work on the LPC/MCUXpresso exporter. A first test is in my branch https://github.com/JojoS62/mbed-os/tree/add_MCUXpresso_exporter/tools/export/mcuxpresso
For mbed 5, I have only a LPC4088 for testing, so it is modified for this target first.
There I use the standard linkerfile for gcc_arm, is there a need to use a different for the LPC54114? Anyway, the linker script name should be read from the options and not be hardcoded in the template.
The next todo is also to use the flags and different builds from the options (as in GAE exporter).
For now, I use also a target specific + common template. Ommitting the cpu specs makes some trouble. Maintanance should not be too difficult, most settings are in the common template.

I use also a forced zip file option by setting zip_proj = True in the project.py. This worked somehow, but I got an error after merging updates for fixing static files. I think this is an error, some incompatible types were added.
When force zip to true, all features are added instead of only the necassary. But the gae exporter class marks the unavailable features as excluded from the build, so only the zip is larger then necessary but build works fine.

[theotherjimmy]

@JojoS62 As long as the second template is easy to maintain, that sounds great!

[JojoS62]

I have already merged some of the gae stuff into the xpresso template and get the debug, develop and release configurations. Compiling works, calling the linker fails. The cproject template is really hard to read....

[theotherjimmy]

The cproject template is really hard to read....

Agreed, but I don't think I could do much better, or better at all really.

[JojoS62]

@ilg-ul I have used your exporter code and want to modify it for using it with LPC/MCUXpresso, also eclipse based IDE's. I hope this is ok for you, the copyrights and your name as original author will be kept.

This creates already some readable output: https://github.com/JojoS62/mbed-os/tree/add_MCUXpresso_exporter
But now I'm stuck on the following problems:

1. Debug/Release build: the linker gets no input files and I do not understand the magic that should create the linker input. The IDE creates a makefile but the objs are empty and the linker step fails:

makefile:70: *** unterminated variable reference.  Stop.

# Tool invocations
70: mbed-os-example-blinky.axf: $(OBJS) $(USER_OBJS)
	@echo 'Building target: $@'
	@echo 'Invoking: MCU C++ Linker'
	arm-none-eabi-c++ -Wl,--wrap,main -Wl,--wrap,_malloc_r -Wl,--wrap,_free_r -Wl,--wrap,_realloc_r -Wl,--wrap,_memalign_r -Wl,--wrap,_calloc_r -Wl,--wrap,exit -Wl,--wrap,atexit -Xlinker -Map="mbed-os-example-blinky.map" -Xlinker -print-memory-usage -Xlinker --gc-sections -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -mthumb -T "${workspace_loc:/mbed-os-example-blinky/Debug\linker-script-debug.ld" -o "mbed-os-example-blinky.axf" $(OBJS) $(USER_OBJS) $(LIBS)

As far as I understand the cdt scanner should add the object files to the linker command. I have compared the created .cproject file with a good one, but I cannot find the magic difference. A sample created file for the LPC4088 is attached.

The settings page for the tools shows a yellow eclamation mark but no error text, so I guess some option is recognized, but this seems to be a minor error.

2. the 'develop' build is not recognized, all settings are missing and the settings dialog is filled with default values. Does the toolchain have to know the .debug or .release extensions?

Do you have some more information about the .cproject file contents?

cproject.zip

[ilg-ul]

Do you have some more information about the .cproject file contents?

unfortunately not. :-(

although not related to your problem, one advice: for portability reasons, do not generate Eclipse projects with backslash path separators. (for example in the sourceEntries elements.

[JojoS62]

Thanks for your fast reply.
The sourceEntries is using the same as in your exporter, the common excluded_folders. A quick check with mbed export -i gnuarmeclipse shows the same behaviour, If that was different before, something else broke it. But the IDE is reading these path entries and excludes them as wanted.
I'm trying now to find the right entries for storageModule moduleId="scannerConfiguration">, that maybe the place for the configuration for the scanned object path?

[ilg-ul]

The sourceEntries is using the same as in your exporter

then the gnuarmeclipse has a small problem and should be fixed. I personally do not use Mbed, and the only tests I did were on macOS, where the paths were ok, so I had no chance to encounter the problem.

the IDE is reading these path entries and excludes them as wanted.

did you try on a POSIX environment too? but even if it works, it is still recommended to use POSIX portable paths.

[JojoS62]

I agree, but the fix should be done where the exclude_folders is created. I'm using windows and have no Linux/Mac installation, but maybe @theotherjimmy can help with this issue.
I have fixed it here: JojoS62@1bee24f

More confusing is the eclipse scanner configuration, I have some different projectfiles and cannot find a simple default.

[theotherjimmy]

@JojoS62 Yes, I can definitely help. On the other hand, you have already provided a fix! Would you like to make that commit you referenced into a PR? I approve it 👍 .

[JojoS62]

Yes, I want to make a PR, but there are some more details I want to fix as commented in my commit. The problem with linking was the missing linker script file.
The next step is to convert the settings into cproject options. The cdt settings should be the same for the exporters, but Ilg has created own dialogs with more detailed settings than the NXP developers. So the templates will be different.
I just found the cdt source https://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/build/org.eclipse.cdt.managedbuilder.gnu.ui/plugin.xml?id=5cc43360724772fefa127a28023b67d4f8133f1f
This looks like a list for the cdt base options. For the NXP extensions this file would be nice to have, but I guess it is closed source and not available.
I will need a few more days, but it looks already good, my LPC4088 blinky is compiling and running.

[theotherjimmy]

The problem with linking was the missing linker script file.

I'm glad that you found the problem.

For the NXP extensions this file would be nice to have, but I guess it is closed source and not available.

You can always ask. That file might not be very important to keep closed source. But, they are not likely to give it to you.

my LPC4088 blinky is compiling and running.

Excellent! I look forward to your PR.

---

Back on topic @mmahadevan108 Do you need any help from me?

[mmahadevan108]

This is being discussed in the below PR
#4916