• State Verified Answer
  • Replies 1 reply
  • Subscribers 73 subscribers
  • Views 454 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 313715
Options

nRF5340 FOTA with APP rollback

crzyrndm

I have an application where the nRF53 receives updates from an internet connected device and if (post-update) that connection is failing for whatever reason, the application will need to be able to revert. I would like to also support NET core updates but the simultaneous update functionality is clearly not suitable because it either disallows rollbacks or effectively renders the NET core inoperable (doc link)

  • The unofficial samples repo "non-simultaneous" nrf5340 is a blank and the dependencies between the various configuration inputs (Kconfig/DT/CMake for each image + partition manager) are very interlinked so I'm looking to see if there is a baseline sample for this sort of application available (NET core updated independently of APP core) and/or what kconfig needs to look like to support this
  • Can I update the APP to something that would potentially send commands the NET core doesn't know about and then schedule a NET upgrade to match? NET core updates should only ever be feature additions so this isn't *necessary* but is nice to have
  • Is there a way to "version" the hci_rpmsg (default nRF53 BT NET image) image and query that? I can add tracking externally if not
  • Do I need to be wary of updating the SDK version in future (NET core updates in general not just independent updates)
  • If the net core does become unresponsive, is it only the NET application that is corrupt (i.e. is the b0n image write protected and can mcuboot be used to write over (effectively) a blank NET application or is outside input required to recover a NET core?
  • Can I use the mcuboot downgrade prevention to create versions that can't work with an old net firmware (e.g. <NET VERSION>+<APP_VERSION> for CONFIG_MCUBOOT_IMAGE_VERSION). The docs indicate that the value after the `+` doesn't matter but also mention it as a number elsewhere. Would 2+3.4 still work to prevent it reverting to 1+... but allow any 2+... version (and if so is this guaranteed behaviour or an artifact of the current implementation )

TLDR: That got a bit rambly but I'm looking for information about how to setup/support non-simultaneous FOTA updates for a nRF53

Parents
  • +1

    Hi,

    The unofficial samples repo "non-simultaneous" nrf5340 is a blank and the dependencies between the various configuration inputs (Kconfig/DT/CMake for each image + partition manager) are very interlinked so I'm looking to see if there is a baseline sample for this sort of application available (NET core updated independently of APP core) and/or what kconfig needs to look like to support this

    See the SMP Server Sample. 

    Can I update the APP to something that would potentially send commands the NET core doesn't know about and then schedule a NET upgrade to match? NET core updates should only ever be feature additions so this isn't *necessary* but is nice to have

    Unfortunately, this feature is not supported. 

    Is there a way to "version" the hci_rpmsg (default nRF53 BT NET image) image and query that? I can add tracking externally if not

    use mcumgr -c acm1 image list

    Do I need to be wary of updating the SDK version in future (NET core updates in general not just independent updates)

    Depends on the features or bug fixing you require. 

    If the net core does become unresponsive, is it only the NET application that is corrupt (i.e. is the b0n image write protected and can mcuboot be used to write over (effectively) a blank NET application or is outside input required to recover a NET core?

    yes.

    Can I use the mcuboot downgrade prevention to create versions that can't work with an old net firmware (e.g. <NET VERSION>+<APP_VERSION> for CONFIG_MCUBOOT_IMAGE_VERSION). The docs indicate that the value after the `+` doesn't matter but also mention it as a number elsewhere. Would 2+3.4 still work to prevent it reverting to 1+... but allow any 2+... version (and if so is this guaranteed behaviour or an artifact of the current implementation )

    You can read about downgrade prevention under Preventing downgrades using MCUboot. You configure the application image version using CONFIG_MCUBOOT_IMAGE_VERSION.

    TLDR: That got a bit rambly but I'm looking for information about how to setup/support non-simultaneous FOTA updates for a nRF53

    mcuboot_smp_ble and mcuboot_smp_uart are very good examples to demonstrate that. 

    Regards,
    Amanda H.

Reply
  • +1

    Hi,

    The unofficial samples repo "non-simultaneous" nrf5340 is a blank and the dependencies between the various configuration inputs (Kconfig/DT/CMake for each image + partition manager) are very interlinked so I'm looking to see if there is a baseline sample for this sort of application available (NET core updated independently of APP core) and/or what kconfig needs to look like to support this

    See the SMP Server Sample. 

    Can I update the APP to something that would potentially send commands the NET core doesn't know about and then schedule a NET upgrade to match? NET core updates should only ever be feature additions so this isn't *necessary* but is nice to have

    Unfortunately, this feature is not supported. 

    Is there a way to "version" the hci_rpmsg (default nRF53 BT NET image) image and query that? I can add tracking externally if not

    use mcumgr -c acm1 image list

    Do I need to be wary of updating the SDK version in future (NET core updates in general not just independent updates)

    Depends on the features or bug fixing you require. 

    If the net core does become unresponsive, is it only the NET application that is corrupt (i.e. is the b0n image write protected and can mcuboot be used to write over (effectively) a blank NET application or is outside input required to recover a NET core?

    yes.

    Can I use the mcuboot downgrade prevention to create versions that can't work with an old net firmware (e.g. <NET VERSION>+<APP_VERSION> for CONFIG_MCUBOOT_IMAGE_VERSION). The docs indicate that the value after the `+` doesn't matter but also mention it as a number elsewhere. Would 2+3.4 still work to prevent it reverting to 1+... but allow any 2+... version (and if so is this guaranteed behaviour or an artifact of the current implementation )

    You can read about downgrade prevention under Preventing downgrades using MCUboot. You configure the application image version using CONFIG_MCUBOOT_IMAGE_VERSION.

    TLDR: That got a bit rambly but I'm looking for information about how to setup/support non-simultaneous FOTA updates for a nRF53

    mcuboot_smp_ble and mcuboot_smp_uart are very good examples to demonstrate that. 

    Regards,
    Amanda H.

Children
No Data
Related
Terms of service