• State Not Answered
  • Replies 15 replies
  • Subscribers 68 subscribers
  • Views 2175 views
  • Users 0 members are here
Attachments (3) Download All
Nordic Case Info
  • Case ID: 237385
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DOUBT IN ZIP FILE GENERATION FOR OTA -DFU.

NANDHU

HI ,

  I need the nrfutil commands used to generate the following zip file

  1. softdevice only
  2. bootloader only
  3. softdevice + bootloader  
  4. softdevice +bootloader+application 

If you can please attach the  command used for generating each zip file in the reply ,please don't provide any link because it  time consuming. 

please answer to 1,2,3 and 4 only.

  • 0 in reply to NANDHU

    If it is not advertising as DFU targ, then there is probably a bug in your application that causes the chip to reset before it starts advertising. Do you remember the ticket where I told you about debugging when there is a bootloader present?

    In Segger Embedded Studio, you can just press "Tools" -> "Attach Debugger" from the toolbar menu when you have your application project open, and it will start the debug session.

  • 0 in reply to Edvin
    Edvin said:
    If it is not advertising as DFU targ, then there is probably a bug in your application that causes the chip to reset before it starts advertising.

    Actually there is no application in the DK only SD and BL and also there is no application hex in the zip file too.

     You mean the application for bootloader ?

    Edvin said:
    Do you remember the ticket where I told you about debugging when there is a bootloader present?

    yes, But at that time, debug was done by you and told me to use "pca10040_ble" instead of "pca10040_ble_debug". 

  • 0 in reply to NANDHU

    You can debug the application using the "pca10040_ble" bootloader project as long as you program the bootloader settings, and use "attach debugger" instead of "build and debug".

    The difference between "attach debugger" and "build and debug" is that "build and debug" will upload the .hex file. When you do this from the IDE, the application will behave the same, but there are some bit differences. If there are any bit differences it means that the signature of the application will change(the signature generated when you create the DFU image or if you generate the bootloader settings and program it manually).

    If the signature changes it means that the bootloader will reject the application. 

    So use "attach debugger". 

  • 0 in reply to Edvin

    Just tell me one thing Edvin.

    If a DK contains only SD and BL of sdk 14.2 and its advertising as "DfuTrag"

    Then using nRF_Connect desktop application  we done a OTA -DFU to that DK .

    The zip file used for OTA-DFU contains SD and BL of sdk 15.3.

    After the OTA -update reaches 100% (ie transfer completed) what will happen to DK?

    Is the DK advertise as "DfuTrag " from new bootloder which is updated through OTA or not.

    Edvin said:
    If the signature changes it means that the bootloader will reject the application. 

    Actually there is no application is using man . please try to understand.

  • 0 in reply to NANDHU
    NANDHU said:
    Is the DK advertise as "DfuTrag " from new bootloder which is updated through OTA or not.

     Yes. The "DfuTarg" is from the new bootlaoder. You can confirm this by changing the advertising name of the bootloader if you open the bootloader project from SDK15.3.0, and go into sdk_config.h, and look for:

    #define NRF_DFU_BLE_ADV_NAME "DfuTarg"

    Change it to 

    #define NRF_DFU_BLE_ADV_NAME "Dfu15"

    Or something else (not too long). 

Related