mbed-cli -> MSBuild for NXP i.MX

[szenger]

I am currently trying to port an mbed-os project for the MIMXRT1050-EVK development board (in QSPI configuration) to MSBuild in Visual Studio, following this tutorial: https://visualgdb.com/tutorials/arm/import_sdk/
While the exported Makefile ($mbed export -i GCC_ARM -m MIMXRT1050_EVK) from the example can be built via $make and works just fine, the compilation setup from VisualGDB creates a .bin file after small modifications, which neither seems to run on the controller nor can be debugged (“Frame not in module” via JLink).
Small modifications for the preprocessor made are,

1. Renaming the startup file startup_MIMXRT1052.s to startup_MIMXRT1052.S
2. Activating preprocessing for the linker script. Afterwards removing of all #define macros in PreprocessedLinkerScript.ld

The binary from MSBuild also is 7kB smaller than the one from make (60kB vs 53kB). The first bytes (startup) seems to be identical in both files.

Are there any known issues to this? Thanks!

[support]

Hi,

No problem. VisualGDB offers 2 troubleshooting tools to address this type of issue:

• First of all, you can use the Embedded Memory Explorer to compare the build produced by MSBuild against the build produced by mbed-cli. Most likely, it will be missing some symbols, or using different versions of symbols.
• You can also examine the .rsp files produced by MSBuild and compare them against the mbed-cli build logs. This approach does require substantial time, although it allows tracking down every difference between the 2 build setups and getting exactly the same result as the original project. See this tutorial for a detailed example.

[szenger]

Hello!

Thanks for your reply. The embedded memory explorer indeed did reveal an alignment issue. Oddly, the sections are placed correctly, while the whole alignment is off (see attachments).
Both builds use an identical linker script. I could not find SRAM_DTC, SRAM_ITC or SRAM_OC anywhere within the project at all (Visual Studio CTL+SHIFT+F). Memory alignment in both files looks like:

