bootloader project in nCS

Hi,

1. Is bootloader file and firmware file, different for projects build on nCS..?
    Or a single executable build file consists both bootloader & firmware..?

2. Can you suggest a sample program to build a bootloader project..?

Thanks,

  • Also,

    3. I would like to know more about "mcuboot" that nCS uses.
    Kindly suggest.

  • Hello,

    In NCS, the bootloader is enabled through configurations, mostly. 

    I suggest that you check out the documentation of FOTA upgrades:

    https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.9.1/nrf/ug_nrf52.html#fota-upgrades

    And there is also a written guide on how to add DFU to your project, that I can recommend:

    https://devzone.nordicsemi.com/guides/nrf-connect-sdk-guides/b/software/posts/ncs-dfu

    If you struggle with the implementation, I suggest that you follow the guide first, and add DFU to the smp_svr sample from NCS, so that you know that everything around (uploading via nRF Connect for iOS/Android/mcumgr) is working as it should, before you start looking into potential issues in your custom application.

    BR,

    Edvin

  • Hello ,

    And there is also a written guide on how to add DFU to your project,

    Towards DFU, i see that we make the following configuration to the project:

    # Ensure an MCUboot-compatible binary is generated.
    CONFIG_BOOTLOADER_MCUBOOT=y

    So,
    1. By enabling MCUBOOT what happens..?
    2. Where is the bootloader image file in the device memory..?
    3. Is the boot loader image file different than firmware image file or bootloader code is integrated into the firmware image file..?

    Thanks,

  • 1: By enabling MCUBOOT the compiler will build the MCUBOOT bootloader for you, and add it to the build folder. This means that when you flash your project, it will flash the bootloader and the application. Also, when you build, it will build the uppdate binary file in build\zephyr\app_update.bin, so if you do any updates, you can use this to update using DFU.

    2: In the beginning. After enabling CONFIG_BOOTLOADER_MCUBOOT=y your build folder will contain a file called partitions.yml, which will list all the partitions in the flash. 

    part of this file will say something like:

    app:
      address: 0xc200
      end_address: 0x80000
      region: flash_primary
      size: 0x73e00
    littlefs_storage:
      address: 0xf8000
      end_address: 0xfe000
      placement:
        align:
          start: 0x4000
        before:
        - end
      region: flash_primary
      size: 0x6000
    mcuboot:
      address: 0x0
      end_address: 0xc000
      placement:
        before:
        - mcuboot_primary
      region: flash_primary
      size: 0xc000

    So in this case you can see that the bootloader is located at address 0x0, while the app is located at 0xc200.

    3: Depending on what chip you are working on. If your chip only have one core, then the build folder will have one .hex file that is called either zephyr.hex or merged.hex. If you have several cores, then there will be a separate file for each core. However, the bootloader will be included in the files if CONFIG_BOOTLOADER_MCUBOOT=y.

    BR,
    Edvin

  • Hello ,

    Thank you for the info,

    Further,

    1. How does how does the image boot if I have not enabled CONFIG_BOOTLOADER_MCUBOOT=y..?

    2. Some preexisting bootloader does the job or if system does not find anything at the address,

    bootloader is located at address 0x0

    It will straight away jump to the firmware file address 

    app is located at 0xc200

    ..??

    3. Can you please suggest if this "BOOTLOADER_MCUBOOT" checks for firmware file image code signing before booting the image..?

    4. If it does, how does it use the key for code signing check on the firmware file..?

    5. How can I update this key..?

    Thanks,

Related