Target.mbed_app_start ignored in mbed_app.json

Mbed OS Best practice
1

I would like to compile an unmanaged bootloader and an application using mbed cli2 (mbed-tools) for an NUCLEO_F429ZI board.
Between bootloader and application I would like to place a configuration space of > 16KB.

My understanding is that I need to create two mbed projects, one for the bootloader and another one for the application. Now I am struggling with defining a new start address for the application.

After reading the documentation:

An unmanaged bootloader build is a method of controlling the link location of a program within Mbed OS. There are two configuration options available for changing the link location: target.mbed_app_start and target.mbed_app_size .
I concluded that I can change the start address of my application by stating these parameters in a mbed_app.json, here shifted by 64K as the default FLASH start is at 0x8000000.

{
    "target_overrides": {
        "*": {
          
            "target.mbed_app_start": "0x08010000",
            "target.mbed_app_size":     "0x40000"
        }
    }
}

The parameter explanation tells that e.g. for target.mbed_app_start:

The value of this parameter is available to C and C++ as APPLICATION_ADDR and to the linker as MBED_APP_START .

But when applying the the commands:

$mbed-tools configure -m NUCLEO_F429ZI -t GCC_ARM
$mbed-tools compile -m NUCLEO_F429ZI -t GCC_ARM

I do not get any compilation error, but I also do not find these parameters reflected in the build, neither in the generated mbed-stm32f429xi.link_script.ld (program start is still the default).
Also I did not find the parameter MBED_APPLICATION_ADDR defined in the generated build.ninja - I also cannot a compile source files using that parameter as the parameter (“…was not declared in this scope”) . Also the generated map file confirms the unchanged default application start address.

It seems that I miss a fundamental issue. Can anyone help?
Best regards
cdelfs

2

See https://github.com/ARMmbed/mbed-tools/issues/156 if it helps.

3

Hi Ladislas,
it helped! :partying_face: Many thanks!

Yesterday, I also created a custom mbed_lib.json and created a parameter to get a MBED_APPLICATION_ADDR definition (which worked, but did not improve anything), but I did not expect that doing the “same thing” for MBED_APP_START would do the job!

I hope that this workaround continues to work until mbed cli2 can cope with target.mbed_app_start.

Best regards
cdelfs

4

So, root cause is that mbed cli2 does not support this case - a workaround is needed and explained in the referenced post.

This is how used the proposed workaround:
I created a mbed_lib.json in the project root directory:

{
    "name" : "custom",
    "config": {
          "mbed_app_start": {
            "help": "Use a custom application start address",
            "macro_name": "MBED_APP_START",
            "value":  "0x08002000"
        },

        "mbed_app_size": {
            "help": "Use a custom application size",
            "macro_name": "MBED_APP_SIZE",
            "value":  "0x70000"
        }
    }
}

and did the compilation again (full build!). Of course, these values can be overwritten in an mbed_app.json, e.g.:

{
    "target_overrides": {
        "*": {          
            "custom.mbed_app_start": "0x08002500",
            "custom.mbed_app_size":     "0x60000"
        }
    }
}

As this is a workround, the mbed safety measures do not apply, e.g. usually mbed checks whether the start address is valid and also the size fits (using the content of the file mbed-os/tools/arm_pack_manager/index.json). So, whatever values are chosen, mbed will not complain and the linker will support arbitrary link results. It is up to the user to choose values fitting to the chip’s memory map and its FLASH/RAM sections.

1 Like