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

Generate package to migrate SD+BL+APP from SDK15 to SDK17

prodrigues

Hi all,

First I would like to notice that I did look into the forum and found this similar question which did not solve my problem:
https://devzone.nordicsemi.com/f/nordic-q-a/27862/update-sd-bl-app-from-sdk-v13-to-v14-via-dfu-fails

My problem:

  1. I have custom boards that have APP+SD+BL running based on nRF5_SDK_15.2.0 (sd_id 0xAF).
  2. I have an application project and a bootloader project that work with nRF5_SDK_17.0.2. If I merge the SD+BL+APP .hex files and program the custom board with the resulting .hex with a JLINK programmer the code runs as expected
  3. If I generate a DFU .zip with the same content the DFU fails (I am performing DFU over BLE with nRFConnect android APP).
    1. The DFU starts and does the first part (BL+SD?)
    2. Then the app disconnects and tries to connect again as expected for the second part of the DFU (right?)
    3. It stays like this for a while without being able to connect. Then it stops trying and the DFU is not completed. 

This is what I have regarding the nrfutil package generation:

dfu_bootloader_sd_app:
	@nrfutil pkg generate --hw-version 52 --sd-req 0xAF,0x101 --application-version 5 --bootloader $(BOOTLOADER) --bootloader-version 0 --softdevice $(SOFTDEVICE) --sd-id 0x101 --application $(APPLICATION) --key-file $(KEY_FILE) $(OUTPUT_ZIP)


Can you please provide some insight?

Thanks,
Pedro

Parents
  • 0

    Hi Pedro, 


    Please use nRF Connect and check if the device after updating the BL+SD if it runs as a Bootloader and advertises anything?

    Any reason why your bootloader version in your script to generate the DFU package was "--bootloader-version 0 " ? 
    Usually the bootloader doesn't allow update to lower or the same bootloader version. 
    Please try to do SD+BL and APP DFU update separately (2 zip files) before testing with one single .zip. 

  • 0 in reply to Hung Bui

    Hi Hung,

    More info:

    When I first created the post I was only trying with nRFConnect on my Android phone. When trying with nRF connect on linux I get this error:

    17:22:31.417	Performing DFU with file: /home/prodrig/Documents/git/ble5_firmware/Output/5.0.0/bl_sd.zip
17:22:32.458	Attribute value changed, handle: 0x10, value (0x): 01-00
17:22:32.492	Attribute value changed, handle: 0x0F, value (0x): 02-00-00
17:22:32.494	Attribute value changed, handle: 0x0F, value (0x): 60-02-01
17:22:32.546	Attribute value changed, handle: 0x0F, value (0x): 06-01
17:22:32.562	Attribute value changed, handle: 0x0F, value (0x): 60-06-01-00-01-00-00-00-00-00-00-00-00-00-00
17:22:32.592	Attribute value changed, handle: 0x0F, value (0x): 01-01-97-00-00-00
17:22:32.607	Attribute value changed, handle: 0x0F, value (0x): 60-01-01
17:22:34.150	Received status with code 4 Unknown value, message: 'Error sending packet to target. Code: 0x802a'
17:22:35.653	Received status with code 4 Unknown value, message: 'Error sending packet to target. Code: 0x802a'
17:22:37.155	DFU failed with error: When writing 'CREATE' command to Control Point Characteristic of DFU Target: Could not write CREATE command: Failed to write to attribute with handle: 15: Error occured when writing. Errorcode: Unknown value (0x8005) .
17:22:37.159	Received status with code 4 Unknown value, message: 'Error sending packet to target. Code: 0x802a'
17:22:38.660	Received status with code 4 Unknown value, message: 'Error sending packet to target. Code: 0x802a'

    Hung Bui said:
    Please use nRF Connect and check if the device after updating the BL+SD if it runs as a Bootloader and advertises anything?

    No it does not advertise.

    Hung Bui said:
    Any reason why your bootloader version in your script to generate the DFU package was "--bootloader-version 0 " ? 

    That was wrong at the time of the post creation. After reading my old settings.hex I realized bootloader-version was 1. So I changed and I am now generating the packages with --bootloader-version 2.

    Hung Bui said:
    Please try to do SD+BL and APP DFU update separately (2 zip files) before testing with one single .zip. 

    Tried this. On nRF Connect from linux I had the same issue reported above. On my phone, It sent and in the end a popup appeared saying "Application has been sent successfully". But after that the device does not advertise as expected...


    Thanks,
    Pedro
  • 0 in reply to Hung Bui

    Hi Hung,

    Haven't tried everything yet but here goes some preliminary info:

    1 - Yes it advertises
    2- No it does not advertise if I run:

    nrfjprog --program Output/sd_bl.hex --sectorerase -r

    It advertises if I run:

    nrfjprog -e
