downgrade from SDK 2.4.2 to SDK 1.9.1

[Leiser]

We are working to updated the SDK to version 2.4.2 running on nRF5340 SoC. Current the firmware is working fine except when we tested to downgrade the firmware back with the firmware using SDK 1.9.1. After we OTA the firmware back, the netcore is not been downgrade to the firmware from SKD 1.9.1. The side effect is the BLE is not longer working.

The test steps are:

1 - Flask SDK 1.9.1 firmware using Jlink.

2 - OTA SDK 2.4.2 firmware.

3 - OTA SDK 1.9.1 firmware.

4 - OTA SDK 2.4.2 firmware.

The step 4 failed because the device is no longer sending BLE advertisement.

One of my colleges read the image and he saw that between the step 2 and 3 the netcore was not updated. Meaning, the netcode firmware on step 3 is the one built using SDK 2.4.2.

I tried to enable the MCU boot netcore logs, few times I saw the following message: E: Network core update failed.

The problem I'm facing to debug the problem is the logging via RTT almost never works. After 4 days working in this issue I saw the MCU boot messages only twice.

[Leiser]

Hi,

It was not at beginning, the bon size was smaller and the start address was the same. But, now I added static partition to make the partition with the same size for the child image and this change did not fix the problem.

[Sigurd Hellesvik]

Can you upload the pm_static.yml you used now?

[Leiser]

I'm not using a customize board. How this CONFIG_LOG_BACKEND_FS works? 

[Sigurd Hellesvik]

Leiser said:

I'm not using a customize board.

Then I suggest that you just log using UART  for the DK. (standard log over the USB)
That usually works well for me for bootloader logging

[Leiser]

Sorry, I made a mistake in my last message. I'm using a customize board with no UART available. I will see how can I debug this.

[Sigurd Hellesvik]

Ah, that makes more sense then.

Leiser said:

 How this CONFIG_LOG_BACKEND_FS works? 

This will save logs to a selected file system . Then you can read out the logs using whatever method you want.
Maybe the easiest is to use the SMP Server sample and its file system functionality. Our nRF Device Manager application for mobile also can read from file systems over SMP.

[Leiser]

My co-work made some test. And the preliminary result is pointing not to the SDK version but the use of Soft device instead of Zephyr controller. Our firmware with SDK 1.9.1 use Zephyr controller. When we updated to SDK 2.4.2, we starting using Soft device.

[Hung Bui]

Hi Leiser, 

Sigurd is away and I will take over the ticket in the mean time. 

So what happening here is that the controller has been updated from Zephyr controller in SDK v1.9.1 to Softdevice controller in v2.4.2 ? 
And when you try to revert it back it was not possible to downgrade ? 
I'm not so sure if it's actually feasible to downgrade the controller at all. There must be some logic need to be turned of to do so because it's normally not allowed to downgrade due to security reason. An attacker can try to downgrade the stack to exploit security holes in previous version of the stack. 

[Leiser]

We had informed we will not allow to downgrade the version using OTA after we had release the firmware using Softdevice controller and SDK 2.4.2. My company accepted that.

Thanks for the help.