Linker script produces excessively large binaries for LPC1549

[ducky64]

Description of defect

The compiled binaries from objcopy are 33,587,200 bytes (=0x2008000), which is equivalent to the contents of flash, empty space inbetween, ram1, and ram2 banks. This causes problems with OpenOCD flashing, which uses the .bin (instead of .elf) files and seems to try to write past the flash banks.

This seems to be a problem in the LPC1549.ld and a result of different RAM banks for the .data and .heap sections, since (at least some) other LPC targets do not have this issue.

Experimentally, the .bin files have saner sizes if:

• line 141 is removed
• the .heap and .data section are in the same RAM bank
• an AT relocation directive is applied to .heap

I'm not super familiar with linker scripts, so I don't know which of the above is the right fix. But this might be an easy fix for someone more familiar with linker scripts?

Originally submitted as bug to platformio/platform-nxplpc#23

Target(s) affected by this defect ?

LPC1549

Toolchain(s) (name and version) displaying this defect ?

PlatformIO, which uses GCC-ARM

What version of Mbed-os are you using (tag or sha) ?

5.15.6
(per /platform/mbed_version.h; here is the version as defined by PlatformIO build scripts)

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

PlatformIO latest

How is this defect reproduced ?

Create a PlatformIO project with the LPC1549 and build it. It will produce an excessively large firmware.bin file.

[ciarmcom]

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/IOTOSM-3835

[0xc0170]

What board do you use? It has daplink running so you can drop-in the binary and test if that works? As this has been in the codebase for some time (LPCXpresso1549) and the board has mbed-interface (https://os.mbed.com/platforms/LPCXpresso1549/).

The target was removed since Mbed 6, only 5.15.

@JojoS62 Have you experienced any problems with flashing?

@ARMmbed/team-nxp Please review

[JojoS62]

I can confirm that I get the same binarysize when I use mbed-cli to build a program for this target. The .elf looks fine and I have used always a debugger to load the program into a LPCXpresso1549.
It looks like the space between flash and ram is padded with zero bytes, but I'm also not an expert for the linker description files. The result is the same with gcc 9 or 10.

[JojoS62]

I could fix it by adding (NOLOAD) to bss and stack segment.

--- a/targets/TARGET_NXP/TARGET_LPC15XX/device/TOOLCHAIN_GCC_ARM/LPC1549.ld
+++ b/targets/TARGET_NXP/TARGET_LPC15XX/device/TOOLCHAIN_GCC_ARM/LPC1549.ld
@@ -133,7 +133,7 @@ SECTIONS
     } > Ram0_16
 
     
-    .heap :
+    .heap (NOLOAD):
     {
         __end__ = .;
         end = __end__;
@@ -146,7 +146,7 @@ SECTIONS
     /* .stack_dummy section doesn't contains any symbols. It is only
      * used for linker to calculate size of stack sections, and assign
      * values to stack symbols later */
-    .stack_dummy :
+    .stack_dummy (NOLOAD):
     {
         *(.stack)
     } > Ram2_4

I don't understand why this should be necessary, there should not be any symbols in these segments.

[ducky64]

@0xc0170 we use custom boards with a 10-pin SWD header connected to a generic debug probe running CMSIS-DAP. So solutions specific to the LPCXpresso board might not work for us. We have a OpenOCD config lpc1549_openocd.cfg.txt for the LPC1549 (which we should probably get around to upstreaming at some point) that works for debugging and uploading sane-sized binaries, but not large binaries (well, it uploads, but hangs at verification, presumably when it tries to read an invalid address).

Additional note: opening the .elf with the disassembler shows the section for .heap, but also containing nothing. I haven't checked what that looks like if the linkerscript is modified to not produce excessively large binaries.

[JojoS62]

openOCD as well as pyOCD can handle elf files, so using the .bin should not be necessary.
http://openocd.org/doc/html/Flash-Programming.html
But of course, the bin file should be also correctly generated. I have used other targets like LPC1347 and used the binary file, there I did not see this filling.

[ducky64]

Flashing seems to work successfully with the .elf file, though PlatformIO is set to use the .bin file as the upload default. We can certainly override the upload configuration, but it'd be nice to have a proper fix too.