DFU BLE bootloader doesn't seem to work

[Jerry Easley]

I am trying to implement the smp_svr example as described here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/README.html.

I have successfully built and flashed the MCU bootloader. (to a nRF52840dk)

I have successfully built, the mcumgr.

I have successfully built, signed, and flashed the smp_svr.

At this point I looked at my nRF_CONNECT_FOR_MOBILE scanner but I do not see the device.

I modified the smp_svr bluetooth.c as follows:

/*

static const struct bt_data ad[] = {

BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),

BT_DATA_BYTES(BT_DATA_UUID128_ALL,

0x84, 0xaa, 0x60, 0x74, 0x52, 0x8a, 0x8b, 0x86,

0xd3, 0x4c, 0xb7, 0x1d, 0x1d, 0xdc, 0x53, 0x8d),

};

*/

static const struct bt_data ad[] = {

BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),

BT_DATA_BYTES(BT_DATA_UUID128_ALL,

0x84, 0xaa, 0x60, 0x74, 0x52, 0x8a, 0x8b, 0x86,

0xd3, 0x4c, 0xb7, 0x1d, 0x1d, 0xdc, 0x53, 0x8d),

BT_DATA(BT_DATA_NAME_COMPLETE, "Zephyr_DFU", 8),

};

This I did because I was unsure what the default advertising name was.

I then rebuilt, resigned, and re-flashed.

I still did not see the the device on my scanner.

When I attempt to flash with mcumgr It doesn't connect.

sudo ~/go/bin/mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' echo hello
hello
Error: Failed to connect to peer after 10s

and

sudo ~/go/bin/mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='ZephyrDFU' echo hello
Error: Failed to connect to peer after 10s

This suggests to me the smp_svr program isn't working correctly.

I'm not sure where to go with this, any suggestions?

Regards,

Jerry

[Hung Bui]

Hi Jerry, 

Could you please let me know which NCS SDK version you are using ? The implementation of smp_svr has been changed lately especially in NCS v2.3.0 and NCS v2.4.0

When you build smp_svr, did you use the overlay-bt.conf in addition to the prj.conf ? 

Please be aware that when you build smp_svr it will automatically build MCUBoot as the child image so you don't have to flash anything else in addition. 

My suggestion is to use a phone to check if the device advertise or not after you flash. You then can use nRF Connect app on the phone to do an DFU update. 
After you can verify that it works with a phone, then you can continue the test with mcumgr on PC. 

[Jerry Easley]

Hi Hung,

My SDK is 2.4.1; toolchain is 2.4.0.

This is the command I used to build thee smp_svr.

(.venv) jerry@Ubuntu:~/zephyrproject$ west build \
            -b nrf52840dk_nrf52840 \
            zephyr/samples/subsys/mgmt/mcumgr/smp_svr \
            -- \
            -DEXTRA_CONF_FILE=overlay-bt.conf

:It sounds like you are assuming I'm building smp_svr under VSCODE; I am following the instructions, which use west command line tools to build mcuboot, and smp_svr in discrete steps.  I don't understand how to do this under VSCODE; the documentation is enigmatic and confusing.  In addition, including the necessary prj.conf statements for mcuboot causes build errors.  If you know how to do it under VSCODE I would prefer to do it that way.

I did use my iPad to check for the advertisement; The scanner did not display the device.

Regards,

Jerry

[Jerry Easley]

Hi Hung,

Just a side note:

I tried to build smp_svr with a board, nreff52840dongle_nrf52840, I get a build error:

[74/140] Building C object modules/nrf/subsys/bluetooth/controller/CMakeFiles/..__nrf__subsys__bluetooth__controller.dir/hci_driver.c.obj
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /home/jerry/ncs/toolchains/1f9b40e71a/usr/local/bin/cmake --build /home/jerry/MyApps/smp_svr/build_dongle

There seems to be some kind of issue with dongles and bootloaders: do you know anything about it? 

Regards,

Jerry

[Hung Bui]

Hi Jerry, 

Please try to do FOTA update with your tablet before you try with the mcumgr. You can use nRF Connect or nRF Device Manager to do update. 

For a FOTA process to complete you would need to either test or confirm the new image (confirm is done automatically in the app on the tablet)

Please take a look at the documentation here: https://docs.zephyrproject.org/latest/services/device_mgmt/mcumgr.html

For test (only run new image once then revert back to original application) you need to do: 

mcumgr <connection-options> image test <hash> 

+ a reset

For confirm (permanently switch the imag) you need to call: 

mcumgr <connection-options> image confirm <hash> 

+ a reset. 

 

[Jerry Easley]

What is the <hash> item and how do I obtain it?

Jerry

[Hung Bui]

Hi Jerry, 
Please read the documentation.
 https://docs.zephyrproject.org/latest/services/device_mgmt/mcumgr.html
