Replacing s140 with s340 softdevice

[Aftab]

Hello,

nRF SDK v16.0, Softdevices s140_nrf52_7.0.1_softdevice and ANT_s340_nrf52840_6.1.1

Recently we wanted to add ANT to our BLE application. So we changed the softdevice in the application from S140 to S340. The new BLE+ANT app runs smoothly. Now we wanted to upgrade our existing devices with new ANT functionality/firmware. But we ran into problem while DFUing the new firmware on our existing devices running S140 softdevice and our app. The bootloader was created using same SDk16.0. We have been successfully upgrading these devices with S140 based applications in past.

The nRFConnect PC application gives two different errors for two different package generate commands (please see the attached images below)

nrfutil pkg generate --application app.hex --application-version 1 --application-version-string "1.0.0" --hw-version 52 --sd-req 0xCA --sd-id 0xB9 --softdevice ANT_s340_nrf52840_6.1.1.hex --key-file private.pem FW_Gateway_hv_fv_2_files.zip

Gives error 3: 

nrfutil pkg generate --application app.hex --application-version 1 --application-version-string "1.0.0" --hw-version 52 --sd-req 0xFFFE --sd-id 0xFFFE --softdevice ANT_s340_nrf52840_6.1.1.hex --key-file private.pem FW_Gateway_hv_fv_2_files.zip

Gives error 4: 

0xCA: because existing application based on s140

0xB9: because new application based on s340

0xfffe: tried any/wildcard softdevice version

In case of error 3, The nRFConnect PC application shows first half of upload complete (softdevice transfer to device is successful), but then as the app.hex transfer begins, application gives error 3.

Any help will be appreciated.

Thanks.

[mrono]

Aftab said:

The behavior is consistent and I cannot understand why it's successful first time but not the second time.

It always gives error on step#4, never has any issue on step #2

Version checking for bootloader updates is more strict than for application updates. The bootloader will reject attempts to update the bootloader itself unless the new bootloader has a higher version number than the currently installed bootloader.

This is normally not a problem, but is a real headache in your use case:

Aftab said:

My goal is that the end user should be able to switch b/w S140 and S340 based files any time.

I would change the version check in the bootloader to accept also bootloader updates with the same version. Otherwise you'd need to increment the version and recreate the DFU package every time the user wants to do this change.