nrfjprog --program Output/sd_bl.hex -r


    So, what is the difference? 

    Thanks,
    Pedro

  • 0 in reply to prodrigues

    Thanks Pedro. There could be a change in the bootloader setting. 
    I will try to test doing a DFU update here and let you know if I find something. 

  • 0 in reply to Hung Bui

    Hi Perdo, 

    Have you made sure the start address of the 2 bootloaders are the same ? I had a quick check here with the bootloader _debug version, the one in SDK v15.2 start at address 0x72000 when the one in SDK v17.0.2 starts at address 0x71000. 


    They should be the same. 

    I attached here the file I used for testing (it worked fine). 
    I used this script to generate the .zip file: 

    nrfutil pkg generate --hw-version 52 --sd-req 0xAF --sd-id 0x0101 --softdevice s132_nrf52_7.2.0_softdevice.hex  --bootloader-version 2 --bootloader Bootloader_SDK17.hex --key-file private.key sd_bl.zip

    Please unzip this: 
    DFU_SD_BL.zip

  • 0 in reply to Hung Bui

    Hi,
    indeed the variable FLASH_START=0x78000 was differing in both bootloader projects. Now, after DFU with Soft Device + Bootloader the device advertises as the bootloader!

    However, when performing DFU with full package the Application still does not start. Instead the bootloader starts.

    What could still be wrong? 

    Thanks,
    Pedro

  • 0 in reply to prodrigues

    Hi Pedro, 

    If you do it manually (2 .zip files, one SD+BL and one APP) would it work  ? 
    We need to look into why the DFU of the APP was not executed automatically. 

    Please provide the log on the phone app and let us know the app version  you are using. Have you tried both nRF Toolbox and NRF Connect ? 

Reply Children
  • 0 in reply to Hung Bui

    Hi Hung,

    Hung Bui said:
    If you do it manually (2 .zip files, one SD+BL and one APP) would it work  ? 

    No, I have the same problem. BL+SD dfu returns success popup and advertises as bootloader. APP, DFU after BL+SD dfu returns success popup but the APP does not boot (stays in bootloader instead).


    Hung Bui said:
    Please provide the log on the phone app and let us know the app version  you are using. Have you tried both nRF Toolbox and NRF Connect ? 

    Yes, tried with nRF Toolbox, same problem. 

    Bellow you may find attached the log of NRF Connect after a DFU of BL+SD+APP.

    Log 2021-02-17 14_24_01.txt

    Edit:
    Just tried the following:

    1. Flashed SD+BL by merging hex files and using nrfjprog
    2. performed DFU with the same APP Zip generated earlier for the 2 zip test and worked correctly.
  • 0 in reply to prodrigues

    Hi Pedro, 
    Please  try testing again using stock images (bootloader and apps) 
    I tested here and  got no problem upgrade to SDK 17 app.
    You may want to try debugging  the bootloader to see if anything wrong. 
    I attached here the file I used. My test's steps: 
    1. Flash bootloader+SDK v15.2 

    2. DFU update app_SDK15.zip

    3. DFU update sd_bl_SDK17.zip

    4. DFU update app_SDK17.zip 

    After step 4 the device works as expected. 
    DFU_SD_BL_18Feb.zip

Related