nrf9160 always recovers when updating applications

RE: nrf9160 always recovers when updating applications

llly — Fri, 07 Jun 2024 03:05:52 GMT

Hi dejan,

I reinstalled NCS for testing, and everything went smoothly this time. If you are upgrading from app_update to SLM, you need to copy the pm_static.yml file of app_update to SLM to ensure that the partitions are the same. If you are upgrading from the old SLM to the new SLM, there is no need to adjust the partitions. Thank you for your help

RE: nrf9160 always recovers when updating applications

dejans — Thu, 06 Jun 2024 07:41:45 GMT

Hi,

[quote user="llly"]When I have time, I will download NCS again to ensure that there are no issues with the SLM itself, and then see if I can find any more clues[/quote]

Fresh installation of NCS might help. You can follow NCS installation guide.

Best regards,
Dejan

RE: nrf9160 always recovers when updating applications

llly — Wed, 05 Jun 2024 07:01:24 GMT

I was just starting to learn about 9160 and have been using version 2.6.1 since the beginning

RE: nrf9160 always recovers when updating applications

JyriLehtinen — Wed, 05 Jun 2024 06:59:43 GMT

By the way, are the samples from the same SDK version as you're currently using? For example, you initially generated them with v2.5.0 and have now switched to v2.6.1? Sometimes the libraries have changed and require updates in the source code.

RE: nrf9160 always recovers when updating applications

llly — Wed, 05 Jun 2024 06:56:24 GMT

Thank you for your testing. When I have time, I will download NCS again to ensure that there are no issues with the SLM itself, and then see if I can find any more clues

RE: nrf9160 always recovers when updating applications

JyriLehtinen — Wed, 05 Jun 2024 06:44:42 GMT

I just tested opening a fresh serial_lte_modem and application_update examples (SDK 2.6.1), and generated the build configurations for nRF9160-dk.

