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

Getting error "DFU characteristic not found"

Dear

I am try to perform an  OTA  operation on a dongle of nrf52840 by ble_app_blinky for PCA10059 project   and  light-switch server for PCA10059 project, which works well on the PCA10059.

For the OTA operation, I have a Android smart phone with nRF toolbox , a PCA10056 DK which can be connect to a dongle by swd interface. I use nRF5 SDK_16.0.0 and SDK for MASH 4.0.0.

In these case, the Softdevice will be " s140_nrf52_7.0.1_softdevice"

Step1 : I make a pair keys for this operation by nrfutil command and build  "secure_bootloader_ble_s140_pca10056_debug.emProject" project with the new public_key.

Step2 :  I download the dfu_bootloader which be built last step to  dongle which be clean by "nrfjprog -e"

Step3 :  Make a dfu.zip for ble_app_blinky project by nrfutil command which is

nrfutil pkg generate --hw-version 52 --debug-mode --sd-req 0x00 --sd-id 0xCA --application ble_app_blinky_pca10059_s140.hex --key-file private.key --softdevice s140_nrf52_7.0.1_softdevice.hex ble_app_blinky_pca10059_s140_sd_DBdfu_package.zip

Make a dfu.zip for light-switch server for PCA10059 project by nrfutil command which is

nrfutil pkg generate --hw-version 52 --debug-mode --sd-req 0x00 --sd-id 0xCA --application light_switch_server_nrf52840_xxAA_s140_7.0.1.hex --key-file private.key --softdevice s140_nrf52_7.0.1_softdevice.hex light_switch_server_nrf52840_xxAA_s140_V701_sd_DBdfu_package.zip

Step4 :  Upload those packages to different Dongle separately by DFU of nRF Toolbox on Android smart phone. All of them be successful.

Step5 :  Modify the  ble_app_blinky for PCA10059 project   and  light-switch server for PCA10059 project by exchange LED pins with each other. Repeat step3 to step4. All of them be failure with a error "DFU characteristic not found"

Q1: Is there anything wrong with the process described above?Why does the first update succeed, but then fail (only once?)?

Q2: When  I doing DFU on DFU tools of nrf toolbox on my phone, if I select  "Application" as file type, I have to select an other file as init package. which mean is if I want download an app.hex to chips, an init package will be supported. Because the SES can build a project to generate a hex file and can download the hex file to chip.  For this reason, can I assume that SES also generated the corresponding init package during the build? If the answer is yes, where is the init package?

Q3: About the bootloader setting page, If a donwload a app.hex go through bootloader, a  bootloader setting page will be generated by bootloader. is it correct? 

When I read the post here, I donot uderstand  those words below.

"But in production for example, you may not want to install the application by doing OTA DFU for thousands of device which takes lots of time. The same when you are doing development. You don't want to do DFU for any change you made to your application.

To solve this, we can generate a bootloader setting manually and merge it with the bootloader to trick the bootloader to accept the pre-flashed application. We use nrfutil to generate the bootloader setting and can use mergehex.exe tool to merge the hex files. If you don't want to merge you can flash the setting first then flash the bootloader."

Would you explain the function to me. Some examples will be better for me.

Q5: I want doing  a OTA by a dongle and a PCA10056. which tools can be used on my disktop like the DFU of nrf toolbox on smart phone?  How I can connect the PCA10056 with the desktop(J2 or J3 or others connector)?  Do i need download the dfu project to the PCA10056? Do you have a manual with detail? 

Thanks,

