doing dfu ble as a PCA10059 dongle

[astella]

To the kind attention of Nordic support team,

I'm very interested in understanding how to have firmware that is working as in PCA10059 in respect to USB bootloader and fw connectivity to do dfu ble.

I did:

C:\Users\astella\AppData\Local\Programs\Python\Python38\Lib\site-packages\pc_ble_driver_py\hex\sd_api_v5>nrfjprog --eraseall
Erasing user available code and UICR flash areas.
Applying system reset.

Then:

C:\Users\astella\AppData\Local\Programs\Python\Python38\Lib\site-packages\pc_ble_driver_py\hex\sd_api_v5>nrfjprog --family nRF52 --program s132_nrf52_5.1.0_softdevice.hex
Parsing hex file.
Reading flash area to program to guarantee it is erased.
Checking that the area to write is not protected.
Programming device.

And:

C:\Users\astella\AppData\Local\Programs\Python\Python38\Lib\site-packages\pc_ble_driver_py\hex\sd_api_v5>nrfjprog --family nRF52 --program connectivity_4.1.1_usb_for_s132_5.1.0.hex
Parsing hex file.
Reading flash area to program to guarantee it is erased.
Checking that the area to write is not protected.
Programming device.

After that I had nRF Connect USB CDC ACM (COM12) in my Device Manager and

>nrfutil -v -v -v -v dfu ble -ic NRF52 -pkg app26022020.zip -p COM12 -n "DfuTarg" worked fine. So that I'm really happy about that.

The thing that I'm still missing in the puzzle, is usb bootloader. I already tried and tested USB secured bootloader.

I was wondering If I can use USB secured bootloader,  s132_nrf52_5.1.0_softdevice.hex and connectivity_4.1.1_usb_for_s132_5.1.0.hex together?

Are they compiled in order to work well together? Can I use hex files how they are? Should I do any modification to their src code and rebuild them, for example to link them

appropriately?

Thank you for all your kindness and your work

[astella]

I saw in C:\Users\astella\AppData\Local\Programs\Python\Python38\Lib\site-packages\pc_ble_driver_py\hex\sd_api_v5

connectivity_4.1.1_usb_with_s132_5.1.0.hex. I understood it is an hex file containing soft device and usb connectivity firmware together.

I'm trying to do a dfu package using this file, so that it can be used with the usb bsecured bootloader

[astella]

When I compile my own application in order to work together with the usb bootloader, I add linker info for flash start and ram start. I don't know if connectivity_4.1.1_usb_with_s132_5.1.0.hex has been linked so that it can be used to generate a dfu package. May you please confirm it? I have tried and did a dfu package but it seems it doesn't work yet

[astella]

I flashed PCA10056 DK with usb open bootloader coming from sdk15.2

Then I used  C:\Users\astella\AppData\Local\Programs\Python\Python38\Lib\site-packages\pc_ble_driver_py\hex\sd_api_v5

connectivity_4.1.1_usb_with_s132_5.1.0_dfu_pkg.zip

Using these files, I was able to program PCA10056

nrfutil dfu usb-serial -pkg connectivity_4.1.1_usb_with_s132_5.1.0_dfu_pkg.zip -p COM13

After that, connectivity firmware was running properly and I was able to do ota updating in a second board

using this command:

nrfutil dfu ble -ic NRF52 -pkg app26022020.zip -p COM12 -n "DfuTarg"
[####################################] 100%
Device programmed.

[astella]

After a reset PCA10056 DK always start the open bootloader, it seems like the previously flashed connectivity firmware cannot run after the first time anymore

[Vidar Berg]

After a pinreset? The open booloader is configured to enter DFU mode after pinresets by default (can be disabled in sdk_config.h). It detects this by reading out the POWER->RESETREAS on boot. 

[astella]

Thank you so much Vidar for your help.

NRF_BL_DFU_ENTER_METHOD_PINRESET was set as 1 in sdk_config.h.

When set as a 0 the flashed program is running, even after removing power supply and put power supply back again. That is fine and thank you for let me discover those settings in sdk_config.h

[jacksong]

awesome!!!