downgrade from SDK 2.4.2 to SDK 1.9.1

RE: downgrade from SDK 2.4.2 to SDK 1.9.1

Leiser — Wed, 11 Oct 2023 14:42:37 GMT

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.

RE: downgrade from SDK 2.4.2 to SDK 1.9.1

Hung Bui — Wed, 11 Oct 2023 13:59:41 GMT

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.

RE: downgrade from SDK 2.4.2 to SDK 1.9.1

Leiser — Mon, 09 Oct 2023 15:45:16 GMT

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.

RE: downgrade from SDK 2.4.2 to SDK 1.9.1

Sigurd Hellesvik — Fri, 29 Sep 2023 14:08:11 GMT

Ah, that makes more sense then.

[quote user="Leiser"] How this CONFIG_LOG_BACKEND_FS works? [/quote]

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.

RE: downgrade from SDK 2.4.2 to SDK 1.9.1

Leiser — Thu, 28 Sep 2023 20:50:00 GMT

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.

RE: downgrade from SDK 2.4.2 to SDK 1.9.1

Sigurd Hellesvik — Thu, 28 Sep 2023 14:57:17 GMT

[quote user="Leiser"]I'm not using a customize board.[/quote]

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

RE: downgrade from SDK 2.4.2 to SDK 1.9.1

Leiser — Wed, 27 Sep 2023 17:50:22 GMT

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

RE: downgrade from SDK 2.4.2 to SDK 1.9.1

Sigurd Hellesvik — Tue, 26 Sep 2023 14:15:39 GMT

I think it is time to try to make logging work at this point.

Do you have the option to do serial logging from the device?

[quote user=""]After 4 days working in this issue I saw the MCU boot messages only twice.[/quote]

It is impractical, but I think you need to reset the RTT logger everytime you reboot the DK.

Alternatively, you can try to use CONFIG_LOG_BACKEND_FS, to write logs to a file, and then read it from the file later.

RE: downgrade from SDK 2.4.2 to SDK 1.9.1

Leiser — Thu, 21 Sep 2023 13:12:39 GMT

It did not fix. I had tried that before I had opened this ticket.

RE: downgrade from SDK 2.4.2 to SDK 1.9.1

Sigurd Hellesvik — Thu, 21 Sep 2023 13:07:41 GMT

[quote user="Leiser"]

I just try and now the child image partition from SDK 2.4.2 is not matching the child partition from SDK 1.9.2,

The b0n end address from SDK 1.9.1 build is 0x1008600 and build using SDK 2.4.2 the b0n and address is 0x1008580. This cause because the size is different 0x8600 and 0x8580 respectively.

[/quote]

Aha, try to force the same size for both, and see if that fixes this

RE: downgrade from SDK 2.4.2 to SDK 1.9.1

Leiser — Thu, 21 Sep 2023 12:56:46 GMT

I just try and now the child image partition from SDK 2.4.2 is not matching the child partition from SDK 1.9.2,

The b0n end address from SDK 1.9.1 build is 0x1008600 and build using SDK 2.4.2 the b0n and address is 0x1008580. This cause because the size is different 0x8600 and 0x8580 respectively.

The pm_static.yml, you described, will do the same for the nRF5340 app core. But right now, this is not my issue because the partition generated automatically by the partition manager match in both builds.

RE: downgrade from SDK 2.4.2 to SDK 1.9.1

Leiser — Thu, 21 Sep 2023 12:56:45 GMT

I just try and now the child image partition from SDK 2.4.2 is not matching the child partition from SDK 1.9.2,

The b0n end address from SDK 1.9.1 build is 0x1008600 and build using SDK 2.4.2 the b0n and address is 0x1008580. This cause because the size is different 0x8600 and 0x8580 respectively.

RE: downgrade from SDK 2.4.2 to SDK 1.9.1

Sigurd Hellesvik — Thu, 21 Sep 2023 12:48:33 GMT

[quote user="Leiser"]This is working because after I added it I saw the partitions_CPUNET.yml from the SDK 2.4.2 build is exactly the same the one generated by the SDK 1.9.1 build.[/quote]

Yea, that should be enough to check this then.
In this case, I do not think that static partitioning is the issue anymore.

I will look more into this tomorrow, to see if I can see any other things that may cause the issue.

[quote user="Leiser"]I will try what you wrote. I will let you know.[/quote]

I do not think this is necessary, as you were able to verify that the partitioning did not change.

RE: downgrade from SDK 2.4.2 to SDK 1.9.1

Leiser — Thu, 21 Sep 2023 12:13:18 GMT

As far I know for the net core (child image) the file does need to be named as pm_static.yml. The pm_static.yml must the name for the app core.

The pm.yml I got from the build using SDK1.9.1. I took the file generated for the child image by the partition manager. I copied the file from my SDK1.9.1 build, folder <SDK1.9.1 project root folder >\build\hci_rpmsg\partitions_CPUNET.yml, renamed it to pm.yml, copied to my SDK2.4.2 files on <SDK2.4.2 project root folder >child_image\pm.yml.

I changed the VS Code build file to include om the Extra CMake arguments the following:

-Dhci_rpmsg_PM_STATIC_YML_FILE:STRING="C:/nRF5340-samples/nrf5340/app_core/test/peripheral_hr_sdk2.4.2/child_image/pm.yml"

This is working because after I added it I saw the partitions_CPUNET.yml from the SDK 2.4.2 build is exactly the same the one generated by the SDK 1.9.1 build.

I will try what you wrote. I will let you know.

RE: downgrade from SDK 2.4.2 to SDK 1.9.1

Sigurd Hellesvik — Thu, 21 Sep 2023 07:47:21 GMT

That file is named pm.yml.

Did you rename this?

Can you explain where you get this file, and how you are using it?

I see that the file you send does not have static partitions for mcuboot, mcuboot_primary or mcuboot_secondary.
Can I suggest that you do this to do static partitioning?

First, build your application without static partitioning.
Copy project/build/partitions.yml --> project/pm_static.yml
1. Note: pm_static.yml will automatically be detected by the build system, due to its specific name
Copy project/pm_static.yml to both projects for v2.4.2 and v1.9.1
Rebuild both applications.
Flash first application.
Now try DFU

RE: downgrade from SDK 2.4.2 to SDK 1.9.1

Leiser — Wed, 20 Sep 2023 14:04:39 GMT

devzone.nordicsemi.com/.../pm.zip

Here the file I'm using.

RE: downgrade from SDK 2.4.2 to SDK 1.9.1

Sigurd Hellesvik — Wed, 20 Sep 2023 06:44:07 GMT

Can you upload the pm_static.yml you used now?

RE: downgrade from SDK 2.4.2 to SDK 1.9.1

Leiser — Tue, 19 Sep 2023 13:36:04 GMT

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.

RE: downgrade from SDK 2.4.2 to SDK 1.9.1

Sigurd Hellesvik — Mon, 18 Sep 2023 12:51:54 GMT

Hi,

Is your partitioning static between the updates?

Regards,
Sigurd Hellesvik