• State Verified Answer
  • Locked Locked
  • Replies 23 replies
  • Subscribers 70 subscribers
  • Views 3803 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 300592
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Firmware update without DFU

Jithin A

Hi, I am new to the Nordic environment. So far I have done all the integration by going through your examples code which is very good.

Now, one thing I have no knowledge about is updating the firmware image(non-secure + TF-M) without using DFU.

I do not want FW update over DFU for some personal reasons.

Please guide me to any reference or documentation for how to build a bootloader and configure the application image to run with the bootloader and do OTA update.

I do not know from where to start for implementing the OTA update.

Thank you in advance.

My setup:

NRF SDK: v2.2.0

Board: nRF5340-DK

Parents
  • 0

    Hi,

    Can you clarify what you mean by not wanting to do fw update over DFU? DFU is device firmware update, so if you want to update your device, then this will be DFU, Do you mean that you do not want to update the device over serial (e.g. UART), but only over the air?

    Best regards,

    Marte

Reply
  • 0

    Hi,

    Can you clarify what you mean by not wanting to do fw update over DFU? DFU is device firmware update, so if you want to update your device, then this will be DFU, Do you mean that you do not want to update the device over serial (e.g. UART), but only over the air?

    Best regards,

    Marte

Children
  • 0 in reply to Marte Myrvold

    The reason I do not want to do DFU is we are using our own crypto algorithms to transfer any data over BLE.

    Let me explain what I need to do actually

    I get the FW image over BLE which later it is decrypted and is stored in the desired partition.

    Now on the next boot, I need the bootloader to check if there is any new image downloaded and boot the new image if so.

  • 0 in reply to Marte Myrvold

    Hello, just to let you know that I need to implement this onto my project with high priority.

    Please let me know if I am missing anything to explain my need.

    Please help me with the integration ASAP.

  • +1 in reply to Jithin A

    Hi,

    Thank you for clarifying. As long as you have MCUboot enabled and save the image in the correct area in flash and with the correct metadata (header + trailer), then the transport method is irrelevant. To enable MCUboot you must set the following configuration in prj.conf:

    CONFIG_BOOTLOADER_MCUBOOT=y

    The metadata can contain information about booting information, image hash, etc. You can find more about this, both header and trailer, in MCUboot Bootloader Design. There you will also find information about image slots, swapping, and more.

    As for area in flash, when you enable MCUboot with the configuration above, the partition manager will automatically configure partitions. You can see the partitions after you have built the application by running the following command:

    west build -t partition_manager_report

    If you are using VS Code with our extension you can also see it by selecting the Memory report action, and going to Partitions in the generated report. As an example, adding MCUboot support to the Blinky sample, the partitions will look lilke this:

      flash_primary (0x100000 - 1024kB):
+-------------------------------------------------+
| 0x0: mcuboot (0xc000 - 48kB)                    |
+---0xc000: mcuboot_primary (0x7a000 - 488kB)-----+
| 0xc000: mcuboot_pad (0x200 - 512B)              |
+---0xc200: mcuboot_primary_app (0x79e00 - 487kB)-+
| 0xc200: app (0x79e00 - 487kB)                   |
+-------------------------------------------------+
| 0x86000: mcuboot_secondary (0x7a000 - 488kB)    |
+-------------------------------------------------+

  sram_primary (0x40000 - 256kB):
+--------------------------------------------+
| 0x20000000: sram_primary (0x40000 - 256kB) |
+--------------------------------------------+

    As you can see, here the primary MCUboot image slot starts at 0xc000, and the secondary image slot at 0x86000.

    Best regards,

    Marte

  • 0 in reply to Marte Myrvold

    Thank you so much for the reference


    I see it’s a lot of things to take in.
    Anyway after going through the bootloader reference you shared earlier, I have below 2 questions

    1. How to insert header and trailer metadata to my application image?

    2. How to write any data into the specific address in the flash?
    —> Currently I am using PSA protected storage APIs for accessing flash inside TF-M and I see I can not specify the destination address in any of PSA PS APIs.

    NOTE: I have TF-M partition in my application and anything I need to do with the flash are should be done inside TF-M partition.
    I can not use non-secure partition due to some security purposes.

    Please guide me through this.

    I appreciate your support.

  • +1 in reply to Jithin A

    Hi,

    Jithin A said:
    1. How to insert header and trailer metadata to my application image?

    You can use imgtool to sign images and add metadata, see the imgtool documentation. Additionally, you can generate private and public keys with imgtool. Make sure to add the --pad flag for the image trailer.

    For an example on how to use imgtool for manually signing you can check out one of my colleagues examples: mcuboot_manual_sign. Please not that in that example, mcumgr is used, so the necessary commands will differ somewhat from what you should use. See the documentation above for more information about the different flags and which you should use.

    Jithin A said:
    2. How to write any data into the specific address in the flash?

    If you use the function dfu_target_write(), the firmware image will be written into MCUboots secondary slot, see MCUboot-style upgrades for more information on this.

    Best regards,

    Marte

Related