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?

[Vidar Berg]

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

[Aftab]

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.

[Vidar Berg]

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.

[Aftab]

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?

[Vidar Berg]

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.

[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).

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

[Vidar Berg]

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.

[Aftab]

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