Hi,
McuXpresso 11.5 includes ld 2.37. This version of the linker will not link an executable file into the final binary. The executable file in question is the binary application for the M0A CPU, which gets linked into the M4 CPU binary on an LPC4300. This is the console error message:
/usr/local/mcuxpressoide-11.5.0_7232/ide/plugins/com.nxp.mcuxpresso.tools.linux_11.5.0.202107051138/tools/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: cannot use executable file '../../../../common/example/LPC4370/b_m4/../b_m0a/Debug/B_M0A.axf.o' as input to a link
This all worked fine until a recent change in ld. Here's a link to a bug report on the issue:
https://sourceware.org/bugzilla/show_bug.cgi?id=26223
https://sourceware.org/bugzilla/show_bug.cgi?id=26047
Is there any workaround for this? Is there an alternative way to embed the M0A/M0S binary into the M4 binary that gets around the now-forbidden executable input file?
Thanks - Eamonn
已解决! 转到解答。
Hi Alice,
Thanks for taking this up.
You can replicate this easily enough.
Create a multicore LPC_LINK2 project for M4 and M0APP as per Chapter 18 of MCUXpresso IDE User Guide.
Build the M0 and M4 projects as normal. Everything should link properly.
Then, modify the M0A object file, e.g. "example_M0A.axf.o" as follows:
The final appended command in the M0A linker command " && dd if=/dev/zero of="ex_m0a.axf.o" bs=1 seek=16 conv=notrunc count=2" is used to change the ELF object type from ET_EXEC (0x02) to ET_NONE (0x00).
Use a hex editor and change the byte at offset 0x10 from 0x00 to 0x02 (undoing what dd does above). You now have an executable object, and when you build the M4 project, the linker will complain about trying to link an executable input file.
I can see why the dd command was added to avoid the issue. I can do something similar in my project makefile. (This is an old project which uses its own makefiles, and this is why the M4 link is failing: we link in the unmodified axf.o M0A object.)
You can mark this as solved, since I can replicate what the IDE is doing in my own project.
Thanks again - Eamonn
Hi Alice,
Thanks for taking this up.
You can replicate this easily enough.
Create a multicore LPC_LINK2 project for M4 and M0APP as per Chapter 18 of MCUXpresso IDE User Guide.
Build the M0 and M4 projects as normal. Everything should link properly.
Then, modify the M0A object file, e.g. "example_M0A.axf.o" as follows:
The final appended command in the M0A linker command " && dd if=/dev/zero of="ex_m0a.axf.o" bs=1 seek=16 conv=notrunc count=2" is used to change the ELF object type from ET_EXEC (0x02) to ET_NONE (0x00).
Use a hex editor and change the byte at offset 0x10 from 0x00 to 0x02 (undoing what dd does above). You now have an executable object, and when you build the M4 project, the linker will complain about trying to link an executable input file.
I can see why the dd command was added to avoid the issue. I can do something similar in my project makefile. (This is an old project which uses its own makefiles, and this is why the M4 link is failing: we link in the unmodified axf.o M0A object.)
You can mark this as solved, since I can replicate what the IDE is doing in my own project.
Thanks again - Eamonn