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

[Hung Bui]

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. 

[prodrigues]

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

[Hung Bui]

Hi Pedro, 
Regarding the issue with Linux, what you reported (error 0x802a) similar to one of the case here. You may need to disable MSD to use nrfConnect on Linux. 

I would suggest to try the following: 

1. Flash the stock BL+SD of SDK v15.2. Verify that it's advertising.

2. Flash the stock BL+SD of SDK v17 to the same chip (do nrfjprog --program with --sectorerase) . Verify that the new bootloader is advertising. 

3. Read flash out using nrfjprog --readcode 

4. Erase the chip and Redo Step 1.

5. Do DFU update of BL+SD of SDK v17 . 

6. If it's not advertising try read flash out using nrfjprog --readcode

7. Compare the 2 hex dump at step 3 and step 6. I usually use Notepad++ to compare. 

Please send us your files (including the private keys and public keys, the .zip file, your bootloader and softdevice in SDK v15.2 ) so that we can test here.

[prodrigues]

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

[Hung Bui]

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. 

[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

[prodrigues]

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

[Hung Bui]

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 ?