Hi Vincent,

Thanks for your response. I am glad that it is in the works. Do you know what is the timeline when the FOTA based platform for NRF52 be available? We are currently planning on using the Rigado BMD-300 module which has an nrf52 ble Chip on it and they have a custom bootloader which supports encrypted and unencrypted OTA firmware updates. However they expect only the application hex to be transmitted. Is there any way to separate the application hex from the hex file that is generated using the online mbed compiler. I am looking for a more standard way to separate the hex file, so I can load the resulting hex file over USB/OTA.

Thanks, Ajay.

Hello Ajay,

It is not possible to do that out of the box at the moment but if you build your project with mbed-cli, it is easy to add a new target reserved which doesn't merge the application with the softdevice:

• Open the file https:github.com/ARMmbed/mbed-os/blob/master/targets/targets.json in mbed-os.
• The base target for NRF52 targets is named MCU_NRF52 it contains an attribute named MERGE_SOFT_DEVICE which indicate to the build system if the softdevice should be merged or not. By default, this attribute is set to true.
• To avoid the merge of the softdevice, you can copy your current target in a new on, and set in the copy the attribute MERGE_SOFT_DEVICE to false. If you compile with this new target then the softdevice won't be merge with the application.

For instance, this is the copy of the NRF52_DK target which doesn't merge the softdevice:

    "NRF52_DK": {
        "supported_form_factors": ["ARDUINO"],
        "inherits": ["MCU_NRF52"],
        "macros_add": ["BOARD_PCA10040", "NRF52_PAN_12", "NRF52_PAN_15", "NRF52_PAN_58", "NRF52_PAN_55", "NRF52_PAN_54", "NRF52_PAN_31", "NRF52_PAN_30", "NRF52_PAN_51", "NRF52_PAN_36", "NRF52_PAN_53", "S132", "CONFIG_GPIO_AS_PINRESET", "BLE_STACK_SUPPORT_REQD", "SWI_DISABLE0", "NRF52_PAN_20", "NRF52_PAN_64", "NRF52_PAN_62", "NRF52_PAN_63"],
        "device_has": ["ANALOGIN", "ERROR_PATTERN", "I2C", "I2C_ASYNCH", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPI_ASYNCH", "SPISLAVE"],
        "release_versions": ["2", "5"],
        "device_name": "nRF52832_xxAA",
        "MERGE_SOFT_DEVICE": false
    }

Another thing I've noticed, an application running on the Rigado BMD-300 should start at 0x1C000 and have a maximal size of 0x2B000 bytes.

While the start offset is correct in the mbed linker script, it is not the case for the length. I advise you to modify the linker script otherwise if the size of the binary exceed the capacity it will be unnoticed.

Hi Vincent,

Has the near future come or is it coming soon? In other words, is the OTA DFU update for NRF52 already supported and if not, do you have a timeline? I'm working on project where we need to have this critical feature and we need to know if we should start developing in Nordic SDK (slower) or mbed (faster).

Thanks!

Hello Yogesh,

You didn't have to export your application, it is possible to use mbed cli to import it from a mercurial or git repository. Projects on developer.mbed.org are stored in mercurial repository, so it is possible to import them directly:

mbed import <repo_url>

More information about mbed cli can be found here.

Unfortunately, not all targets properties can be overridden otherwise I would have advise you this solution, it is much more simpler and less intrusive.

The online compiler use armcc under the hood, different compiler means different code and code size. Applications generated by GCC are more bloated by default because the I/O and file subsystems are much bigger.

These two subsystems are included in the binary because by default assertions are on and the C library mandate that an application should close opened file descriptor when the exit function is called.

It is possible to optimize your application to avoid the inclusion of those subsystems:

• Disable assertions by defining NDEBUG
• Instruct the system that it shouldn't close I/Os at exit by setting the "platform.stdio-flush-at-exit" target property to false.

In your mbed_app.json it looks like:

{
    "macros": [
        "NDEBUG=1"
    ],
    "target_overrides": {
        "*": {
	        "platform.stdio-flush-at-exit": false
        }
    }
}

Other optimizations tricks are also possible if you don't use the RTOS capabilities.