• State Not Answered
  • Replies 19 replies
  • Subscribers 86 subscribers
  • Views 2957 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 314696
Options

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.

Parents
  • 0

    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.

  • 0 in reply to Leiser

    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?

    1. First, build your application without static partitioning.
    2. 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
    3. Copy project/pm_static.yml to both projects for v2.4.2 and v1.9.1
    4. Rebuild both applications.
    5. Flash first application.
    6. Now try DFU
  • 0 in reply to Sigurd Hellesvik

    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.

  • 0 in reply to Leiser
    Leiser said:
    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.

    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.

    Leiser said:
    I will try what you wrote. I will let you know.

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

Reply
  • 0 in reply to Leiser
    Leiser said:
    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.

    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.

    Leiser said:
    I will try what you wrote. I will let you know.

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

Children
Related
Terms of service