You will see the hash when you call 

mcumgr <connection-options> image list

[Jerry Easley]

Hi Hung,

You will have to forgive me; I have read the documentation a 1000 times; I don't understand it; it if full of buzz words which are not defined and I can't figure out what it is talking about.

This is what I see:

Images:
 image=0 slot=0
    version: 0.0.0
    bootable: true
    flags: active confirmed
    hash: ea9c889031e33c8c9c500e00e8ed94454f536368c499c186688f323a48f973b4
 image=0 slot=1
    version: 0.0.0
    bootable: true
    flags: pending
    hash: 582ef2530f15968c39513443f312418a0179dac2050b1146bd727467df042564
Split status: N/A (0)

As you can see I have two images. I presume one is my smp_svr application and one is my binky application; I don't know which is which.

I don't know how this works; I have uploaded my blinky image, apparently, successfully.  From your comments above I need to do two additional steps in order to get my blinky application running.  In order to do that I need to specify the <hash>, of which I have two; which should I use?

Let us suppose that I have my blinky application up and running and I want to update it; how do I do that if the smp_svr is no longer active?

Regards,

Jerry

[Hung Bui]

Hi Jerry,

When in doubt , just try both ;) 

Just kidding, you should use the one at slot 1 : 582ef2530f15968c39513443f312418a0179dac2050b1146bd727467df042564

The original image will always at slot 0. It's the image that will run at boot (after MCUBoot). When you do test, image at slot 1 will be temporarily copied to slot 0 and revert back after rest.

When you do confirm the image at slot 1 will overwrite the one at slot 0 and run at next boot.

[Jerry Easley]

Hi Hung,

Ok this is what I did:

(.venv) jerry@Ubuntu:~/zephyrproject$ sudo ~/go/bin/mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' image upload ~/MyApps/blinky/build_dk/zephyr/app_update.bin
 23.03 KiB / 23.03 KiB [====================================================================================================================] 100.00% 10.43 KiB/s 2s
Done
(.venv) jerry@Ubuntu:~/zephyrproject$ sudo ~/go/bin/mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' image list
Images:
 image=0 slot=0
    version: 0.0.0
    bootable: true
    flags: active confirmed
    hash: ea9c889031e33c8c9c500e00e8ed94454f536368c499c186688f323a48f973b4
 image=0 slot=1
    version: 0.0.0
    bootable: true
    flags:
    hash: 582ef2530f15968c39513443f312418a0179dac2050b1146bd727467df042564
Split status: N/A (0)
(.venv) jerry@Ubuntu:~/zephyrproject$ sudo ~/go/bin/mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' image test 582ef2530f15968c39513443f312418a0179dac2050b1146bd727467df042564  + a reset
Images:
 image=0 slot=0
    version: 0.0.0
    bootable: true
    flags: active confirmed
    hash: ea9c889031e33c8c9c500e00e8ed94454f536368c499c186688f323a48f973b4
 image=0 slot=1
    version: 0.0.0
    bootable: true
    flags: pending
    hash: 582ef2530f15968c39513443f312418a0179dac2050b1146bd727467df042564
Split status: N/A (0)
(.venv) jerry@Ubuntu:~/zephyrproject$ sudo ~/go/bin/mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' image confirm 582ef2530f15968c39513443f312418a0179dac2050b1146bd727467df042564  + a reset
Images:
 image=0 slot=0
    version: 0.0.0
    bootable: true
    flags: active confirmed
    hash: ea9c889031e33c8c9c500e00e8ed94454f536368c499c186688f323a48f973b4
 image=0 slot=1
    version: 0.0.0
    bootable: true
    flags: pending
    hash: 582ef2530f15968c39513443f312418a0179dac2050b1146bd727467df042564
Split status: N/A (0)

My blinky application does not run.

I have reset the device with vscode: it doesn't run.

I have reset the device with the reset button: it does not run.

I have removed power and applied power: it does not run.

I am sure I have switched images because my smp_svr is no longer manifest.

Maybe I have not properly prepared my blinky application?

Regards,

Jerry

[Hung Bui]

Hi again, 

Have you built the blinky with MCUBoot added ? The image should be configured so that it can run on slot 0

My suggestion is to do an update with the same smp_svr image, just change something like advertising name, or blink another LED but still the same smp_svr application. 

[Jerry Easley]

Hi Hung,

I apologize, it is working: I must have had too much coffee and not enough sleep.

I have just one other question if I may abuse you further:

My understanding of how this works is as follows:

Any application that I want to update from time to time over BLE will necessarily have to include the equivalent of the smp_svr code; is that correct?

Regards,

Jerry

[Hung Bui]

Hi Jerry, 
Yes SMP_SVR is integrated into your application automatically when you enable those configuration you find in the smp_svr (both prj.conf and the overlay_bt.conf)