Adding a memory section causes linker to generate oversized file even with proper memory alignment

[Boris Matešin]

I'm currently working on a board diagnostic firmware and an accompanying Windows console app.
The Win part of the project is supposed to monitor the diagnostic firmware's progress through shared RAM locations (effectively, fixed-memory-address registers)
The firmware part of the project is supposed to perform automatic tests, store results in that shared chunk of RAM and in some cases check those addresses to see if any extra tests need to be done.

I'm using nRF SDK v14.1.0, GCC arm-none-eabi v6.3.1 20170620 and Make 3.81.

On the nrf52 firmware side, I set up the linker script as follows:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x23000, LENGTH = 0x5d000
  RAM (rwx) :  ORIGIN = 0x20002120, LENGTH = 0xDE60
  RAM_SHARE (rwx) :  ORIGIN = 0x2000FF80, LENGTH = 0x0080   /* 128 bytes for sharing over SWO */
}

...

SECTIONS
{
  . = ALIGN(4);
  .share_data :
  {
    PROVIDE(__start_share_data = .);
    KEEP(*(.share_data))
    PROVIDE(__stop_share_data = .);
  } > RAM_SHARE
} INSERT AFTER .cli_sorted_cmd_ptrs;

In the firmware itself I use a typedef struct with all results inside (basically a collection of int8 values) as follows:

static volatile TestResultSet __attribute__((section(".share_data"))) testResultsShared;

Here's the problem. If I set the testResultsShared variable set in the share_data section, once make creates the final hex file it blooms to a size of 512 MB.
The hex file has about 220 kB of actual data before it gets nul-padded for the remaining 511.78 MB - I verified this with a standard hex-editor.

This also has a side-effect that generating settings using nrfutil takes a much longer time and takes up all available RAM - forum user schef ran into that side-effect as well.

If I take out the __attribute__((section...))) extension, the generated file shrinks back to circa 220 kB which is more like the expected size - but then I have no guarantee the testResultsShared elements will be where I need them.

Can anyone point out an obvious (or not so obvious) error here?

[Håkon Alseth]

Hi,

 

Try adding (NOLOAD) around your section.

.share_data(NOLOAD) :
{
  PROVIDE(__start_share_data = .);
  KEEP(*(.share_data))
  PROVIDE(__stop_share_data = .);
} > RAM_SHARE

 

PS: I recommend that you declare your type with "type_t name __attribute__((used))" in case you change optimization settings and the compiler/linker finds out it can dump this section.

 

Cheers,

Håkon

[Boris Matešin]

Hi, Håkon,

thank you for your guidance, I added the (NOLOAD) directive to the section as you suggested.
After compiling with optimization level -O2 (our standard for release versions):

• the resulting hex file was the proper size (220 kB)
• the MAP file showed the share_data section located at 0x2000ff80
• the settings file was generated within 3 seconds and nrfutil did not use too much memory
• the firmware performed as expected

Since the optimization level was unchanged since the last version and everything worked, I might add the __attributed__((used)) later on, if necessary.

Marking as resolved. Thank you!