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

[Edvin]

Hello again,

A colleague of mine made me aware of a change that you would need to do in your bootloader.

The bootloader has a check:

    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;
    }

If this is present in your current bootloader, you would need to change this bit in the bootloader, perform a DFU with this bootloader update (image containing bootloader with fix and old softdevice), then you can update to the new softdevice using the method described above.

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