• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 19 replies
  • Subscribers 69 subscribers
  • Views 1184 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 327700
Options

Upgrade from s140 to s340

Aftab

Reference to my old work where I sucessfully upgraded an s140 based application to s340 (ANT supported) application here:

 Replacing s140 with s340 softdevice 

Now we have decided to change the bootloader name from simple DfuTarg to Dfu_ABCD_C where ABCD is short for the MAC address of the device to identify individual device. 

Before uplaoding the s340 based app, there is an intermediate step where I upload s140 based app but with modified bootloader which allows the s340 based app to be uploaded. The s140 bootloader by default does not allow to firmware to be replaced by an s340 based app. It i son this step where I'm facing problems.

I am using the same bootloader project as before and following the same steps. But the first half of upload is complete (bl+sd), the app.hex does not upload. The nRFConnect app gets stuck after bl+sd upload successful and then gives time out error.

I get the following error message:

I have attached the log file of the bootloader and the package generation command is:

nrfutil pkg generate --bootloader bootloader.hex --bootloader-version 1 --application app.hex --application-version 2 --application-version-string "2.0.0" --hw-version 52 --sd-req 0xB9 --sd-id 0xCA --softdevice s140_nrf52_7.0.1_softdevice.hex --key-file private.pem FW_Hotshot_hv_fv_3_files.zip

Log file: 

SN: Is there a way to directly replace an s140 based app to s340 one?

  • 0 in reply to Aftab

    Sorry, this is the command with which I generate the bootloader file:

    nrfutil pkg generate --bootloader bootloader.hex --bootloader-version 1 --hw-version 52 --sd-req 0xB9 --sd-id 0xCA --key-file private.pem FW_Hotshot_hv_fv_bootloader_only.zip

    When I try to upload this file, it gives me error:

    DFU failed with error: When writing 'EXECUTE' command to Control Point Characteristic of DFU Target: Operation code 4 (EXECUTE) failed on DFU Target. Result code 4 (INSUFFICIENT_RESOURCES).

  • 0 in reply to Aftab

    I changed the --bootloader-version 1 to --bootloader-version 2, it caused the bootloader to upload successfully but device stops advertisement and cannot be scanned even after power cycle.

  • 0 in reply to Aftab
    Aftab said:
    Result code 4 (INSUFFICIENT_RESOURCES

    This suggests that the new bootloader has a different start address in flash. Please ensure all the bootloaders you are using are linked to the same start address. Using different start address will either cause the bootloader to reject the update with the INSUFFICIENT_RESOURCES error, or accept the update and cause the device to become bricked.

  • 0 in reply to Vidar Berg

    These the project settings of both the bootloaders, they are same:

    Old bootloader
    FLASH_PH_START=0x0
    FLASH_PH_SIZE=0x100000
    RAM_PH_START=0x20000000
    RAM_PH_SIZE=0x40000
    FLASH_START=0xf8000
    FLASH_SIZE=0x6000
    RAM_START=0x20005968
    RAM_SIZE=0x3a698

    New bootloader
    FLASH_PH_START=0x0
    FLASH_PH_SIZE=0x100000
    RAM_PH_START=0x20000000
    RAM_PH_SIZE=0x40000
    FLASH_START=0xf8000
    FLASH_SIZE=0x6000
    RAM_START=0x20005968
    RAM_SIZE=0x3a698

  • 0 in reply to Aftab

    Bootloader updates always require a higher version number. The bootloader will not accept a bootloader update of the same version or lower, and the error response if the version requirement is not met should be NRF_DFU_RES_CODE_EXT_ERROR + NRF_DFU_EXT_ERROR_FW_VERSION_FAILURE. 

    NRF_DFU_RES_CODE_INSUFFICIENT_RESOURCES should only be returned if the data object is too big or if the new bootloader is too big to fit in the allocated bootloader region.

    Which SDK version are you on?

Related