I copied the the partitions.yml from application_update as pm_static.yml for the slm and did a pristine build. No errors. Below is my pm_static.yml. Seems to be identical to yours, though at lines 36-38 the order is different (Windows and Linux output the items in different orders, but i don't think it matters, compiles with both).

EMPTY_0:
  address: 0xc000
  end_address: 0x10000
  placement:
    before:
    - mcuboot_pad
  region: flash_primary
  size: 0x4000
app:
  address: 0x18000
  end_address: 0x88000
  region: flash_primary
  size: 0x70000
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0x10000
  end_address: 0x10200
  placement:
    align:
      start: 0x8000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0x10000
  end_address: 0x88000
  orig_span: &id001
  - tfm
  - app
  - mcuboot_pad
  region: flash_primary
  sharers: 0x1
  size: 0x78000
  span: *id001
mcuboot_primary_app:
  address: 0x10200
  end_address: 0x88000
  orig_span: &id002
  - app
  - tfm
  region: flash_primary
  size: 0x77e00
  span: *id002
mcuboot_secondary:
  address: 0x88000
  end_address: 0x100000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x8000
    align_next: 0x8000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x78000
mcuboot_sram:
  address: 0x20000000
  end_address: 0x20008000
  orig_span: &id003
  - tfm_sram
  region: sram_primary
  size: 0x8000
  span: *id003
nrf_modem_lib_ctrl:
  address: 0x20008000
  end_address: 0x200084e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - tfm_sram
    - start
  region: sram_primary
  size: 0x4e8
nrf_modem_lib_rx:
  address: 0x2000a568
  end_address: 0x2000c568
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_tx
  region: sram_primary
  size: 0x2000
nrf_modem_lib_sram:
  address: 0x20008000
  end_address: 0x2000c568
  orig_span: &id004
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x4568
  span: *id004
nrf_modem_lib_tx:
  address: 0x200084e8
  end_address: 0x2000a568
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_ctrl
  region: sram_primary
  size: 0x2080
otp:
  address: 0xff8108
  end_address: 0xff83fc
  region: otp
  size: 0x2f4
sram_nonsecure:
  address: 0x20008000
  end_address: 0x20040000
  orig_span: &id005
  - sram_primary
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x38000
  span: *id005
sram_primary:
  address: 0x2000c568
  end_address: 0x20040000
  region: sram_primary
  size: 0x33a98
sram_secure:
  address: 0x20000000
  end_address: 0x20008000
  orig_span: &id006
  - tfm_sram
  region: sram_primary
  size: 0x8000
  span: *id006
tfm:
  address: 0x10200
  end_address: 0x18000
  inside:
  - mcuboot_primary_app
  placement:
    before:
    - app
  region: flash_primary
  size: 0x7e00
tfm_nonsecure:
  address: 0x18000
  end_address: 0x88000
  orig_span: &id007
  - app
  region: flash_primary
  size: 0x70000
  span: *id007
tfm_secure:
  address: 0x10000
  end_address: 0x18000
  orig_span: &id008
  - mcuboot_pad
  - tfm
  region: flash_primary
  size: 0x8000
  span: *id008
tfm_sram:
  address: 0x20000000
  end_address: 0x20008000
  inside:
  - sram_secure
  placement:
    after:
    - start
  region: sram_primary
  size: 0x8000

So your error runs deeper than pm_static, there's something strange with your build process. I noticed some weird stuff while fiddling with the lwm2m_client example, Windows-built binaries had something messed up with the flash maps, the example, mcuboot complained that imagemagic was bad and application failed at "boot_write_img_confirmed()" with IO error (-5). The same source file, SDK version and build configuration worked fine on Linux.

At some point it started working again on windows though I don't know why, the generated .config and partition.yml files were identical.

I'm unable to replicate it anymore so it's hard to say at this point.

RE: nrf9160 always recovers when updating applications

llly — Wed, 05 Jun 2024 06:09:12 GMT

Sorry, I will pay attention to these details in the future.devzone.nordicsemi.com/.../1614.pm_5F00_static.yml.txt

This is what I copied directly from the app_update sample without any changes. Can you help me check if there are any issues? Thank you.

RE: nrf9160 always recovers when updating applications

JyriLehtinen — Wed, 05 Jun 2024 05:49:47 GMT

(By the way, you can use the formatting tools in your posts to help the reader. For example, the build output could have been a code block)

Based on the output, the build fails at the partition_manager.py. The magic line is

Partition manager failed: End of last partition is after last valid address
Failed to partition region sram_primary, size of region: 262144

The error is most likely in your pm_static.yml.
Actually, you might as well share the file here, wouldn't hurt.

RE: nrf9160 always recovers when updating applications

llly — Wed, 05 Jun 2024 01:32:57 GMT

This is about the error message after using pm_static.yml

-- Found partition manager static configuration: F:/nrf9160_app/serial_lte_modem/pm_static.yml
Partition 'mcuboot' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_pad' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_primary' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_primary_app' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_secondary' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_sram' is not included in the dynamic resolving since it is statically defined.
Partition 'nrf_modem_lib_ctrl' is not included in the dynamic resolving since it is statically defined.
Partition 'nrf_modem_lib_rx' is not included in the dynamic resolving since it is statically defined.
Partition 'nrf_modem_lib_sram' is not included in the dynamic resolving since it is statically defined.
Partition 'nrf_modem_lib_tx' is not included in the dynamic resolving since it is statically defined.
Partition 'sram_nonsecure' is not included in the dynamic resolving since it is statically defined.
Partition 'sram_secure' is not included in the dynamic resolving since it is statically defined.
Partition 'tfm' is not included in the dynamic resolving since it is statically defined.
Partition 'tfm_nonsecure' is not included in the dynamic resolving since it is statically defined.
Partition 'tfm_secure' is not included in the dynamic resolving since it is statically defined.
Partition 'tfm_sram' is not included in the dynamic resolving since it is statically defined.
Partition manager failed: End of last partition is after last valid address
Failed to partition region sram_primary, size of region: 262144
Partition Configuration:
mcuboot_sram:
size: 32768
nrf_modem_lib_ctrl:
placement:
after:
- tfm_sram
- start
size: 1256
nrf_modem_lib_rx:
placement:
after:
- nrf_modem_lib_tx
size: 8192
nrf_modem_lib_sram:
size: 17768
nrf_modem_lib_trace:
placement: {}
size: 16384
nrf_modem_lib_tx:
placement:
after:
- nrf_modem_lib_ctrl
size: 8320
sram_nonsecure:
size: 229376
sram_primary:
size: 211608
sram_secure:
size: 32768
tfm_sram:
placement:
after:
- start
size: 32768

CMake Error at F:/nordic/ncs_v2.6.1/nrf/cmake/partition_manager.cmake:331 (message):
Partition Manager failed, aborting. Command:
C:/ncs/toolchains/cf2149caf2/opt/bin/python.exe;F:/nordic/ncs_v2.6.1/nrf/scripts/partition_manager.py;--input-files;F:/nrf9160_app/serial_lte_modem/build/mcuboot/zephyr/include/generated/pm.yml;F:/nrf9160_app/serial_lte_modem/build/zephyr/include/generated/pm.yml;F:/nrf9160_app/serial_lte_modem/build/modules/nrf/subsys/partition_manager/pm.yml.settings;F:/nrf9160_app/serial_lte_modem/build/modules/nrf/subsys/partition_manager/pm.yml.libmodem;F:/nrf9160_app/serial_lte_modem/build/modules/nrf/subsys/partition_manager/pm.yml.tfm;F:/nrf9160_app/serial_lte_modem/build/modules/nrf/subsys/partition_manager/pm.yml.trustzone;F:/nrf9160_app/serial_lte_modem/build/modules/nrf/subsys/partition_manager/pm.yml.mcuboot;--regions;sram_primary;otp;flash_primary;--output-partitions;F:/nrf9160_app/serial_lte_modem/build/partitions.yml;--output-regions;F:/nrf9160_app/serial_lte_modem/build/regions.yml;--static-config;F:/nrf9160_app/serial_lte_modem/pm_static.yml;--sram_primary-size;0x40000;--sram_primary-base-address;0x20000000;--sram_primary-placement-strategy;complex;--sram_primary-dynamic-partition;sram_primary;--otp-size;756;--otp-base-address;0xff8108;--otp-placement-strategy;start_to_end;--flash_primary-size;0x100000;--flash_primary-base-address;0x0;--flash_primary-placement-strategy;complex;--flash_primary-device;flash_controller;--flash_primary-default-driver-kconfig;CONFIG_SOC_FLASH_NRF
Call Stack (most recent call first):
F:/nordic/ncs_v2.6.1/zephyr/cmake/modules/kernel.cmake:248 (include)
F:/nordic/ncs_v2.6.1/zephyr/cmake/modules/zephyr_default.cmake:138 (include)
F:/nordic/ncs_v2.6.1/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:66 (include)
F:/nordic/ncs_v2.6.1/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:97 (include_boilerplate)
CMakeLists.txt:9 (find_package)

-- Configuring incomplete, errors occurred!
See also "F:/nrf9160_app/serial_lte_modem/build/CMakeFiles/CMakeOutput.log".
See also "F:/nrf9160_app/serial_lte_modem/build/CMakeFiles/CMakeError.log".
FAILED: build.ninja
C:\ncs\toolchains\cf2149caf2\opt\bin\cmake.exe --regenerate-during-build -SF:\nrf9160_app\serial_lte_modem -BF:\nrf9160_app\serial_lte_modem\build
ninja: error: rebuilding 'build.ninja': subcommand failed
FATAL ERROR: command exited with status 1: 'C:\ncs\toolchains\cf2149caf2\opt\bin\cmake.EXE' --build 'f:\nrf9160_app\serial_lte_modem\build'

This is the content in CMakeError. log

Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: C:/ncs/toolchains/cf2149caf2/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc.exe
Build flags:
Id flags:

The output was:
1
c:/ncs/toolchains/cf2149caf2/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.exe: c:/ncs/toolchains/cf2149caf2/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/lib\libc.a(lib_a-exit.o): in function `exit':
exit.c:(.text.exit+0x34): undefined reference to `_exit'
collect2.exe: error: ld returned 1 exit status

Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" failed.
Compiler: C:/ncs/toolchains/cf2149caf2/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc.exe
Build flags:
Id flags:

This is the content in CMakeOutput.log

The target system is: Generic - 3.5.99 - arm
The host system is: Windows - 10.0.19045 - AMD64
Compiling the C compiler identification source file "CMakeCCompilerId.c" succeeded.
Compiler: C:/ncs/toolchains/cf2149caf2/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc.exe
Build flags:
Id flags: -c

The output was:
0

Compilation of the C compiler identification source "CMakeCCompilerId.c" produced "CMakeCCompilerId.o"

The C compiler identification is GNU, found in "F:/nrf9160_app/serial_lte_modem/build/CMakeFiles/3.21.0/CompilerIdC/CMakeCCompilerId.o"

Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" succeeded.
Compiler: C:/ncs/toolchains/cf2149caf2/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc.exe
Build flags:
Id flags: -c

The output was:
0

Compilation of the CXX compiler identification source "CMakeCXXCompilerId.cpp" produced "CMakeCXXCompilerId.o"

The CXX compiler identification is GNU, found in "F:/nrf9160_app/serial_lte_modem/build/CMakeFiles/3.21.0/CompilerIdCXX/CMakeCXXCompilerId.o"

Checking whether the ASM compiler is GNU using "--version" matched "(GNU assembler)|(GCC)|(Free Software Foundation)":
arm-zephyr-eabi-gcc.exe (Zephyr SDK 0.16.5) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I don't know if these are helpful in solving this problem?

RE: nrf9160 always recovers when updating applications

llly — Wed, 05 Jun 2024 01:26:32 GMT

Thank you for your wishes.The method of porting code was not very successful. It was able to download the firmware normally and prompted to restart to apply the new firmware after the download was completed. The first startup after the restart was much slower than normal, which should be when the new firmware was applied, but it was still running the old firmware after startup.I will continue to study this in the future.

RE: nrf9160 always recovers when updating applications

dejans — Tue, 04 Jun 2024 12:58:54 GMT

Hi,

[quote user="llly"]I am now trying to directly port the code of app_update to SLM, so that there is no need to update from app_update to SLM, which can probably avoid partition issues[/quote]

I hope that you will be successful. When you are done, please provide an update.

[quote user="llly"]hank you for your help. I also think it's a partition issue, but I'm still researching how to adjust it. I tried to copy the content of app_update/build/partitions.yml to slm/pm_static.yml using JyriLehtinen's method, and added set(PM_STATIC_YML_FILE ${CMAKE_CURRENT_LIST_DIR}/pm_static.yml CACHE INTERNAL "") to the SLM project CMakeLists.txt, but there was an error during the build process[/quote]

To examine this, we would need build log.

Best regards,
Dejan

RE: nrf9160 always recovers when updating applications

llly — Mon, 03 Jun 2024 01:33:54 GMT

hi JyriLehtinen

Thank you for your reply. I tried according to your method, but there was an error during the build.

I am now trying to directly port the code of app_update to SLM, so that there is no need to update from app_update to SLM, which can probably avoid partition issues

RE: nrf9160 always recovers when updating applications

llly — Mon, 03 Jun 2024 01:23:41 GMT

hi dejans

Thank you for your help. I also think it's a partition issue, but I'm still researching how to adjust it. I tried to copy the content of app_update/build/partitions.yml to slm/pm_static.yml using JyriLehtinen's method, and added set(PM_STATIC_YML_FILE ${CMAKE_CURRENT_LIST_DIR}/pm_static.yml CACHE INTERNAL "") to the SLM project CMakeLists.txt, but there was an error during the build process

RE: nrf9160 always recovers when updating applications

dejans — Fri, 31 May 2024 07:57:52 GMT

Hi llly ,

Static partitioning is commonly used to ensure consistency between builds. You can read about configuring static partitions in the partition manager documentation.

Best regards,
Dejan

RE: nrf9160 always recovers when updating applications

JyriLehtinen — Fri, 31 May 2024 06:13:09 GMT

Well, the easiest solution might be to copy the generated partition file from the project which is originally flashed to the board (in your case, app_update/build/partitions.yml copied to slm/pm_static.yml, then add the following line to the SLM project CMakeLists.txt:

set(PM_STATIC_YML_FILE ${CMAKE_CURRENT_LIST_DIR}/pm_static.yml CACHE INTERNAL "")

Might not compile, but it's quick to try.

I'm not 100 % certain, but I think the main issue there is the mcuboot_primary/secondary, which need to have identical addresses and sizes (there's a trailer with mcuboot data in the end of the flash), but I'd say it's risky having mismatched storage etc.
I think West warns about multi-image builds without a static partition file, and this is why. In the worst case, you can brick devices by doing app updates, which end up editing critical data in the flash, in an unrecoverable manner.

RE: nrf9160 always recovers when updating applications

llly — Fri, 31 May 2024 01:55:20 GMT

Are you referring to the differences here? If so, how should we modify the definition of this section？

RE: nrf9160 always recovers when updating applications

JyriLehtinen — Thu, 30 May 2024 13:38:39 GMT

The SLM-application is most likely built with a different partition table, as I assume you're not using same pm_static.yml (at least for the relevant parts).

Updating the application does not update the bootloader, so the bootloader in your DK is built with the partitions defined in your application_update build. This defines which address the bootloader will check when determining whether to revert the image or not.
Now, your SLM build probably has a different partition table, so when you call boot_writd_img_confirmed() it writes to a different address, defined by your partition table in that build.