• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 12 replies
  • Subscribers 96 subscribers
  • Views 4007 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 294733
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

nRF52820 softdevice DFU

Louis_263

Hi,

I managed to do a DFU with an application on a nRF52820. Now I wanted to test if I can also update the softdevice. For this I read the following article:
infocenter.nordicsemi.com/index.jsp
Under the point "Single-bank updates" I saw that with a new softdevice the application area is deleted, and the softdevice is first copied into the application area and then copied into its destinated area. Since in my nRF52820 is not enough space for a softdevice in the application area, I wanted to ask whether a DFU of the softdevice is possible at all?

This is a screenshot of my memory usage:

pink area: bootloader

green area: application

blue/orange area: softdevice and MBR

Edit from 2.9.2022:

If I set the macro NRF_DFU_SINGLE_BANK_APP_UPDATES to 1, it does not work, because there is not enough space according to the log (is attached to this post). I generated the softdevice DFU package with the following command:

nrfutil pkg generate --hw-version 52 --sd-req 0x100 --softdevice s140_nrf52_7.2.0_softdevice.hex --key-file private.pem app_dfu_package_sd_s140.zip

Fullscreen 6378.dfu_sd_not-working_rtt-log.txt Download 
00> <info> app Inside main
00> <debug> app: In nrf_bootloader_init
00> <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
00> <debug> nrf_dfu_settings: Using settings page.
00> <debug> nrf_dfu_settings: Copying forbidden parts from backup page.
00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
00> <info> nrf_dfu_settings: Backing up settings page to address 0x3E000.
00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
00> <debug> app: Enter nrf_bootloader_fw_activate
00> <info> app: No firmware to activate.
00> <info> app: Boot validation failed. No valid app to boot.
00> <debug> app: DFU mode because app is not valid.
00> <info> nrf_bootloader_wdt: WDT is not enabled
00> <debug> app: in weak nrf_dfu_init_user
00> <debug> app: timer_stop (0x20002A58)
00> <debug> app: timer_activate (0x20002A58)
00> <info> app: Entering DFU mode.
00> <debug> app: dfu: NRF_DFU_EVT_DFU_INITIALIZED
00> <debug> app: Initializing transports (found: 1)
00> <debug> nrf_dfu_serial_uart: serial_dfu_transport_init()
00> <debug> nrf_dfu_serial_uart: serial_dfu_transport_init() completed
00> <debug> app: dfu: NRF_DFU_EVT_TRANSPORT_ACTIVATED
00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
00> <debug> app: Enter main loop
00> <debug> nrf_dfu_serial: Received ping 1
00> <info> nrf_dfu_serial_uart: Allocated buffer 200041C0
00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_PING
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
00> <debug> nrf_dfu_serial: Sending Response: [0x9, 0x1]
00> <debug> nrf_dfu_serial: Set receipt notif target: 0
00> <info> nrf_dfu_serial_uart: Allocated buffer 200041C0
00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_RECEIPT_NOTIF_SET
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
00> <debug> nrf_dfu_serial: Sending Response: [0x2, 0x1]
00> <debug> nrf_dfu_serial: Received serial mtu
00> <info> nrf_dfu_serial_uart: Allocated buffer 200041C0
00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_MTU_GET
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
00> <debug> nrf_dfu_serial: Sending Response: [0x7, 0x1]
00> <info> nrf_dfu_serial_uart: Allocated buffer 200041C0
00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_SELECT (command)
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
00> <debug> nrf_dfu_serial: Sending Response: [0x6, 0x1]
00> <debug> app: Shutting down transports (found: 1)
00> <info> nrf_dfu_serial_uart: Allocated buffer 200041C0
00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_CREATE (command)
00> <debug> app: timer_stop (0x20002A58)
00> <debug> app: timer_activate (0x20002A58)
00> <debug> app: dfu: NRF_DFU_EVT_DFU_STARTED
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
00> <debug> nrf_dfu_serial: Sending Response: [0x1, 0x1]
00> <info> nrf_dfu_serial_uart: Allocated buffer 20004244
00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (command)
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
00> <debug> nrf_dfu_serial: Sending Response: [0x3, 0x1]
00> <info> nrf_dfu_serial_uart: Allocated buffer 200041C0
00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (command)
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
00> <debug> nrf_dfu_serial: Sending Response: [0x3, 0x1]
00> <info> nrf_dfu_serial_uart: Allocated buffer 20004244
00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (command)
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
00> <debug> nrf_dfu_serial: Sending Response: [0x3, 0x1]
00> <info> nrf_dfu_serial_uart: Allocated buffer 20004244
00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_CRC_GET (command)
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
00> <debug> nrf_dfu_serial: Sending Response: [0x3, 0x1]
00> <info> nrf_dfu_serial_uart: Allocated buffer 20004244
00> <debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_EXECUTE (command)
00> <debug> nrf_dfu_validation: PB: Init packet data len: 68
00> <info> nrf_dfu_validation: Signature required. Checking signature.
00> <info> nrf_dfu_validation: Calculating hash (len: 68)
00> <info> nrf_dfu_validation: Verify signature
00> <info> nrf_dfu_validation: Image verified
00> <debug> app: Enter nrf_dfu_cache_prepare()
00> <debug> app: required_size: 0x25634.
00> <debug> app: single_bank: true.
00> <debug> app: keep_app: false.
00> <debug> app: keep_softdevice: true.
00> <debug> app: SD_PRESENT: true.
00> <debug> app: Bank contents:
00> <debug> app: Bank 0 code: 0x00: Size: 0x0
00> <debug> app: Bank 1 code: 0x00: Size: 0x0
00> <debug> app: pass: 0.
00> <debug> app: cache_address: 0x27000.
00> <debug> app: cache_too_small: true.
00> <debug> app: keep_firmware: false.
00> <debug> app: delete_more: true.
00> <debug> app: pass: 1.
00> <debug> app: cache_address: 0x27000.
00> <debug> app: cache_too_small: true.
00> <debug> app: keep_firmware: true.
00> <debug> app: delete_more: true.
00> <warning> app: Aborting. Cannot fit new firmware on device
00> <error> nrf_dfu_validation: Can't find room for update
00> <debug> nrf_dfu_req_handler: Request handling complete. Result: 0x4
00> <warning> nrf_dfu_serial: DFU request completed with result: 0x4
00> <debug> nrf_dfu_serial: Sending Response: [0x4, 0x4]
00> <debug> app: dfu: NRF_DFU_EVT_DFU_FAILED

