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.

[Edvin]

Hello,

I haven't really tried this myself with the ANT softdevices before, but when you change the softdevice, you should in general also update the bootloader. Perhaps this is why it doens't work in the first case. The bootloader denies the softdevice update because if it turns out having a bootloader and softdevice that doesn't match, then the device is possibly (probably) bricked. 

Try either generating a package including:

1: SD + BL

2: SD + BL + APP.

Either of them should work. If the softdevice S140 and S340 is the same version, then you can use the same bootloader as you are currently using when generating the packet. 

If you update using SD + BL, then it should start advertising as DfuTarg. If you include the APP, it will start the app. Note that when you generate a DFU image using SD + BL + APP, then this is actually split into two transfers. First SD + BL, and then the application at last.

So try generating an image using BL + SD, and let me know whether it is accepted or not.

Best regards,

Edvin

[Aftab]

Thanks for the reply.

Here is what I did and it's result.

1. I commented out the following lines from old bootloader (used with S140 softdevice) and generated the bootloader.hex. Copied it to my old project location where I generate hex file.

else if (SD_PRESENT && (SD_ID_GET(MBR_SIZE) != SD_ID_GET(sd_start_addr)))
{
    NRF_LOG_ERROR("The new SoftDevice is of a different family than the present SoftDevice. Compatibility cannot be guaranteed.");
    result = false;
}

2. Created new firmware zip file: modified bootloader+S140+APP and uploaded to my device

3. Copied the secure bootloader project in SDK 16 and renamed it secure_bootloader_s340 (just to be on safe end)

4. In the pre-processor settings of this project, changed line to following. 

NRF_SD_BLE_API_VERSION=6
S340

I'm using softdevice ANT_s340_nrf52840_6.1.1.hex for ANT. Previously these values were 7 and S140 respectively for old bootloader.

5. Generated the new bootloader, created two files

i. BL + SD

ii. BL + SD + APP

6. Tried to upload the file, in both cases I get following error message:

7. This time it's not about softdevice, it gives FW_VERSION_FAILURE, so I tried to increment --application-version from 1 to 2 in the package generator command, the issue still remains.

[Aftab]

Later I noticed that my device wouldn't come to bootloader mode (DfuTarg name) if I merge the new bootloader with software and simple flash it. This post helped me to correct the error, I had to change the headers in the include path from s140 to s340.

devzone.nordicsemi.com/.../ble-bootloader-example

I noticed that simple flash of bootloader+SD gives correct results (Can see DfuTarg and upload file).

Now heading towards main issue (Upgrading S140 based app to S340 based app).

[Edvin]

So what is the current FW version in your settings? Or perhaps it is the bootloader version that you need to increase.

If you are not sure, please try the debug version of the bootloader (pca10056_s140_ble_debug), and monitor the RTT log. Why was the image rejected?

BR,

Edvin

[Aftab]

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:

[Aftab]

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

[Aftab]

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.

[Aftab]

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

[Einar Thorsrud]

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.