• State Not Answered
  • Replies 5 replies
  • Subscribers 70 subscribers
  • Views 149 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 338869
Options

Run time control of MCU Manager

bbbakke

We are looking to do DFU over UART to the Application as described in DevAcademy nRF Connect SDK Intermediate, Lesson 8, Exercise 1, Step 5. However, we have only one UART available external to our product and it is used for other communications in normal operation (i.e., when not doing SW updates).

So, our use case is not to start MCU Manager at power up and keep it disabled so the UART can be used by another thread for normal communications. Then, when the app decides it wants to go into DFU over UART mode it will terminate the normal communications, cease using the UART, and then invoke the MCU Manager to begin its communications over the UART for the purpose of uploading a new SW image to slot 1.

Is this possible? Can you provide some insight as to how we can prevent the MCU Manager from staring at power up, and how the app can start it later when it is needed?

Parents
  • 0

    Hi,

    What you describe is possible. You can see the two processes as two individual procedures; one where you're booting up and entering your application, and one where you're in serial recovery mode. In each of these two modes, you can use the same UART in those two separated modes. 

    Kind regards,
    Andreas

  • 0 in reply to AHaug
    Hello Andreas,
     
    This doesn't really address our use case. The way you described it, one boot up entering the app and one boot up in MCUBoot serial recovery mode, is how DevAcademy nRF Connect SDK Intermediate, Lesson 8, Exercise 1, Step 3/4 works, with a single application slot.
     
    In our use case we want to operate as described in Step 5 with two application slot and MCUMGR (not MCUBOOT) using a UART to load the new image into the second slot (slot 1). And then at next start up, if the second image is tagged for test, MCUBoot will swap slot 1 and slot 0, then run the new image.
     
    Again, this is exactly how Lesson 8, Exercise 1, Step 5 works. And we have this working.
     
    The difference for our use case is, we want to use the UART for other purposes most the time and have control when MCUMGR takes over and uses the UART. So, my question remain; can you provide some insight as to how we can prevent the MCUMGR from starting when the App runs, and how the App can start it later when it is needed?
     
    Thanks for your help,
    Brad
Reply
  • 0 in reply to AHaug
    Hello Andreas,
     
    This doesn't really address our use case. The way you described it, one boot up entering the app and one boot up in MCUBoot serial recovery mode, is how DevAcademy nRF Connect SDK Intermediate, Lesson 8, Exercise 1, Step 3/4 works, with a single application slot.
     
    In our use case we want to operate as described in Step 5 with two application slot and MCUMGR (not MCUBOOT) using a UART to load the new image into the second slot (slot 1). And then at next start up, if the second image is tagged for test, MCUBoot will swap slot 1 and slot 0, then run the new image.
     
    Again, this is exactly how Lesson 8, Exercise 1, Step 5 works. And we have this working.
     
    The difference for our use case is, we want to use the UART for other purposes most the time and have control when MCUMGR takes over and uses the UART. So, my question remain; can you provide some insight as to how we can prevent the MCUMGR from starting when the App runs, and how the App can start it later when it is needed?
     
    Thanks for your help,
    Brad
Children
  • 0 in reply to bbbakke
    bbbakke said:
    In our use case we want to operate as described in Step 5 with two application slot and MCUMGR (not MCUBOOT) using a UART to load the new image into the second slot (slot 1). And then at next start up, if the second image is tagged for test, MCUBoot will swap slot 1 and slot 0, then run the new image.

    Ah, I see. Thank you for elaborating. In other words the approach will be to change the UART without entering serial recovery i.e while performing DFU over UART from the application itself, which section 5 in the exercise describes. Could you also verify one more thing: Do you intend to have two versions of the firmware that you swap between, or do you intend to remove the contents of slot 1 after it's been moved to slot 0 and verified as the new image?

    I will spend some more time looking into this tomorrow, hopefully with a resolution.

    Kind regards,
    Andreas

  • 0 in reply to AHaug
    AHaug said:
    Do you intend to have two versions of the firmware that you swap between, or do you intend to remove the contents of slot 1 after it's been moved to slot 0 and verified as the new image?

    It will be the later case. We would tag slot 1 as test, then MCUBoot would swap the two images before running the new app image, the new app will go through its checks and, if all is good, tag it as confirmed.

    Thanks for looking into it. Looking forward to hear what you fine.

    -Brad

  • 0 in reply to bbbakke

    Noted, thank you for verifying.

    After discussing this topic with my colleagues I got a suggestion that this might be what you want: In https://docs.zephyrproject.org/latest/services/device_mgmt/smp_transport.html#uart-serial-and-console under UART/serial and console, UART multiplexing is recommended to separate use of an UART between an application and the mcumgr smp transport. Other than this, I believe you might have to set up two UARTs for their own independent use.

    Now as to your other/original concern: Is there a way to not enable MCUmgr before you need it, i.e during run time: From what I've seen in the sample code there's no part of the application where you disable it, but I believe you can choose when to initialize the groups as shown in the smp server sample https://github.com/nrfconnect/sdk-zephyr/blob/main/samples/subsys/mgmt/mcumgr/smp_svr/src/main.c 

    Kind regards,
    Andreas

Related
Terms of service