This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

doing dfu ble as a PCA10059 dongle

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

Parents
  • 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

  • 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

  • I tried something like this :

    nrfutil pkg generate --sd-req 0x0 --sd-id 0x0 --hw-version 52 --key-file private.key --application-version 1 --application connectivity_4.1.1_usb_for_s132_5.1.0.hex --softdevice s132_nrf52_5.1.0_softdevice.hex dfu.zip
    Zip created at dfu.zip

    I programmed PCA10056 DK with secured usb bootloader already flashed in it.

    It took a while but the dfu.zip was programmed.

    After that I had no the desired connectivity firmware working in order to do ota updating of a second board.

    To recap:

    the situation is:

    In PCA10056 DK s132_nrf52_5.1.0_softdevice.hex and connectivity_4.1.1_usb_for_s132_5.1.0.hex make it possible to do ota updating of a second board, when both files are flashed using jlink

    In the same PCA10056 I flashed the dfu.zip built with those working hex files, but using the secured usb bootloader. And it is not possible anymore to do ota updating of a second board.

    I don't know either if I'm wrong using precompiled files and/or wrong settings or I need to re build with appropriate option for the linker.

    Hope my question is clear.

    Thank you

  • 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.

  • 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

  • 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. 

  • 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

Reply Children
No Data
Related