How can I perform the DFU so that the existing softdevice is deleted?

BR

Louis

Parents
  • 0

    Hi  ,

    I have tried the solution approach and the transfer of the DFU also works without problems, I get displayed: "Device programmed".
    However, after the DFU (App+Softdevice), the application no longer starts. I looked at the memory after the DFU and discovered an anomaly, see the image below:

    There is a "gap" in the softdevice and I don't know why it is there. Maybe it means that the application is no longer being called.
    Maybe you can help me.

    Update:

    I found out that the actual application is written to the beginning of the softdevice (see the following pictures). How can this happen?
    Can't the memory area of the softdevice simply be deleted and then the new softdevice be written there? And the same with the application. I don't understand why the application is written to the beginning of the softdevice area.

    This is the log of the DFU of the application (executed after the DFU of the softdevice):

    log_wrong_dfu.txt

    There you can see that somehow this does not work as I imagined. The cache_address is initially set to 0x27000 (i.e. the start of the application) and is then set to 0x1000 (i.e. the start of the softdevice).

    BR

    Louis

Reply
  • 0

    Hi  ,

    I have tried the solution approach and the transfer of the DFU also works without problems, I get displayed: "Device programmed".
    However, after the DFU (App+Softdevice), the application no longer starts. I looked at the memory after the DFU and discovered an anomaly, see the image below:

    There is a "gap" in the softdevice and I don't know why it is there. Maybe it means that the application is no longer being called.
    Maybe you can help me.

    Update:

    I found out that the actual application is written to the beginning of the softdevice (see the following pictures). How can this happen?
    Can't the memory area of the softdevice simply be deleted and then the new softdevice be written there? And the same with the application. I don't understand why the application is written to the beginning of the softdevice area.

    This is the log of the DFU of the application (executed after the DFU of the softdevice):

    log_wrong_dfu.txt

    There you can see that somehow this does not work as I imagined. The cache_address is initially set to 0x27000 (i.e. the start of the application) and is then set to 0x1000 (i.e. the start of the softdevice).

    BR

    Louis

