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,

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)