This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

FOTA with Nordic Connect SDK (ncs) not working

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
  • So a small amount of progress. Let me refresh where I am.

    SDK v1.4.2. peripheral LBS application. Modified to operate with mcuboot & fota, by the following changes

    main() function has these calls added:

       printk("Advertising successfully started\n");
       // For FOTA
       os_mgmt_register_group();
       img_mgmt_register_group();
       smp_bt_register();

    prj.conf is like this:

    CONFIG_NCS_SAMPLES_DEFAULTS=n
    CONFIG_BT=y
    CONFIG_BT_PERIPHERAL=y
    CONFIG_BT_DEVICE_NAME="Nordic_Blinky"
    CONFIG_BT_LBS=y
    CONFIG_BT_LBS_POLL_BUTTON=y
    CONFIG_DK_LIBRARY=y
    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
    CONFIG_BT_L2CAP_TX_MTU=252
    CONFIG_BT_L2CAP_RX_MTU=252
    CONFIG_BT_RX_BUF_LEN=260
    CONFIG_BT_CTLR_TX_BUFFER_SIZE=251
    CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
    CONFIG_MCUMGR_SMP_BT_AUTHEN=n
    CONFIG_DEBUG_OPTIMIZATIONS=y
    CONFIG_MCUMGR_SMP_SHELL=y
    CONFIG_FILE_SYSTEM=y
    CONFIG_FILE_SYSTEM_LITTLEFS=n
    CONFIG_MCUMGR_CMD_FS_MGMT=y
    CONFIG_STATS_NAMES=n
    CONFIG_LOG=n
    CONFIG_FLASH=y
    CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

    board dts file has this flash setup:

    partitions {
    compatible = "fixed-partitions";
    #address-cells = <1>;
    #size-cells = <1>;

    boot_partition: partition@0 {
    label = "mcuboot";
    reg = <0x00000000 0xc000>;
    };
    slot0_partition: partition@c000 {
    label = "image-0";
    reg = <0x0000C000 0x34000>;
    };
    slot1_partition: partition@3e000 {
    label = "image-1";
    reg = <0x00040000 0x34000>;
    };
    /* scratch_partition: partition@70000 {
    label = "image-scratch";
    reg = <0x00074000 0xa000>;
    };
    */ storage_partition: partition@7a000 {
    label = "storage";
    reg = <0x0007a000 0x00006000>;
    };

    Note the change I made to the slots, to allow the application to fit.

    Built the code, it's this size:

    Programming 37.2 KB of addresses 00000000 — 000094eb
    Programming 207.4 KB of addresses 0000c000 — 0003fd9b

    so will fit in the slots.

    Erased the chip and downloaded the image. serial debug on mcu shows this:

    *** Booting Zephyr OS build v2.4.0-ncs2 ***
    [00:00:00.400,878] <inf> mcuboot: Starting bootloader
    [00:00:00.406,921] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
    [00:00:00.416,870] <inf> mcuboot: Boot source: none
    [00:00:00.422,302] <inf> mcuboot: Swap type: none
    [00:00:00.724,212] <inf> mcuboot: Bootloader chainload address offset: 0xc000
    [00:00:00.731,811] <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 21:16:22
    Bluetooth initialized
    Advertising successfully started

    Rebuilt the code to generate a different binary (I have time & date coded in a printf)

    Started a download via nrf connect for mobile using CONFIRM ONLY. Download proceeds, at a slow rate, 1.5kB/s

    At the end, nrf connect for mobile says "validating", and the mcu reboots, showing this:

    *** Booting Zephyr OS build v2.4.0-ncs2 ***
    [00:00:00.274,505] <inf> mcuboot: Starting bootloader
    [00:00:00.280,517] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
    [00:00:00.290,466] <inf> mcuboot: Boot source: none
    [00:00:00.295,898] <inf> mcuboot: Swap type: perm

    ... a few seconds pass, then this is printed ...


    [00:00:12.354,919] <inf> mcuboot: Bootloader chainload address offset: 0xc000
    [00:00:12.362,518] <inf> mcuboot: Jumping to the first image slot

    The android app disconnects with no messages.

    nrf logger dump of these final stages of dfu are shown below.

    So the image upload bricks the device; rebooting the device leaves the boot sequence as this:

    *** Booting Zephyr OS build v2.4.0-ncs2 ***
    [00:00:00.274,475] <inf> mcuboot: Starting bootloader
    [00:00:00.280,487] <inf> mcuboot: Primary image: magic=good, swap_type=0x3, copy_done=0x1, image_ok=0x1
    [00:00:00.290,344] <inf> mcuboot: Boot source: none
    [00:00:00.295,776] <inf> mcuboot: Swap type: none
    [00:00:00.566,192] <inf> mcuboot: Bootloader chainload address offset: 0xc000
    [00:00:00.573,822] <inf> mcuboot: Jumping to the first image slot

    Completely stuck at this point and out of ideas. 

    I hope these details reveal what is going wrong.

    Regards,

    Mike.

  • Hi Mike,

    I am not able to explain this at this point. I need to look more into it before I can say something meaningful, but I hope to get back to you tomorrow.

    Einar

Reply Children
No Data
Related