• State Verified Answer
  • Locked Locked
  • Replies 10 replies
  • Subscribers 91 subscribers
  • Views 1896 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 285193
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

Can I download new image in the place of application ?

RAM_MS

As per DFU concept the image management command handlers makes it possible to upload, list, test and confirm the image(s), while the OS management command handlers makes it possible to reset the chip (and run the echo command). Since the DFU support is added to the application, the chip needs to be reset, to give control to MCUboot, which will validate the new uploaded image and swap it with the old image.

But I want to erase old image 1st then download new image using DFU because my application is occupy 90 % of memory so vacant space is not available to download new image and it is hard to add external flash memory because hardware design is completed.

How to do it ?

Any settings is there to do so.

Thanks ,

ram

Parents
  • 0

    Hi Ram,

    Which transport do you use for DFU?

    MCUboot does not have any other transport than serial, and that is for serial recovery. If you want another transport (like Bluetooth) or more features than you get with serial recovery, you need to do handle the transport in the application, and then you need to store the new image separately from the existing image. One alternative could be to use an external flash in addition to the nRF, and have the secondary slot there.

    Einar

  • 0 in reply to Einar Thorsrud

    Hello Einar ,

    Einar Thorsrud said:
    Which transport do you use for DFU?

    I am using serial.

    Einar Thorsrud said:
    you need to do handle the transport in the application, and then you need to store the new image separately from the existing image.

    I don't want to store new image separately .

    Instead I want  overwrite-based image upgrades,

    please guide steps to do so.

    Thanks ,

    Ram

  • 0 in reply to RAM_MS

    That is correct. Bluetooth transport must be done by the application, and the application cannot overwrite itself.

  • 0 in reply to Einar Thorsrud

    Hello Einar,

    Thanks for your support .

    Ram

  • 0 in reply to RAM_MS

    Hello Einar ,

    Another clarification I want to know . 

    My bootloader is secure_bootloader_ble_s132. 

    And by this I updated my application ble_app_blinky_s132 via nrf_connect app from mobile.

    So bootloader is always there placed in starting address of flash .Again I put in it bootloader mode and want to update a new application lets ble_app_beacon_s132. 

    And I want to new application should overwritten in the place of old application ble_app_blinky_s132.

    It is not possible via Bluetooth bootloader?

    Thanks ,

    Ram  

  • +1 in reply to RAM_MS

    Hi Ram,

    Earlier you were describing MCUBoot and SMP server etc. All I have stated before applies to that bootloader, and this is what is used with the nRF Connect SDK.

    What you are describing now is the secure bootloader from the nRF5 SDK. This is a completely different bootloader, that has nothing to do with MCUBoot, SMP server etc. This is a completely different bootloader where the transport is in the bootloader, so things are very different. In the nRF5 SDK bootloader, you can have only a single application bank, and updates via both serial and DFU can work without the need for flash space to store another application image. In fact, you do not need any additional space at all, as long as you can fit the Bootloader, MBR, application and bootloader settings page (and optionally MBR params). For Bluetooth, you also need the SoftDevice.

    To understand the nRF5 SDK bootloader is recommend Getting started with Nordic's Secure DFU bootloader, a step by step guide. You should also refer to the bootloader examples and bootloader modules documentation.

    Key question: Which SDK version are you using? If you are using the nRF5 SDK, then the nRF5 SDK bootloader is what you should use, and this supports what you have requested. But please discard all you have read about the MCUBootloader, both the documentation you linked to an all discussion here. That has absolutely no relevance for the nRF5 SDK bootloader.

  • 0 in reply to Einar Thorsrud

    Hello Einar ,

    So summary of discussion is if I want overwrite application upgrade via OTA,I should use nRF5 SDK bootloader.

    nRF Connect SDK bootloader via OTA is not support overwrite .

    Right ?

    Thanks,

    Ram

Reply Children
Related
Terms of service