• State Verified Answer
  • Replies 15 replies
  • Subscribers 25 subscribers
  • Views 387 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 265145
Options

FOTA with Nordic Connect SDK (ncs) not working

Mike Hibbett
1 month ago

I'm blocked trying to get an Nrf52 application developed under v1.3.0 SDK work with FOTA.

My application is working fine. FYI, its on custom hardware derived from nrf52832_mdk board definition, and the lbs sample.

Now to add FOTA capability. No buttons or display, so buttonless.

I followed the instructions from here, 

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_nrf52.html?highlight=fota#fota-upgrades

and I end up with an application that has the DFU characteristic advertised, and nrf connect for mobile and connects to, for DFU. I rebuild an application and try to upload it via NRF Connect, and after a short time of "validating app" on the screen, it reverts back with no error message.

Goggling suggests there is some bug with page alignment fixed mid last year. So I try to copy my application to SDK v1.4.2, and I get a raft of build errors, which cannot be navigated to easily in the IDE. Even the previously supported types like u8_t are no longer valid!

Does anyone have any suggestions? I've used buttonless FOTA on a product on the previous NRF5 SDK with no issues, I'd rather not abandon this mess and go back.

Parents
  • 0 1 month ago

    I have resolved the build issues (header files moved in the SDK); the behaviour is the same. FYI, the changes I made are as follows:

    Added to prj.conf:

    # Added for FOTA
    CONFIG_BOOTLOADER_MCUBOOT=y
    CONFIG_MCUMGR=y
    CONFIG_MCUMGR_CMD_OS_MGMT=y
    CONFIG_MCUMGR_CMD_IMG_MGMT=y
    CONFIG_MCUMGR_SMP_BT=y
    CONFIG_IMG_ERASE_PROGRESSIVELY=y

    Added to main.c

    // For FOTA
    #include <tinycbor/cbor.h>
    #include "cborattr/cborattr.h"
    #include <mgmt/mgmt.h>
    #include <mgmt/mcumgr/smp_bt.h>
    #include <mgmt/mcumgr/buf.h>
    #include <mgmt/mcumgr/smp.h>
    #include "os_mgmt/os_mgmt.h"
    #include "os_mgmt/os_mgmt_impl.h"
    #include "os_mgmt/os_mgmt_config.h"
    #include "img_mgmt/image.h"
    #include "img_mgmt/img_mgmt.h"
    #include "img_mgmt/img_mgmt_impl.h"
    #include "img_mgmt/img_mgmt_config.h"

    and in main()

      printk("Application build time: %s %s \n", __DATE__, __TIME__);

    ...

      printk("Advertising successfully started\n");

      // For FOTA
      os_mgmt_register_group();
      img_mgmt_register_group();
      smp_bt_register();

    I reloaded the project, built and flashed. The image booted ok

    *** Booting Zephyr OS build v2.4.0-ncs2 ***
    [00:00:00.403,625] <inf> mcuboot: Starting bootloader
    [00:00:00.409,667] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, cop y_done=0x3, image_ok=0x3
    [00:00:00.419,677] <inf> mcuboot: Boot source: none
    [00:00:00.425,140] <inf> mcuboot: Swap type: none
    [00:00:00.716,369] <inf> mcuboot: Bootloader chainload address offset: 0xc000
    [00:00:00.724,029] <inf> mcuboot: Jumping to the first image slot
    *** Booting Zephyr OS build v2.4.0-ncs2 ***
    Starting Bluetooth Peripheral LBS example
    Application build time: Feb 23 2021 09:53:14
    I: 2 Sectors of 4096 bytes
    I: alloc wra: 0, ff0
    I: data wra: 0, 0
    I: SoftDevice Controller build revision:
    I: cf 5c 0f 11 88 9c d7 02 |.\......
    I: 15 27 c7 c3 ca 60 19 85 |.'...`..
    I: b7 c4 50 e3 |..P.
    I: No ID address. App must call settings_load()
    Bluetooth initialized
    Advertising successfully started

    I rebuilt the code, to generate a different binary image (TIME being different) and attempted to DFU this using nrf connect mobile. "Validating" was displayed for a few seconds, then the Android app reverted without attempting the actual DFU.

    The target debug output showed

    Connected
    Disconnected (reason 19)
    Connected
    W: Unhandled ATT code 0x1d
    Passkey for 4d:a0:4e:95:16:f2 (random): 128349
    Security changed: 4d:a0:4e:95:16:f2 (random) level 4
    Pairing completed: a8:87:b3:74:2d:56 (public), bonded: 1

    I assume I am missing something. Please advise, this product development is now blocked.

  • 0 1 month ago in reply to Mike Hibbett

    By adding the following lines, which I found someone using through a random google search

    CONFIG_BT_RX_BUF_LEN=258
    CONFIG_BT_L2CAP_RX_MTU=247
    CONFIG_BT_L2CAP_TX_MTU=247
    CONFIG_BT_CTLR_TX_BUFFER_SIZE=251
    CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
    CONFIG_MCUMGR_SMP_BT_AUTHEN=n

    FOTA now proceeds as expected, although slowly, 1.3KB/s. At the end, the application booted.

    A second rebuild of the app failed to download, and the device now no longer gets past the bootloader.

    *** Booting Zephyr OS build v2.4.0-ncs2 ***
    [00:00:00.274,566] <inf> mcuboot: Starting bootloader
    [00:00:00.280,578] <inf> mcuboot: Primary image: magic=good, swap_type=0x4, copy_done=0x1, image_ok=0x1
    [00:00:00.290,435] <inf> mcuboot: Boot source: none
    [00:00:00.295,867] <inf> mcuboot: Swap type: test
    [00:00:11.931,640] <inf> mcuboot: Bootloader chainload address offset: 0xc000
    [00:00:11.939,270] <inf> mcuboot: Jumping to the first image slot

    So please point us to the correct technique for enabling FOTA.

    Thanks,

    Mike

  • 0 1 month ago in reply to Mike Hibbett

    Hi Mike,

    I do not see that you lack any configurations. You can compare with the smp_svr sample, but this looks good.

    What happens after getting "mcuboot: Jumping to the first image slot" in the bootloader log? What state is the nRF in? Do you get more usefull debug information if building with CONFIG_DEBUG_OPTIMIZATIONS=y?

    Einar

Reply Children
Related