Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Replacing s140 with s340 softdevice

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: 

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: 

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.

  • After the changes in the last step (where S340 based bootloader now shows DfuTarg and new firmware can be uploaded), I tried again.

    1. Uploaded device with S140 based softdevice+bootloader (aka merged_SD_bootloader.hex file). 

    2. Tried to upload S340 based new firmware, got this error:

  • I also tried to increase bootloader version number in the package generator command. Still the same.

  • Well I just succeeded in upgrading from S140 to S340. The key point here is that you device should be running modified BL+SD+APP (of S140) and now you can upgrade it with BL+SD+APP (of S340).

    Now I'm testing going back from S340 to S140. Will update this thread accordingly.

  • Now I'm trying to reverse change the SD and App. I.e, from S340 to S140.

    I created the BL+SD+APP for the S140, the same way as for S340 as explained in above posts.

    I am able to reverse the firmware from S340 to S140.

    So here is what I have achieved till now:

    1. I erase all firmware from a device + upload SD(S140)+BL. Then upload the firmware (APP) with same S140 settings.

    2. I am able change from the firmware with S140 (BLE only) to the firmware with S340 (BLE+ANT) -successful

    3. Change from the firmware with S340 (BLE+ANT) to the firmware with S140 (BLE only) - successful 

    4. Again, change from the firmware with S140 (BLE only) to the firmware with S340 (BLE+ANT) - FAILED

    Step#4 is where the problems arrives, here it gives following error:

    I repeated this many times but it stops at this step.

    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

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

    Thanks

  • Hi Aftab,

    Can you test with the debug bootloader (with RTT logging) and post the log here, so that we can hopefully understand a bit more about which check fails where?

    Also, please note that while I do not see any problems switching between SoftDevice types that is not directly supported nor something we test (which is why it is prevented by the default bootloader), so it is important that you test this properly.

Related