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.

[Aftab]

The build does not fail with the flash_placement.xml file you provided

[Vidar Berg]

Yes, but you were not getting the NRF_DFU_RES_CODE_INSUFFICIENT_RESOURCES error on your last attempt either.

[Aftab]

The old bootloader advertised with name DfuTarg, the new one is with Dfu_ABCD_X, does this affect anything? Also if I with download the bootloader onto barebone device, it quickly starts advertising. Not sure what is missing here.

[Aftab]

What causes this error?

When writing 'CREATE' command to Control Point Characteristic of DFU Target: Operation code 1 (CREATE) failed on DFU Target. Result code 3 (INVALID_PARAMETER).

[Vidar Berg]

Aftab said:

When writing 'CREATE' command to Control Point Characteristic of DFU Target: Operation code 1 (CREATE) failed on DFU Target. Result code 3 (INVALID_PARAMETER).

It's difficult to say as the error does not say what the parameters were. When do you experience this, and are you still using the built-in DFU library in the nRF Connect for desktop app?

Aftab said:

The old bootloader advertised with name DfuTarg, the new one is with Dfu_ABCD_X, does this affect anything? Also if I with download the bootloader onto barebone device, it quickly starts advertising. Not sure what is missing

I need more information to speculate where it might be failing. Are you able to attach a debugger to the target?

[Aftab]

Vidar Berg said:

Aftab said:

When writing 'CREATE' command to Control Point Characteristic of DFU Target: Operation code 1 (CREATE) failed on DFU Target. Result code 3 (INVALID_PARAMETER).

It's difficult to say as the error does not say what the parameters were. When do you experience this, and are you still using the built-in DFU library in the nRF Connect for desktop app?

It happens when I try to upload the bl+sd (340) + app bundle/zip file, here is the log:

https://drive.google.com/file/d/1eJsnySkHJa9xZuJbk6xhsGh439tM3vFA/view?usp=sharing

Before this, I upload the modified bootloader (s140 based) zip file which uploads correctly on a non-modified s140 bootloader. I could see the modified advertising name of the device. That means the required bootloader upgrade was complete.