Di-Sheng

  • Hi Edvin, I dont mean to distract your efforts to help Di-sheng, but I was worried that you didnt see my most recent comment (with all the details) up above. Basically, I got the buttonless DFU default application working as expected. However, when I add the NUS Service to the Buttonless DFU project (as shown in all my edits below, alongside enabling BLE_NUS in the sdk_config.h), the application faults after the DFU and wont actually run when uploaded to the device.

    static ble_uuid_t m_adv_uuids[]         = 
    {
        {BLE_UUID_DEVICE_INFORMATION_SERVICE, BLE_UUID_TYPE_BLE},
        {BLE_UUID_NUS_SERVICE, NUS_SERVICE_UUID_TYPE}
    };
    
    
    static void nus_data_handler(ble_nus_evt_t * p_evt)
    {
        //Basic default implementation from the ble_app_uart project
    }
    
    
    static void services_init(void)
    {
        // NOTE: These lines of code have been ADDED to the default implementation!
        ble_nus_init_t     nus_init;
    
        // Initialize NUS.
        memset(&nus_init, 0, sizeof(nus_init));
    
        nus_init.data_handler = nus_data_handler;
    
        err_code = ble_nus_init(&m_nus, &nus_init);
        APP_ERROR_CHECK(err_code);
    }


    I have also tried to "Attach Debugger" when my device is in DFU state so that I can see what happens when it fails to start my merged buttonless DFU + UART application after a successful OTA DFU. When I watch this debugger, nothing happens except the debugger quits and the Segger Embedded Studio displays the app_timer2.c file, specifically leaving the cursor at the "static uint64_t get_now(void)" function. Not sure if that helps, but I would love any tips or recommendations you have to help me merge the Buttonless DFU project with the BLE UART project. Thank you for the help :)

  • Hi Edvin

    Thanks for your reply!

    I have past the buttonless dfu testing for Mesh's light-switch server example on PCA10056 and PCA10059 board.

    The buttonless dfu can be performed by Desktop's nRFconnect-->Bluetooth Low Energy tools, cell phone's nRFConnect and toolsbox-->DFU, except the nRFUtil command.

    For Mesh's light-Switch Server project, the nRFUtil command does not start the DFU process for either the PCA100056 or the PCA0059 board, but it works for the BLE_app_blinky project nRFUtil command for both board.

    Below is what happens when I run the command twice:(I am sure that the COM6 and "nRF5x 92Mesh Light" below are correct)

    C:> nrfutil dfu ble -ic NRF52 -pkg LSS59BLDFU1_s140.zip -p COM6 -n "nRF5x 92Mesh Light" -f

     Flashing connectivity firmware...
     Connectivity firmware flashed.

    C:> nrfutil dfu ble -ic NRF52 -pkg LSS59BLDFU1_s140.zip -p COM6 -n "nRF5x 92Mesh Light" -f

      Board already flashed with connectivity firmware.

    Would you help me to find what happen here?

    Thanks,

    Best Regard,

    Di-Sheng

  • cor10 said:
    Hi Edvin, I dont mean to distract your efforts to help Di-sheng, but I was worried that you didnt see my most recent comment (with all the details) up above.

     No worries. I am glad you did.

    Do you see anything in the fault handler? Do you see anything in the log? Try to define DEBUG in your preprocessor definitions in your application, and monitor the log. Do you see any log messages? (Before or after the error?)


     

    Di-sheng said:

    Below is what happens when I run the command twice:(I am sure that the COM6 and "nRF5x 92Mesh Light" below are correct)

    C:> nrfutil dfu ble -ic NRF52 -pkg LSS59BLDFU1_s140.zip -p COM6 -n "nRF5x 92Mesh Light" -f

     Flashing connectivity firmware...
     Connectivity firmware flashed.

    C:> nrfutil dfu ble -ic NRF52 -pkg LSS59BLDFU1_s140.zip -p COM6 -n "nRF5x 92Mesh Light" -f

      Board already flashed with connectivity firmware.

    Would you help me to find what happen here?

     Is that the last thing it says? What does it print if you write the command "nrfutil --version" ?

    BR,
    Edvin

  • Hi Edvin

    Thanks for your reply.

    All works! 

    I just do it again like yesterday. The OTA dfu be performed by nRFUtil command on both of PCA10056 and PCA10059.  

    I think there maybe is some  interferon factor make the dfu breaken yesterday.

    Thank you a lots for your patience and precise help!

    Best Regard,

    Di-Sheng

  • Hello again Edvin,

    I hope you are still able to see this response even after all this time. I have been retasked to figure out whats wrong, so I am resurrecting this thread.

    I dont see any output in the Debug Terminal at all. And when the program halts in the Debugger at the NRF_BREAKPOINT_COND; in the Fault Handler of "app_eroor_weak.c", I can see that DEBUG is defined. I notice that there is technically some output in the Debug Terminal: about 6 empty lines.

    When I "Attach Debugger", I am attaching it to the device after the device has been put into DFU mode. To be specific, I flashed the DFU Secure Bootloader example and triggered DFU mode via a push button (I also tested that it could upload a previous application image correctly before putting it in DFU mode again). While its in DFU mode awaiting my new code, I attach the debugger from the SEGGER Embedded Studio IDE. Then from my iPhone, I connect to the device, and start DFU with the prepared HEX code of my own Buttonless_DFU app code (this is a merge of the standard Buttonless DFU app which has been tested and works, along with the BLE UART example code and the TWI sensor code). From the nRF Connect app on my iPhone, the DFU process finishes and I get a little message saying that the DFU was completed successfully. However, my device never starts advertising again, so I cannot connect to it and run the application. I confirm that it is an issue with the Application Code because I am able to put it back into DFU mode and successfully upload a previous Application Image without any issues and it works as expected. So I must be doing something wrong with the merged Buttonless DFU/BLE Uart/TWI Sensor code.

    What else can I do? Is there any other option for me to Debug this? Thank you so much for your help

Related