• State Not Answered
  • Replies 6 replies
  • Subscribers 90 subscribers
  • Views 2543 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 264968
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF Connect app stuck on "VALIDATING" when performing DFU

Jon

Based on documentation included in http://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_nrf52.html#fota-upgrades I am attempting to get DFU working on the following setup:

-nRF52840

-nrfConnect/Zephyr

-MCUBoot

I am loading the 'app_update.bin' file onto my mobile phone. I am able to see the device and the SMP service. I click the 'DFU' icon and select the 'app_update.bin' file and then the DFU screen appears (with the transfer speed graph) and "Validating" shows below the graph. Nothing happens after this point.

I tried the NRF Toolbox's DFU button. I click the 'Select file' button and choose 'Application' and select the same 'app_update.bin' file. The app then asks for an init packet file and I click the 'NO' option. When starting the upload it gives the error "DFU Init packet required'.

I am confused about the need for an init packet. The documentation mentioned at the start of this ticket indicates that the 'app_update.bin' file can be used directly. Also, the definition of the init file indicates fields like softdevice version, etc, which are not applicable in my configuration (MCU Boot is the bootloader and I am using the MCUMgr for FOTA while the application is running).

Can you please help here?

Thanks,

Jon

Parents
  • 0

    An update: I disabled CONFIG_MCUMGR_SMP_BT_AUTHEN, and now Nrf Connect app gets a little bit further: Instead of getting hung on the 'Validating' message. it quickly flashes "Starting DFU" and then exits back to the characteristics screen.

    Thanks,

    Jon

  • 0 in reply to Jon

    Another update: I traced the DFU process to the point where the first upload message is sent to the device from the NRF Connect app. The CBOR message includes the MCUBoot header. The message includes the CBOR payload as follows:

    {"data": h'3DB8F3960000000000020000344B0800000000000000', "len": 544203, "sha": h'034862', "off": 0}

    As you can see, the MCUBoot magic is correct (0x96f3b83d). However, this data is rejected in the function img_mgmt_impl_upload_inspect() in 'modules/lib/mcumgr/cmd/img_mgmt/port/zephyr/src/zephyr_img_mgmt.c' of the NRFConnect SDK because the header sent by the app only contains 22 bytes of data, whereas the MCUBoot header is defined as 32 bytes in length. The line which checks this is:

        if (req->off == 0) {
        /* First upload chunk. */
        if (req->data_len < sizeof(struct image_header)) {
            /*
             * Image header is the first thing in the image.
             */
            *errstr = img_mgmt_err_str_hdr_malformed;
            return MGMT_ERR_EINVAL;
        }

Reply
  • 0 in reply to Jon

    Another update: I traced the DFU process to the point where the first upload message is sent to the device from the NRF Connect app. The CBOR message includes the MCUBoot header. The message includes the CBOR payload as follows:

    {"data": h'3DB8F3960000000000020000344B0800000000000000', "len": 544203, "sha": h'034862', "off": 0}

    As you can see, the MCUBoot magic is correct (0x96f3b83d). However, this data is rejected in the function img_mgmt_impl_upload_inspect() in 'modules/lib/mcumgr/cmd/img_mgmt/port/zephyr/src/zephyr_img_mgmt.c' of the NRFConnect SDK because the header sent by the app only contains 22 bytes of data, whereas the MCUBoot header is defined as 32 bytes in length. The line which checks this is:

        if (req->off == 0) {
        /* First upload chunk. */
        if (req->data_len < sizeof(struct image_header)) {
            /*
             * Image header is the first thing in the image.
             */
            *errstr = img_mgmt_err_str_hdr_malformed;
            return MGMT_ERR_EINVAL;
        }

Children
Related