Build No Longer Fails if 'target.restrict_size' Exceeded

[mattbrown015]

Description

It appears Add support for nrf52_dk bootloader #8097 has broken things for us! :-(

We have "target.restrict_size": "0x35800" set in our mbed_app.json and previously our build would fail if we exceeded the size. For example:

Using ROM regions application, post_application in this build.
  Region application: size 0x35800, offset 0x8000000
  Region post_application: size 0xa800, offset 0x8035800
...
Merging Regions
  Filling region application with .\BUILD\TEST_TARGET\GCC_ARM\application.bin
[ERROR] Contents of region application does not fit
[mbed] ERROR: "c:\python27\python.exe" returned error.
...

This is no longer the case, I suspect because of tools: fix up build_api padding logic and clean up unused code which removes:

if part_size > region.size:
    raise ToolException("Contents of region %s does not fit"
                         % region.name)

Build output now look likes:

Using ROM regions application, post_application in this build.
  Region application: size 0x35800, offset 0x8000000
  Region post_application: size 0xa800, offset 0x8035800
...
Merging Regions
  Filling region application with .\BUILD\PENGUIN\GCC_ARM\temperature-sensor_application.bin
Space used after regions merged: 0x359cc
Merging Regions
  Filling region application with .\BUILD\PENGUIN\GCC_ARM\temperature-sensor_application.bin
Space used after regions merged: 0x359cc

Our app started crashing and it has taken a couple of hours to realise why because the '0x359cc' wasn't noticed. Primarily because we were under the impression we would get a build failure if it exceeded '0x35800'.

We've been hit with a double whammy this week because it is changes to Mbed OS that have caused our code to grow in size! MPU API #8335 added 824 bytes of code, see MPU API Increases Code Size and Cannot be Completely Removed #9007.

We shall spend the rest of the afternoon removing some cruft so that our app fits again. :-)

Issue request type

[ ] Question
[ ] Enhancement
[X] Bug

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-280

[cmonr]

@JammuKekkonen @naveenkaje What was the reason that the check was removed?
I didn't find anything in the PR's comments.

[naveenkaje]

I suspect that got removed because we refactored how the padding is done now where we iterate through the segments and pad the gaps. I sumbitted #9021 to address the issue that @mattbrown015 is seeing.

[theotherjimmy]

@cmonr It got removed because that's no longer how we size regions. We size regions based only on the segments within the intelhex file that are port of ROM.

[theotherjimmy]

@mattbrown015 It sounds like you're using a target that incorrectly reports that it supports bootloader mode. Check that your linker script takes the defines MBED_APP_START and MBED_APP_SIZE into account.

[mattbrown015]

Hi @theotherjimmy,

Our target is a STM32L4. We've created a custom target based on NUCLEO_L432KC which supports a bootloader. We're not using a bootloader and haven't changed much in our target.

I can see the standard STM32 provided linker script references MBED_APP_START and MBED_APP_SIZE.

Are you saying that I should be defining MBED_APP_SIZE in mbed_app.json?

I'm off work for a couple of days so can't try for myself at the moment.

Thanks.

[theotherjimmy]

Are you saying that I should be defining MBED_APP_SIZE in mbed_app.json?

No. You are using "managed bootloader mode" so you will already see MBED_APP_SIZE passed to your linker script. You should use them in your linker script to restrict the size of your application so that you get a linker failure when your bootloader does not fit.

[mattbrown015]

I've had a look at this now and got a better handle on the Mbed OS build system. I can see you running the preprocessor to generate .link_script.ld.

I think probably I'm abusing the bootloader configuration slightly. We're not using a bootloader and managed or unmanaged bootloader mode is irrelevant to me. All I wanted to do was restricted the amount of flash allocated to .text/.data/.bss without writing my own linker script. I still don't want to create my own linker script, that just feels like something else that I would need to maintain.

I can see in .link_script.ld that the flash memory length is what I want:

  FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 0x35800

rather than:

  FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 256k

So my question now is, why isn't the link failing?

I now appreciate this probably isn't your problem but perhaps you understand these things better than me.

I'm guessing that the problem is related to strings. I can see our debug strings appear in the top of flash so it is always a string that overflows 0x35800.

In turn I'm guessing that it is something to do with the placement of the constants strings in the STM32 linker script. I'm using GCC. The STM32 linker script appears to place .text, .data, .bss and .rodata in FLASH but there are a great many wildcards ('.', '.', etc) that I don't understand.

[theotherjimmy]

So my question now is, why isn't the link failing?

Good question; I don't know. I expect the link to fail with that linker script.

If you provide me with a bit more specifics on the target (like which linker script in mbed-os is used) I might be able to help more.

Stuff that's not directly related to your question below the line.

---

I think probably I'm abusing the bootloader configuration slightly.

Nope. You're using the "I'm building a bootloader" use case of managed bootloader mode. The only "abuse" here is that you're not building a "bootloader", but the tools really don't care about that at all.

We're not using a bootloader and managed or unmanaged bootloader mode is irrelevant to me.

Perhaps you're not using a bootloader, or even making one. That just means that the tools mode you're using is named poorly (my bad), not that it's semantics are irrelevant.

[mattbrown015]

Our custom target inherits from NUCLEO_L432KC so the mbed-os linker script is STM32L432XX.ld:

mbed-os/targets/TARGET_STM/TARGET_STM32L4/TARGET_STM32L432xC/device/TOOLCHAIN_GCC_ARM/STM32L432XX.ld

[theotherjimmy]

My intuition is that the AT here: https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/TARGET_STM32L4/TARGET_STM32L432xC/device/TOOLCHAIN_GCC_ARM/STM32L432XX.ld#L88 may be working against us here and placing the contents of .data sections that overflow the end of your application's region. You should be able to check this by running arm-none-eabi-nm BUILD/<your-target>/GCC_ARM/<your-app>_application.elf | sort and looking for addresses > 0x08035800 and < 0x20000000. You should specifically look for the _edata symbol: https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/TARGET_STM32L4/TARGET_STM32L432xC/device/TOOLCHAIN_GCC_ARM/STM32L432XX.ld#L120 Which will indicate that the data section is what overflowed rom.