My current goal is to port the mbed project to MCUXPresso 11.3.0 (/arm-none-eabi/9.3.1/).
LPC55S69 can only be exported as a simple ZIP file from the online compiler(Google chorme & Windows 10). All other export options are completely ineffective.
I’ve spent dozens of hours trying to compile from the zip file into MCUXPresso, but I’m still getting a lot of errors. after passing GCC, the only thing that got in the way was many linker errors. I have no idea what the cause is any more. It’s so lethal that I can’t move forward.
This link shows that it is possible to compile on LPC55S69 with GCC. However, I could not find a way to do so. I am not a program expert and do not have enough knowledge of GCC. Can someone please guide me through the steps to reproduce this method?
LPC55S69 can only be exported as a simple ZIP file from the online compiler(Google chorme & Windows 10). All other export options are completely ineffective.
Yup. LPC55S69 is not supported for MCUXpresso exporter.
I’ve spent dozens of hours trying to compile from the zip file into MCUXPresso, but I’m still getting a lot of errors. after passing GCC, the only thing that got in the way was many linker errors.
By online compiler, there is a binary hook step for the LPC55S69 target at link stage here:
I think the target LPC55S69_NS (non-secure) need some symbols which are compiled by secure configration.
I am not 100% sure, but you probably need to add secure code (pre-build binary) below:
When I look at the link map by Mbed-CLI build (-m LPC55S69_NS -t GCC_ARM), I found this. So, you probably need to link cmse_lib.o object file.
I decided that I needed an Mbed cli environment, so I built one. As a result, compiling with GCC-ARM worked. I’m reporting my results in case this might be helpful to someone else. I am new to git and mbed cli. There are many things I don’t understand. So I write about my mistakes.
But I will have to redo the convert to MCUXpresso. The current mbed seems to have a complicated compilation procedure internally. Probably target generation using Python. Converting this manually requires a lot of expertise… Mbed cli makes compilation look easy, achieving this manually is not easy. I will try to convert this to MCUXpresso, but it may not work…
The command prompt pointed out that there was no Python module. He said,
You can install all missing modules by running “pip install -r requirements.txt” in “R:\mbed\mbed-os”. I follow the instructions.
pip install -r requirements.txt
However, command failed during the installation process. He said.
" Distutils.errors.DistutilsPlatformError: Microsoft Visual C++ 14.0 is required. Get it with “Microsoft Visual C++ Build Tools”: https:// visualstudio.microsoft.com/downloads/".
I also followed his instructions to install Visual studio 2019 and reboot. Now “pip install -r requirements.txt” was successful. This installation is only neccesary the “Visual studio build tools”.
mbed new . --create-only
mbed target LPC55S69_NS
mbed toolchain GCC_ARM
mbed compile
[mbed] Working path “R:\mbed\test” (library)
[mbed] Program path “R:\mbed” (library)
argument -m/–mcu: LPC55S69_NS is not a supported MCU.
The error was caused by the mbed version. They needs to be 5.15, not 6.8. I try again in a new directory.
mkdir test
cd test
git init
mbed new . --. create-only >mbed add https://github.com/ARMmbed/mbed-os#mbed-os-5.15.6 (“githu b.com” is “github.com”. This space prevent link being automatically rewritten.)
mbed target LPC55S69_NS
mbed toolchain GCC_ARM
mbed compile
I have successfully compiled by placing the appropriate main.cpp. You cannot summon the code without declaring “git init” first. It’s a basic thing, but I didn’t understand it because it’s my first experience with git.
I have an additional question. Please answer if you know the reason.
This question is also related to the online compiler in this title. Why is the export of LPC55S69 not supported? It is not even possible to make_gcc_arm export on mbed CLI. This is a very simple export.
Is it a security issue or a need for pre-built code, related to your answer?
This question is also related to the online compiler in this title. Why is the export of LPC55S69 not supported? It is not even possible to make_gcc_arm export on mbed CLI.
The exporter is normally done by silicon/board vender. In this case, NXP didn’t develop exporter function for this target and I don’t know the reason. I personally think the exporter of online IDE is not actively maintained now and I don’t recommend to use it.
Thanks for reply. I now understand that NXP lacks love for Mbed, Mbed seems to have started with their LPC, but maybe it was a disappointment for NXP.
About Mbed Studio. I’ve already installed it, and it may be the best tool for getting the most out of mbed. It still seems to be missing a few features, but it is well done. If IDE is my goal, it doesn’t have to be Eclipse.
However, that is not my final goal this time. It is to make mbed compatible with the LPC55S69’s unique features (DSP and dual core). So I focused on MCUxpresso.
LPC55S69 looks unpopular in mbed, support for mbed os 6 has been discontinued. Almost certainly no one will know the results of whether NXP’s SDK code can be used with mbed studio. Of course NXP will not support mbed with MCUxpresso. Anyway, I would like to try it.
I finally succeeded in mbed os compile with MCUxpresso. I had a hard time because I didn’t have enough information about this.
So I will record here how to overcome the difficulty. I hope this information will be helpful for people who want to realize mbed development environment on MCUXpresso and Eclipse.
Make all the sources into static libraries
Generate a static library using mbed cli and GCC-ARM. mbed studio seems to be able to use GCC-ARM, but I couldn’t find any information on how to create a static library yet.
mbed compile --library --source=mbed-os
The result is libmbed-os.a. When gcc calls the library, it only uses the mbed-os part, like lib “mbed-os”.a. The error occurred forever until I figured out the cause.
There are several reasons to create a static library. The biggest reason is to avoid the e=87 error. The huge amount of object links in mbed os are trapped by the 32000 character limit of Windows. Either way, compiling every time takes a lot of time in Eclipse, and I need to work around this problem eventually.
But here’s how to avoid the e=87 error in eclipse.
Get GCC-ARM artifacts from Mbed cli environment
The static library, compile, and the artifacts from these two have a header and directory structure. Copy them to the Eclipse project. These are needed to reference the static libraries.
The original source of mbed os contains a lot of unnecessary files, and the official mbed compilation seems to automatically unlink them. But our Eclipse can’t handle them, and they all result in errors. They should all be removed manually. However, this is a lot of work.
If we use a static library, we don’t have to do that. I use this one.
Next. I will also divert include, symbol, and linker related information from the artifacts. The file to get these information is as follows.
.profile-asm
.profile-c
.profile-cxx
.profile-ld
.link_options.txt
.link_script.ld
mbed_config.h
After this, we have to import the information obtained from here into the Eclipse environment. However, it is a daunting task in the Eclipse GUI. Here we should create an XML file for import by continuous processing in an external text editor and then import it into Eclipse. If necessary, we can directly edit the .cproject in Eclipse and append it. (“You should use a makefile.” That point is correct.)
The .link_script.ld is a memory address map artifact that does not contain the problematic C code. The original LPC55S69_cm33_core0_flash.ld contains internal C code that causes errors. The purpose is to avoid this. Someone may be able to pre-build it to handle it like the original, but it is unnecessary. If I develop for a single MPU in Eclipse, I can edit link_script.ld directly.
If everything is correct, the compile will pass without problems.
Fight against linker errors
However, the linker still has a lot of errors. Linker errors are nervous, so I needed to be both careful and bold to kill them.
arm-none-eabi/lib/thumb/v8-m.main+fp/softfp\libc.a(lib_a-sbrkr.o): in function _sbrk_r':sbrkr.c:(.text._sbrk_r+0xc): undefined reference to _sbrk’.
Add “-lnosys” to linker flags.
arm-none-eabi/lib/thumb/v8-m.main+fp/softfp\libc.a(lib_a-malloc.o): in function free': malloc.c:(.text.free+0x6): undefined reference to __wrap__free_r
arm-none-eabi/lib/thumb/v8-m.main+fp/softfp\libc.a(lib_a-__call_atexit.o): in function register_fini': __call_atexit.c:(.text.startup.register_fini+0x6): undefined reference to __wrap_atexit’.
How to deal with these errors.
undefined reference to `__wrap__free_r’.
undefined reference to `__wrap__malloc_r’.
undefined reference to `__wrap__calloc_r’
undefined reference to `__wrap__realloc_r’.
I solved the problem by removing the following from the linker options.
-Wl,–wrap=_free_r
-Wl,–wrap=_malloc_r
-Wl,–wrap=_calloc_r
-Wl,–wrap=_realloc_r
This is a different option than the original. Not sure why, but I move on.
/irq_armv8mml.S:105: undefined reference to `TZ_StoreContext_S
/mbed-os\rtos\source\TARGET_CORTEX\rtx5\RTX\Source/rtx_kernel.c:85: undefined reference to `TZ_InitContextSystem_S
/mbed-os\rtos\source\TARGET_CORTEX\rtx5\RTX\Source/rtx_thread.c:1094: undefined reference to `TZ_FreeModuleContext_S
/mbed-os\rtos\source\TARGET_CORTEX\rtx5\RTX\Source/rtx_thread.c:717: undefined reference to `TZ_AllocModuleContext_S
These can be resolved by adding the following to other objects in the Linker Misc in Eclipse
From here on, I had a very hard time finding the cause.
arm-none-eabi/lib/thumb/v8-m.main+fp/softfp\libc.a(lib_a-signalr.o): in function _kill_r': signalr.c:(.text._kill_r+0x12): undefined reference to _kill
arm-none-eabi/lib/thumb/v8-m.main+fp/softfp\libc.a(lib_a-signalr.o): in function _getpid_r': signalr.c:(.text._getpid_r+0x0): undefined reference to _getpid’
Also add the same declaration to the Library of Eclipse. This solves the problem, but you need to declare it twice. The cause seems to be a dependency on the order in which objects are loaded.
Dealing with the remaining errors.
/mbed-os\targets\TARGET_NXP\TARGET_MCUXpresso_MCUS\TARGET_LPC/sleep.c:33: undefined reference to `POWER_EnterDeepSleep
/mbed-os\targets\TARGET_NXP\TARGET_MCUXpresso_MCUS\TARGET_LPC55S69\TARGET_LPCXpresso/clock_config.c:90: undefined reference to `POWER_ SetVoltageForFreq’.
/mbed-os\targets\TARGET_NXP\TARGET_MCUXpresso_MCUS\TARGET_LPC55S69\TARGET_LPCXpresso/clock_config.c:139: undefined reference to `POWER _SetVoltageForFreq’.
Add “-lpower” to the linker. Add “-lpower” to the library search path.
There is some detailed information that I couldn’t write here. This may not be enough for everyone to get the same results. So I want to upload the MCUXpresso project for LPC55S69 mbed os somewhere. I’ll report back when it’s up.
I don’t know if the LPCXpresso exporter was written originally by NXP, but the MCUXpresso exporter is not. There was a new exporter gnuarmeclipse, written by Liviu Ionescu. I have used this as a template for the MCUXpresso and added the targets that were available that time.
My favorite IDE was also eclipse, but that is a very intranspararent monster. The exporter has to create the project files without using the java objects that are used for these files. So a lot of reverse engineering and try and error was necessary to get it working. Another big problem is that mbed-os contains lots of targets that should not be visible to the IDE, but eclipse tries to analyse everything. It must be configured to exclude and include the used project files.
I have spent also lots of time with the linker errors, too long command lines and many more problems. It is a very tedious task to maintain the exporters and I think they are outdated now.
Something that I was not familar with was using git. My idea was to export the project as zip archive and import it into eclipse. That worked finally by the switch -z. It took some time, but thanks to theotherjimmy, who helped me with my PR for the exporter and understanding git.
So the big disadvantage of this method is that you take a snapshot and you are working disconnected from the the mbed-os development. And also the Mbed config system is not working that way.
Using the mbed-cli or Mbed Studio is a much better way to handle mbed projects. mbed-cli can also be included in VSCode by calling mbed-cli commands and debugging is working also with Cortex-Debug extension. It is a bit more configuration, but you have more control of extensions and can use a lot of debug probes. With built-in git support, you can switch between mbed-os versions and you have better control over your source code, it would never ever create some source code without git.
For the LPC55S69, I would recommend to create a custom target. There is some documentation for this and most of the target code for mbed-os 5.15 should be usable for mbed 6 also.
that is some problem with requiring fixed versions that are no longer available, I remember pywin32 as such a module.
To fix this, change the requirements.txt temporary to install versions pywin>=224 and revert this after running the pip install
Thanks for the info, I understand the difficulty of porting to Eclipse and the potential of Mbed Studio and the limitations of Eclipse. I also had a very hard time getting Eclipse to work. I’ve done similar porting work with Renesas RX + E2studio, LPC1500 + mbed + LPCxpresso. All of them were long and hard fought. Not many people want to do this kind work.
But there is still an advantage of an external vender’s environment like MCUXpresso. I hope you will think more seriously about debugging features before you abandon Eclipse support altogether.
Studio is still a work in progress. No one, including me, can do satisfactory work on the command line. It is only an environment for the true experts.
Today I encountered a new problem. This is going to be a good example of just how important it is. Actually, my battle was not over yet. The LPCXpresso55S69 evaluation board arrived today and when I write my mbed sample axf, it does not work. The debugger showed a runaway before reaching the main function. Of course, the bin with mbed cli worked fine, so there is something wrong with the MCUxpresso artifacts.
I need to trace the “startup_LPC55S69_cm33_core0.S”. I need to know what is happening at the assembler level, MCUxpresso can tell me the register behavior, when will I be able to do that with mbed studio and LPC55S69?
Image: MCUxpresso guides assembler trace and the register where the problem occurred. secure fault|522x500
The current mbed studio debugging support is miserable. Only a few selected hardware monopolize the benefits of mbed support. There is no diversity there. The supported models by popularity are very similar. So studio is still a platform for compilation, but not enough for development.
The LPC55S69 is not loved by mbed, so I expect it will never have debugging support in mbed studio. mbed os 6 support is already gone. So this MPU will end its life with mbed os 5 and MCUxpresso. No update is needed for me unless there is a special fix in the new OS.
Let’s talk about the LPC1500 series. I have been using this MPU for a long time and I am still using the early mbed code. There was a bug in the ticker and timer early on, so I incorporated a fix. But It has been removed from mbed updates early. So I haven’t updated it at all. Some good things have happened recently. MACRUM made a bare metal version of mbed os 6 available for the LPC1500. I am very grateful for that!
I didn’t know anything about the external environment you referred to. So I did some research. This seems to be a promising environment. It seems to be more responsive than mbed studio at this time. It looks like these may work as a backup if my Eclipse project doesn’t work. If there are no problems with the debugger, there is no reason why it has to be MCUxpresso.
I’ll share my findings in case it might be helpful to someone else.
Overview of Visual Studio Code
What is Cortex-Debug?
Debugging support for ARM Cortex-M Microcontrollers with the following features:
Support J-Link, OpenOCD GDB Server
Initial support for STMicroelectronic’s ST-LINK GDB server (no SWO support yet)
Partial support for PyOCD and textane/stlink (st-util) GDB Servers (SWO can only be captured via a serial port)
Initial support for the Black Magic Probe (This has not been as heavily tested; SWO can only be captured via a serial port)
Cortex Core Register Viewer
In some cases the st-util GDB server can report incomplete/incorrect registers, so there may be some issues here.
Peripheral Register Viewer (Defined through standard SVD file)
SWO Decoding - “console” text output and binary data (signed and unsigned 32-bit integers, Q16.16 fixed point integers, single percision floating point values)
The registers that are part of the DWT, TPIU, and ITM debug components will automatically be configured and do not need to be set in firmware.
Firmware may still need to enable the SWO output pin - as this part of the setup is microcontroller dependant.
Decoding ETM data over the SWO pin is not currently supported.
Support for Custom ITM Data Decoders:
Ability to define JavaScript modules to decode complex data formats streamed over one or more ITM ports. Data can be printed to a output window, or sent to the graphing system.
Live graphing of decoded ITM data.
Raw Memory Viewer (“Cortex-Debug: View Memory” command)
Ability to view and step through the disassembled binary. There are three ways that disassembled code will be shown:
Disassembly code will automatically be shown if it cannot locate the corresponding source code.
You can manually see the disassembly for a particular function (“Cortex-Debug: View Disassembly (Function)” command)
You can set the debugger to always show show disassembly (“Cortex-Debug: Set Force Disassembly” command)
Globals and Static scopes in the variables view
Initial support for Rust code (most functionality is working; disassembly views and variables view may still have issues)
RTOS Support (J-Link and OpenOCD - RTOS supported depends on GDB server support)
As a general rule do not try to use stepping instructions before the scheduler of your RTOS has started - in many cases this tends to crash the GDB servers or leave it in an inconsistent state.
The mbed os sample code worked successfully on the LPC55S69 evaluation board from MCUxpresso. work|360x500
It’s unclear what ultimately caused the fault. I am not sure what was the final trigger, as I was changing the project settings while swapping some code around. Perhaps some combination of the above was accidentally enabled.
I’ve uploaded a worked project zip-file to github. Anyone should now be able to download it and check for reproducibility.
But I don’t know if the complex functionality works yet, as I’m only running a simple sample code.