[...]
MEMORY
{
m_flash_config (RX) : ORIGIN = 0x60000000, LENGTH = 0x00001000
m_ivt (RX) : ORIGIN = 0x60000000 + 0x1000, LENGTH = 0x00001000
m_interrupts (RX) : ORIGIN = 0x60000000 + 0x2000, LENGTH = 0x00000400
m_text (RX) : ORIGIN = 0x60000000 + 0x2400, LENGTH = 0x400000 - 0x2400
m_text2 (RX) : ORIGIN = 0x00000000, LENGTH = 0x00020000
m_data (RW) : ORIGIN = 0x80000000, LENGTH = 0x01E00000
m_ncache (RW) : ORIGIN = 0x81E00000, LENGTH = 0x00200000
m_data2 (RW) : ORIGIN = 0x20000000, LENGTH = 0x00020000
m_data3 (RW) : ORIGIN = 0x20200000, LENGTH = 0x00040000
}
SECTIONS
{
.flash_config :
{
. = ALIGN(8);
__FLASH_BASE = .;
KEEP(* (.boot_hdr.conf))
. = ALIGN(8);
} > m_flash_config
ivt_begin= ORIGIN(m_flash_config) + LENGTH(m_flash_config);
.ivt : AT(ivt_begin)
{
[...]

 

I also wrote a script to extract each command along with the *.rsp files from the ProjectName-Debug.bat and compared the output with the commands $make would use. This totals at 906 toolchain calls for gnu make and 905 for VisualGDB. We managed to identify the additional call as the preprocessing of the linker script. While we didn’t get too deep into the compile and assemble commands so far, we tried to look closely at the linking, but could not find any significant difference.

make (1017+711+61600 columns, last being .link_options.txt)
arm-none-eabi-cpp -E -P -Wl,--gc-sections -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 -Wl,-n -Wl,--wrap,printf -Wl,--wrap,sprintf -Wl,--wrap,snprintf -Wl,--wrap,vprintf -Wl,--wrap,vsprintf -Wl,--wrap,vsnprintf -Wl,--wrap,fprintf -Wl,--wrap,vfprintf -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=softfp -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -fmessage-length=0 -fno-exceptions -ffunction-sections -fdata-sections -funsigned-char -MMD -fomit-frame-pointer -Og -DMBED_DEBUG -DMBED_TRAP_ERRORS_ENABLED=1 -DMBED_MINIMAL_PRINTF -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=softfp -DMBED_RAM1_START=0x0 -DMBED_RAM1_SIZE=0x20000 -DMBED_RAM_START=0x20000000 -DMBED_RAM_SIZE=0x60000 -DMBED_BOOT_STACK_SIZE=1024 -DXIP_ENABLE=0 .././mbed-os/targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_MIMXRT1050/device/TOOLCHAIN_GCC_ARM/MIMXRT1052xxxxx.ld -o nxp_wsl_gmake.link_script.ld
arm-none-eabi-gcc -Wl,--gc-sections -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 -Wl,-n -Wl,--wrap,printf -Wl,--wrap,sprintf -Wl,--wrap,snprintf -Wl,--wrap,vprintf -Wl,--wrap,vsprintf -Wl,--wrap,vsnprintf -Wl,--wrap,fprintf -Wl,--wrap,vfprintf -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=softfp -DMBED_RAM1_START=0x0 -DMBED_RAM1_SIZE=0x20000 -DMBED_RAM_START=0x20000000 -DMBED_RAM_SIZE=0x60000 -DMBED_BOOT_STACK_SIZE=1024 -DXIP_ENABLE=0 -T nxp_wsl_gmake.link_script.ld --output nxp_wsl_gmake.elf @.link_options.txt -Wl,--start-group -lstdc++ -lsupc++ -lm -lc -lgcc -lnosys -Wl,--end-group

VisualGDB (total of 81355 columns)
arm-none-eabi-g++.exe -o VisualGDB/Debug/IMXRT1050_NXP -Wl,-gc-sections -T./PreprocessedLinkerScript.ld --specs=nano.specs --specs=nosys.specs -Wl,--gc-sections -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 -Wl,-n -Wl,--wrap,printf -Wl,--wrap,sprintf -Wl,--wrap,snprintf -Wl,--wrap,vprintf -Wl,--wrap,vsprintf -Wl,--wrap,vsnprintf -Wl,--wrap,fprintf -Wl,--wrap,vfprintf -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=softfp -DMBED_RAM_START=0x20000000 -DMBED_RAM_SIZE=0x60000 -DMBED_RAM1_START=0x0 -DMBED_RAM1_SIZE=0x20000 -DMBED_BOOT_STACK_SIZE=1024 -DXIP_ENABLE=0 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mcpu=cortex-m7 -Wl,--start-group VisualGDB/Debug/main.o [...] -lm -lstdc++ -lsupc++ -lm -lc -lgcc -lnosys -Wl,--end-group

 

Is it even possible that this alignment issue could be caused by the compiled files before linking? Or would it make sense to dissect the prior build process (900+ lines) after all? Thanks!

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Linker script preprocessing could be related to this. Please try linking the MSBuild project using the preprocessed linker script produced by the mbed-cli build.

If it doesn’t help, you can quickly narrow down the problem by combining command lines from different builds. E.g. try linking the object files produced by mbed-cli with the linker command line from msbuild, and vice versa. If the problem appears to be specific to the linker command line, try gradually changing the broken command line until it matches the working one, rechecking the results after every step.

If the problem is triggered by using the object files from MSBuild, please try replacing half of them with the versions built by mbed-cli, and check if it solves the problem. This should help you quickly find the specific object file triggering the problem.

[szenger]

Hello again,

I’m not using the preprocessor for linker files on MSBuild. Instead the setup currently uses the file from mbed-cli after preprocessing, which is identical to the linker file from MSBuild after preprocessing – aside of unused #defines in the header. All the processed linker files from MSBuild, mbed-cli or gmake are identical.

Sadly, it currently looks like there are issues in the object files as well as the linker command. I’ve narrowed the object files down to a folder within mbed-os, but whether those are changed or the linker command it breaks the build.
What is most puzzling, however: When copying the .elf file from the mbed-cli compilation (and renaming accordingly), the embedded memory explorer still shows a broken layout (see attachments in last post)? But if I delete the .elf file, it indeed says the file does not exist. Is this expected behavior?

[support]

Hi,

The Embedded Memory Explorer reloads the project file when it finishes building, or when you close and reopen the Memory Explorer window. If you believe it shows incorrect data, please try following the steps below to double-check it:

1. Create a special build of the ELF file with a specific symbol (e.g. test123)
2. Verify that the ELF file actually contains it by running arm-none-eabi-objdump -t [ELF file]
3. Replace the output of the project
4. Fully close Memory Explorer and reopen it via the command in the View menu
5. Recheck whether it shows the newly added symbol

If it still shows the old file layout (e.g. doesn’t show the new symbol), please attach the relevant screenshots and we will help you get it working

[szenger]

Thank you for this command. None of both ELF files actually show the memory partitioning from the linker file (like m_ivt or SRAM_DTC, see attachments in previous post). Where does the embedded memory explorer get this information from? The controller/board in question has three memory setups for code execution: External Hyperflash/QSPI or internal RAM. Could the (presumably wrong) information origin from the project setup? Would this lead to more wrong settings due to?

I also simply copied a ELF file from the MSBuild setup to the mbed-cli one – and it looks fine this way.

[support]

For mbed projects the list of memories (e.g. m_ivt) is computed by parsing the linker script, since there is no other source for this information. For MSBuild projects it’s taken from the device definition shipped with the BSP.

[szenger]

This explains a lot. Then there (probably) is no memory alignment issue in first place. I also finally managed to find the culprit in the linker command: Both -mfloat-abi=hard and -mfloat-abi=soft are defined. If -mfloat-abi=hard is removed the code works. By now I do not know if this is correct, though. Now remains to,

1. Find where to disable -mfloat-abi=hard in the project settings. It seems to be added automatically somewhere outside of Properties -> Linker?
2. And more importantly, why the Debugger cannot set any breakpoints or map any code. Anything is “Frame not in module”.  Any directions where to start here?

Thanks!

[support]

The -mfloat-abi setting should make it to both compiler and linker settings. The easiest way to ensure it would be to use the Configuration Properties -> ARM Settings -> Floating-point ABI setting.

The “frame not in module” error would typically mean that the CPU stopped outside any code that has symbols. You can double-check it by hardcoding a breakpoint (e.g. asm(“bkpt 255”) followed by asm(“nop”) in main()).  Once it hits, try checking the disassembly view. If it displays the “bkpt 255” and “nop” instructions but doesn’t map them to the main source file, there is a problem with symbols. If the code is stopped on a completely different instruction, the problem is not related to the debugger.

[szenger]

When setting this option it also got removed from linker command, thanks!

The hardcoded breakpoint works like a charm and shows in the disassembly as expected too. (The debugger should be fine because it works in NXP’s native example projects.) How do I fix debugging symbols for embedded devices in custom projects in VisualGDB? Is this related to the BSP and different type of memory being used by default?

Attachments:

You must be logged in to view attached files.

[support]

Thanks, this indeed looks like a debug symbol problem. Please see the following tutorial for detailed instructions troubleshooting it: https://visualgdb.com/tutorials/linux/symbols/

[szenger]

I didn’t know that applies for embedded setups too! But that worked well indeed, thanks!

For anyone else reading this thread, stripping debug information flag is not capital S, but also capital S apparently. -s = -Wl,-S, but not -S

[Author]

Posts