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

    Thanks for your reply, I am sorry, I didn't make the question clear.

    I have just successfully completed the Buttonless Dfu experiment based on the BLE_app_blinky example on the DK(PCA10056) board.So I tried to do the Buttonless DFU experiment on the light-Swtich Server example of Mesh on the DK(PCA10056) board in the same way.

    Before your reply, I always thought that the method of adding buttonless Dfu function to the application must also support ble application and Mesh application. Through your reply, I realize that may be not ture. However, from your reply, I think it is still necessary to ask you to look at the process, which can help me to figure out many problems

    Software stack:

    • nRF5_SDK_16.0.0_98a08e2
    • nrf5_SDK_for_Mesh_v4.0.0_src

    Soft device:  S140

    Soft tools:

    • SES 4.22
    • nRF Connect--> Bluetooth Low Energy
    • nRFutil
    • nRFjprog
    • nRF Connect-->Programmer

    Hardware is 2 pcs DK(PCA10056). One of them is used as PDK for ble dfu, which be programmed the pca10056_s140_ble_debug project (nRF5_SDK_16.0.0_98a08e2\examples\dfu\secure_bootloader\pca10056_s140_ble_debug) as dfu bootloader. The other DK is a target board, which be programmed the same dfu bootloader, after it be erased by "nrfjpro -e" command.

     Dfu Prepare:

    A ZIP file will be used for updating via " nRF Connectà Bluetooth Low Energy " and PDK to the target DK, which is in DFU mode after writing to boot Loader but before writing to the application.

    The zip file generation command is as follows:

    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 LSS56BLDFU_s140.zip

    Note:the publice key of bootloader is come from the private.key, so all key is match.

    "s140_nrf52_7.0.1_softdevice.hex" is the softdevice which come from " nRF5_SDK_16.0.0_98a08e2"

    " light_switch_server_nrf52840_xxAA_s140_7.0.1.hex" is the application project which is a example of mesh and be modified for adding buttonless dfu function according to here instructions with some extra operation (please see my last post) which are adding some include files and include directories into the project for eliminate compilation errors.  

    Dfu Process:

    After target Dk power on, I can find a device which device name is " DFU Targ by " nRF Connect--> Bluetooth Low Energy " and PDK. Connecting it and DFU ZIP file will be completed. all process will be ok like I do blinky example.

    Result:

                When DFU update is completed, LED1-4 flashes together under normal conditions, and then the device named "nRF5 Mesh Light" can be found through " nRF Connect--> Bluetooth Low Energy " and PDK. But now it is only LED1-4 that is lit together, and it is always on, and any information of this device is also found through " nRF Connect--> Bluetooth Low Energy " and PDK.

    Because only project application project (light_switch_server_nrf52840_xxAA_s140_7.0.1.hex) was modified, the rest parts such as Bootlader and Softdevice were the same as Button DFU before, and since BLE DFU was adopted, the bootloader setting page of the application was generated by bootloader, so the SES's "Section Placement Macros" of the application project do not be modified, and the contents of "Section Placement Macros"  were still as follows:

    • FLASH_PH_START=0x0
    • FLASH_PH_SIZE=0xf8000
    • RAM_PH_START=0x20000000
    • RAM_PH_SIZE=0x3f000
    • FLASH_START=0x27000
    • RAM_START=0x20002e00

     That is all I have to say about my attempt to add the Buttonless function to the Mesh example.

    My questions is follow:

    Q1. I think I understand the difference between the Mesh implementation mechanism you mentioned and ble. In other words, the Buttonless function added according to BEL will not only not start the application into DFU mode, but also disturb the normal operation of the Mesh application. Is that correct?

    Q2. If I still want add ble buttonless dfu to mesh's application, how should I do? What are the specific steps?Any special attention?Do you have any recommendations?

    Q3. Based on the buttonless function process and results of the mesh application described above, can you determine the cause? How can I make sure where it stuck ? 

    Q4  I'll take a look at the SD_ble_gatts_service_add () and SD_ble_gatts_characteristic_add () functions, based on what you said in your last post.  You also side "Please check the log from the device.". Would you like to explain that to me about how and what can I do?

    Q5 You said last post "Does it set aside space for the FDS (if you use that at all)? And does it set aside space for the bootloader?".  What does FDS mean? and What does "does it set aside space for the bootloader?" mean?

    Then I compare two chips maps by nRFConnect -->Programmertools, One of them is a ble_app_blinky example for PCA10056 with successful  buttonless dfu function, The other one is the light-switch server of Mesh with unsuccessful buttonless dfu function.

    PIC1: nrf52840 map for ble_app_blinky with buttonless dfu of PCA10056.png

    PIC2:nrf52840 map for light-switch server with buttonless dfu of PCA10056.png

    As we know, The black , red and yellow areas in pic1 and pic2 is for Setting page and MBR-P, bootloader and MBR;

    Green A area is for Software.

    The ble_app_blinky with buttonless DFU for PCA10056.bin is about 25kByte

    The light-switch server with buttonless DFU for PCA10056.bin is about 137kByte

    So the Green B area of pic1 is for application.  The green B and C of pic2 is for application.

    My question is below:

    Q3: What is for the green C of pic1?

    Q4: Why doesn't pic2 have this piece which like Green C of pic1? Is it the reason which the application do not run?

     

    Thanks

     Best Regards,

    Di-Sheng

  • Thank you for your tips on this. Everything you mentioned proved to be true. I have to turn on and off my phone to refresh the GATT table, and if the Service Changed option is set from the beginning, it works as expected.

    Now that I confirmed that the default buttonless DFU example works as is, I have merged my previous ble_app_uart project with the buttonless DFU template. I have everything included and it builds/compiles without error.

    However, when I try to load this merged application onto my device, it doesnt run...something is faulting. When I try and use the debugger, it never successfully starts....usually when I run Build and Debug, it loads the code onto the device, and then prompts me with a Start button to begin Debugging. However, the issue with my merged Buttonless DFU/UART project is that the debugger never presents me with a Start button to click, as if its already running (I see the Pause button instead of Play in the Segger Embedded Studio). So this tells me that something is faulting before the Debugger can even start properly. I tried to see where this behavior is coming from since the dafault example works fine, and so I simply added the NUS Service UUID in 'm_adv_uuids[] as a first step, and this is enough to replicate the behavior Im talking about.

    static ble_uuid_t m_adv_uuids[]         = 
    {
        {BLE_UUID_DEVICE_INFORMATION_SERVICE, BLE_UUID_TYPE_BLE},
        {BLE_UUID_NUS_SERVICE, NUS_SERVICE_UUID_TYPE}
    };

    What would you recommend is the best way to resolve this issue? There must be some configuration issue that I am missing with the overlapping DFU and UART projects. When merging the 2 SDK Config files, there were only a few instances where the two files had different setting values. Specifically, these conflicting settings were:

    • #define PEER_MANAGER_ENABLED
      • 1 in the Buttonless DFU, 0 in the UART application
    • #define PM_CENTRAL_ENABLED
      • 0 in the Buttonless DFU, 1 in the UART application
    • #define BLE_DFU_ENABLED 1
      • This needs to be set to 1, so ignoring
    • #define CRC16_ENABLED
      • 1 in the Buttonless DFU, 0 in the UART application
    • #define FDS_ENABLED
      • 1 in the Buttonless DFU, 0 in the UART application
    • #define NRF_FSTORAGE_ENABLED
      • 1 in the Buttonless DFU, 0 in the UART application
    • #define NRF_PWR_MGMT_CONFIG_AUTO_SHUTDOWN_RETRY
      • 1 in the Buttonless DFU, 0 in the UART application
    • #define NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED
      • 1 in the Buttonless DFU, 0 in the UART application
    • #define NRF_LOG_BACKEND_RTT_ENABLED
      • 0 in the Buttonless DFU, 1 in the UART application
    • #define NRF_LOG_DEFAULT_LEVEL
      • 3 in the Buttonless DFU, 4 in the UART application
    • #define NRF_SDH_BLE_GAP_DATA_LENGTH
      • 27 in the Buttonless DFU, 251 in the UART application
    • #define NRF_SDH_BLE_GATT_MAX_MTU_SIZE
      • 23 in the Buttonless DFU, 247 in the UART application

    I also changed NRF_SDH_BLE_VS_UUID_COUNT to be 2 (previously 1) for both DFU and UART, and changed NRF_SDH_BLE_SERVICE_CHANGED to 1 (previously 0).

    Does anything seem suspicious here? Thank you so much for you time and help with this.

  • So LED1-4 is constant on. That is an important observation. That means that the bootloader accepts the application and start it.

    LED1-4 turned on is the error indication in a mesh application. 

    In Segger Embedded Studio, which you are using, there is an option to "attach debugger":

    If you do this, it means you can debug without uploading any software to the DK, which means that the bootloader will not reject the application.

    Try this, and see if you get any log output. What does the log say? If you don't get any log output, try to add some logs in the start of the application, e.g. "start". Do you see logs before you add the bootloader?

    Either way, you can also try to set breakpoints, to see whether a function is executed or not. Where does the application stop?

    BR,

    Edvin

  • Hi Edvin

    I do debug the project follow the way that you said last post. Finally, the code  stay in " sleep_forever() " function , because  err_code =0x04 be got from "SVCALL(SD_BLE_GATTS_RW_AUTHORIZE_REPLY, uint32_t, sd_ble_gatts_rw_authorize_reply(uint16_t conn_handle, ble_gatts_rw_authorize_reply_params_t const *p_rw_authorize_reply_params));"

    The link below is the debug tracking in word format.

    /cfs-file/__key/communityserver-discussions-components-files/4/Mesh-buttonless.docx

    Q1:  Would you help me to find why it get a 0x04 error code when the "ble_dfu_buttonless_init()" be executed?  -------The error code of 0x04 was actually obtained by executing "SVCALL"

    Q2: I notice the  he light-switch server project of Mesh lacks "power_management_init()" and "gatt_init()" function compared to the BLE project. Is it mean the power_management  and gatt block do not be added in the project?

    How I can add them if they are necessary or how I can remove the checking if they are not necessary?

    Thanks,

    Best Regards,

    Di-Sheng

  • The Mesh stack has it's own way of sleeping, and uses sd_app_evt_wait() for this. 

     

    Di-sheng said:
    How I can add them if they are necessary or how I can remove the checking if they are not necessary?

     What do you mean by "remove the checking if they are not necessary"?

     

    Di-sheng said:
    Q2: I notice the  he light-switch server project of Mesh lacks "power_management_init()" and "gatt_init()" function compared to the BLE project. Is it mean the power_management  and gatt block do not be added in the project?

     This is handled other ways. 

     

    Di-sheng said:
    Q1:  Would you help me to find why it get a 0x04 error code when the "ble_dfu_buttonless_init()" be executed?  -------The error code of 0x04 was actually obtained by executing "SVCALL"

     If you look in your sdk_config.h file, you should see a define: NRF_SDH_BLE_VS_UUID_COUNT, which is by default set to 0. Set it to 1. When you do this, your main() -> initialize() -> ble_stack_init() -> nrf_sdh_ble_enable() will print something about changing the RAM start and RAM size. 

    Now, it doesn't do that by default, because the "normal" SDK uses a different logging module than the mesh SDK, and the function that checks the RAM settings is from the normal SDK, so it will not print anything.

    So there are a few things you need to do. In nrf_sdh_ble.c, add the following things:

    #include "log.h"
    
    #undef NRF_LOG_INFO
    #undef NRF_LOG_WARNING
    #undef NRF_LOG_DEBUG
    
    
    #define NRF_LOG_INFO        __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, __VA_ARGS__);
    #define NRF_LOG_WARNING     __LOG(LOG_SRC_APP, LOG_LEVEL_WARN, __VA_ARGS__);
    #define NRF_LOG_DEBUG       __LOG(LOG_SRC_APP, LOG_LEVEL_DBG1, __VA_ARGS__);
    

    Then, in nrf_sdh_ble_enable() in the same file, add \n, at the end of all the NRF_LOG_WARNING, NRF_LOG_DEBUG and NRF_LOG_ERROR calls. E.g. change:

    NRF_LOG_WARNING("Insufficient RAM allocated for the SoftDevice.");
    to
    NRF_LOG_WARNING("Insufficient RAM allocated for the SoftDevice.\n");

    Then it should say something about the RAM in your log. In my case it says:

    <t:       8299>, nrf_sdh_ble.c,  249, RAM starts at 0x20002E00
    <t:       8302>, nrf_sdh_ble.c,  252, RAM start location can be adjusted to 0x20002440.
    <t:       8306>, nrf_sdh_ble.c,  255, RAM size for application can be adjusted to 0x3DBC0.

    You need to change this in your project settings:

    Hopefully, that solves the issue.

    Don't worry about the RAM size. It is not used in the Mesh examples.

Related