• State Not Answered
  • Replies 18 replies
  • Subscribers 66 subscribers
  • Views 724 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

    Hello,

    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.

    Maybe I'm forgetting some details, but my recollection is that this limitation only applied to the SoftDevice, not the app. The bootloader has no way of knowing what SoftDevice an app upgrade was built for. So, isn't it sufficient to only upgrade the bootloader in the intermdiate step?

    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.

    Can you attach a debugger to the board to find out if the program may have crashed, or does it continue to advertise?

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

    You mean s340 based application + the S340 Softdevice? This will only work if the bootloader currently present on your device has been patched to allow the Softdevice variant to be changed.

    Best regards,

    Vidar

  • 0 in reply to Vidar Berg
    Vidar Berg said:
    So, isn't it sufficient to only upgrade the bootloader in the intermdiate step?

    I tried that and it gives error 3, INVALID PARAMETER error.

    Vidar Berg said:
    Can you attach a debugger to the board to find out if the program may have crashed, or does it continue to advertise?

    I haven't attached debugger yet bit it does not advertise any longer.

    Vidar Berg said:
    You mean s340 based application + the S340 Softdevice? This will only work if the bootloader currently present on your device has been patched to allow the Softdevice variant to be changed.

    That was the original idea, I previously did many things including re-compiling the bootloader against the s340 API headers (details here:  BLE Bootloader example). This helped me device advertise with DfuTarg name. But uploading the s340 based app again gives error 3 INVALID_PARAMETER.

  • 0 in reply to Aftab
    Aftab said:
    I tried that and it gives error 3, INVALID PARAMETER error.

    This should work. Maybe there was an issue with the init command. Can you show the nrfutil command you used to create this update? 

    Aftab said:
    That was the original idea, I previously did many things including re-compiling the bootloader against the s340 API headers (details here:  BLE Bootloader example). This helped me device advertise with DfuTarg name. But uploading the s340 based app again gives error 3 INVALID_PARAMETER.

    The intermediate bootloader does not need to be compatible with the S340 API (the S140 SoftDevice will be present on the DFU target at this point), as the new bootloader for S340 should be updated along with the S340 SoftDevice.

  • 0 in reply to Vidar Berg

    This is the command:

    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

    Vidar Berg said:
    The intermediate bootloader does not need to be compatible with the S340 API (the S140 SoftDevice will be present on the DFU target at this point), as the new bootloader for S340 should be updated along with the S340 SoftDevice.

    The intermediate bootloader plus s340 softdevice uploads successfully but after power cycle, the device cannot be scanned.

    Vidar Berg said:
    You mean s340 based application + the S340 Softdevice? This will only work if the bootloader currently present on your device has been patched to allow the Softdevice variant to be changed.

    Exactly what changes are required in this case?

  • 0 in reply to Aftab
    Aftab said:
    This is the command:

    This creates a combined sd+bl+app update, not BL only. 

    Aftab said:
    The intermediate bootloader plus s340 softdevice uploads successfully but after power cycle, the device cannot be scanned.

    The intermidate bootloader was to allow the s340 to be updated in the first place. The S340 SoftDevice, bootloader, and app can be updated after updating to the intermediate bootloader.

Related