Children
  • 0 in reply to Louis_263

    Hi Louis,

    The init command for the application update must include the FWID of the Softdevice the app was built for (i.e. 0x0100 if you still use s140 v7.2.0), and not 0x00. When the FWID is 0x00, it tells the bootloader that the application is meant to run without the Softdevice, so it will overwrite it.

    Can you post the command you used to make the combined Softdevice+application update package?

  • 0 in reply to Vidar Berg

    Hi Vidar,

    this is the command I used:

    nrfutil pkg generate --hw-version 52 --application app.hex --application-version 1 --sd-req 0x00,0x100 --sd-id 0x100 --softdevice s140_nrf52_7.2.0_softdevice.hex --key-file private_key.pem app_sd_dfu_package.zip

    BR

    Louis

  • 0 in reply to Louis_263

    Hi Louis,

    Thanks. I see from your command that you are correctly setting the FWID requirements so you are likely experiencing this bug that was addressed in nrfutil v6.1.7:  https://github.com/NordicSemiconductor/pc-nrfutil/releases

    Please upgrade nrfutil and try again.

  • 0 in reply to Vidar Berg

    Hi Vidar,

    Thanks for the quick reply, I will try it and get back to you.

    Maybe I'll list here again all the steps I've done so far, then maybe you can check if everything is correct.

    • I took the UART secure bootloader project as is, and used the following preprocessor symbols for me:
      • CONFIG_GPIO_AS_PINRESET
        FLOAT_ABI_SOFT
        NRF52820_XXAA
        BOARD_PCA10100
        NRF_DFU_SINGLE_BANK_APP_UPDATES=1
        NRF_DFU_FORCE_DUAL_BANK_APP_UPDATES=0
        NRF_DFU_SETTINGS_VERSION=2
        SVC_INTERFACE_CALL_AS_NORMAL_FUNCTION
        __HEAP_SIZE=0
        uECC_ENABLE_VLI_API=0
        uECC_OPTIMIZATION_LEVEL=3
        uECC_SQUARE_FUNC=0
        uECC_SUPPORT_COMPRESSED_POINT=0
        uECC_VLI_NATIVE_LITTLE_ENDIAN=1
    • I generate the bootloader settings for my project, consisting of softdevice, app and bootloader, with the following command:
      • nrfutil settings generate --family NRF52QFAB --application app.hex --application-version 1 --bootloader-version 1 --bl-settings-version 2 settings.hex
    • With a custom command I jump from the application into the bootloader (GPREGRET method) and thus trigger a DFU
    • I generate the DFU package with the following command:
      • nrfutil pkg generate --hw-version 52 --application app.hex --application-version 1 --sd-req 0x00,0x100 --sd-id 0x100 --softdevice s140_nrf52_7.2.0_softdevice.hex --key-file private_key.pem app_sd_dfu_package.zip
    • During the DFU the old softdevice and the old application should be deleted and replaced 1 to 1 at the same location in flash memory by the new softdevice and the new application
  • 0 in reply to Louis_263

    I don't see any problems with what you have done so far.

    The only way the application update will be allowed to overwrite the Softdevice is if the signed init command for the app contains 0x00 in its  SD FWID list as shown below.

    Output from 'nrfutil pkg display 'ZIP_FILE' command:

Related
Terms of service