Hello_world and other samples do not build properly for thingy53_NRF5340_cpuapp_ns

RE: Hello_world and other samples do not build properly for thingy53_NRF5340_cpuapp_ns

Menon — Thu, 22 Feb 2024 10:00:32 GMT

Hello,

Your issue looks a bit different.

Since my colleague is working on your issue, I recommend you follow the discussion there.

Follow the devzone thread:https://devzone.nordicsemi.com/support-private/support/322519

Kind Regards,

Abhijith

RE: Hello_world and other samples do not build properly for thingy53_NRF5340_cpuapp_ns

nickdr — Wed, 21 Feb 2024 18:33:09 GMT

I am having the same issue. Tried both blinky LED and hello world examples and I never get to the break point set on the first line in the main function. I am using a NORA-B126 (nrf5340) module. Here is a screenshot of where it stops. I have "Optimize for debugging (-Og) set as the optimization level. I am building an Non Secure app. Any help would be appreciated.

RE: Hello_world and other samples do not build properly for thingy53_NRF5340_cpuapp_ns

Menon — Tue, 29 Aug 2023 09:43:43 GMT

Hello,

[quote user="Trento"]Does it mean that my Thingy53s are damaged now?[/quote]

I don't think this will break your device. Try to program your device with a precompiled file that comes with thingy_firmware. See the sections on updating through BLE and updating through USB.

Kind Regards,

Abhijith

RE: Hello_world and other samples do not build properly for thingy53_NRF5340_cpuapp_ns

Trento — Mon, 28 Aug 2023 14:19:21 GMT

Hi Abhijith,

thanks for your reply. Unfortunately, I did not pay attention to that.

Does it mean that my Thingy53s are damaged now?

RE: Hello_world and other samples do not build properly for thingy53_NRF5340_cpuapp_ns

Menon — Mon, 28 Aug 2023 11:16:35 GMT

Hello,

[quote user="Trento"]As external debuggers, I used nRF52840DK and nRF52833DK. Is there any way for a factory reset?[/quote]

For thingy53, you need to use an external debugger that supports Arm cortex-M33; see here. You can use nRF5340dk, but the DKs you mentioned cannot be used as an external debugger for thingy53.

Kind Regards,

Abhijith

RE: Hello_world and other samples do not build properly for thingy53_NRF5340_cpuapp_ns

Trento — Sun, 27 Aug 2023 10:00:56 GMT

Hi everyone,

I am encountering the same error when trying to debug all my three Thingy53. They worked off-the-shelf and I managed to flash the blinky example a couple of times into all of them but then suddenly they stopped working properly. Now, even the blinky example does not work. The flashing process completes (via external debugger and USB) but has no effect. When I try to debug, it gives me the issue with fih_panic_loop. I am using Visual Studio Code on Windows 10, but I also tried Ubuntu, and the problem is the same. As external debuggers, I used nRF52840DK and nRF52833DK. Is there any way for a factory reset?

RE: Hello_world and other samples do not build properly for thingy53_NRF5340_cpuapp_ns

henning larsen — Wed, 16 Aug 2023 12:32:22 GMT

hi,

Thanks, good to know.

I would think it is important that hello_world demos work without any hick-ups. For my part I have found a workaround.

br henning

RE: Hello_world and other samples do not build properly for thingy53_NRF5340_cpuapp_ns

Menon — Wed, 16 Aug 2023 12:23:16 GMT

Hello,

Yes, I tried this here and was able to produce the same error you are getting.

It looks a bit strange to me. I think it is because the bootloader is crashing while setting the breakpoint. But I am not sure of the root cause. So I will discuss this with my colleague and try to ask this internally.

Kind Regards,

Abhijith

RE: Hello_world and other samples do not build properly for thingy53_NRF5340_cpuapp_ns

henning larsen — Sat, 12 Aug 2023 16:00:43 GMT

hello,

I created the target with the debug option on and off and the problem does not differ in those two targets. When debugging - it does not run, but loops into the fih_panic loop and apparently never goes though main.

Can you please just try the same on your side and tell me if the application runs or not.

RE: Hello_world and other samples do not build properly for thingy53_NRF5340_cpuapp_ns

Menon — Fri, 11 Aug 2023 11:23:31 GMT

Hello,

Sorry for the long response time. I was sick for a few days.

Are you enabling the enable debug option in the build configuration? See a similar old thread. Kindly go through the debug optimisation section provided in the thread.

Can you please check this and update me? If it's still breaking, I will try it here.

Kind Regards,

Abhijith

RE: Hello_world and other samples do not build properly for thingy53_NRF5340_cpuapp_ns

henning larsen — Wed, 09 Aug 2023 15:20:40 GMT

I really would appreciate to know at least this:

Does the hello_world demo application built for the Thingy53_NRF5340_cpuapp_ns as target run and debug out of the box?

I can't get it to work.

RE: Hello_world and other samples do not build properly for thingy53_NRF5340_cpuapp_ns

henning larsen — Tue, 08 Aug 2023 20:00:56 GMT

Hello,

I have still not been able to launch a succesful debug session with the Thingy53_NRF5340_cpuapp_ns as target for app hello_world. It builds but it fails to debug or run!

You wrote that it builds for you but can you also debug the code - set a breakpoint in main and it stops execution there? This does not work here. Here it enters the panic loop.

What _does work_ is build hello_world with target set to nrf5340dk_nrf5340_cpuapp_ns. But using the thingy53 board as actual target - = the same board as the failing case.

This means that the hardware is working and at least some part of the procedure I take is right.

Below are images of the VS code window when nrf5340dk_nrf5340_cpuapp_ns is the target followed by the similar window when switched to the other target Thingy53_NRF5340_cpuapp_ns. I.e. the hello_world application is set to have two targets but in this case same physical hardware.

I notice one peculiar thing - the layout of the build_XX folder display (see below images) is different in the two different target builds - is this to expect?

Why is is different and what causes this?

Do you see the same difference? At least the debugging works different here.

Any idea why the hello_world/Thingy53_NRF5340_cpuapp_ns does not run here?

henning

Summary:

a) hello_world with build target=Thingy53_NRF5340_cpuapp_ns on Thingy53 HW --- Does build but not debug/run

b) hello_world with build target=nrf5340dk_nrf5340_cpuapp_ns on Thingy53 HW --- Does build and run.

VS code window when nrf5340dk_nrf5340_cpuapp_ns is the target:

And here is the similar window when switched to the other target Thingy53_NRF5340_cpuapp_ns

RE: Hello_world and other samples do not build properly for thingy53_NRF5340_cpuapp_ns

henning larsen — Mon, 07 Aug 2023 15:10:38 GMT

Hello,

Ok now I have from inside the nRF connect for desktop v4.1.2/ toolchain manager (TCM) v1.2.5 removed sdk 2.4.0, v2.4.1.

Reinstalled from inside TCM sdk 2.4.0.

Checked the voltage on the board (VOUTB=3.0V)

Inside VS Code Build a hello_world app with target thingy53_nrf5340_cpuapp_ns with debug enabled.

Added a breakpoint in the main.c code.

Started debug: It downloads and verifies apparently correct.

Then same as before never enters the main code but loops in fih_panic_loop()

with this call stack and DEBUG CONSOLE listed below.

I really hope you have an idea what can be wrong.

In theory it can be a broken board and I can get hold of another. But I am not optimistic on that.

Br henning

And this DEBUG CONSOLE:

JLinkGDBServerCL: SEGGER J-Link GDB Server V7.90 Command Line Version
JLinkGDBServerCL:
JLinkGDBServerCL: JLinkARM.dll V7.90 (DLL compiled Aug 2 2023 15:24:12)
JLinkGDBServerCL:
JLinkGDBServerCL: -----GDB Server start settings-----
JLinkGDBServerCL: GDBInit file: none
JLinkGDBServerCL: GDB Server Listening port: 63307
JLinkGDBServerCL: SWO raw output listening port: 2332
JLinkGDBServerCL: Terminal I/O port: 2333
JLinkGDBServerCL: Accept remote connection: localhost only
JLinkGDBServerCL: Generate logfile: off
JLinkGDBServerCL: Verify download: off
JLinkGDBServerCL: Init regs on start: off
JLinkGDBServerCL: Silent mode: on
JLinkGDBServerCL: Single run mode: on
JLinkGDBServerCL: Target connection timeout: 0 ms
JLinkGDBServerCL: ------J-Link related settings------
JLinkGDBServerCL: J-Link Host interface: USB
JLinkGDBServerCL: J-Link script: none
JLinkGDBServerCL: J-Link settings file: none
JLinkGDBServerCL: ------Target related settings------
JLinkGDBServerCL: Target device: nRF5340_xxAA_APP
JLinkGDBServerCL: Target device parameters: none
JLinkGDBServerCL: Target interface: SWD
JLinkGDBServerCL: Target interface speed: 12000kHz
JLinkGDBServerCL: Target endian: little
JLinkGDBServerCL:
=thread-group-added,id="i1"
=cmd-param-changed,param="pagination",value="off"
fih_panic_loop () at C:/ncs/v2.4.0/bootloader/mcuboot/boot/bootutil/src/fault_injection_hardening.c:68
68 __asm volatile ("b fih_panic_loop");
[New Remote target]

Thread 2 received signal SIGTRAP, Trace/breakpoint trap.
fih_panic_loop () at C:/ncs/v2.4.0/bootloader/mcuboot/boot/bootutil/src/fault_injection_hardening.c:68
68 __asm volatile ("b fih_panic_loop");
Execute debugger commands using "-exec <command>", for example "-exec info registers" will list registers in use (when GDB is the debugger)

RE: Hello_world and other samples do not build properly for thingy53_NRF5340_cpuapp_ns

henning larsen — Mon, 07 Aug 2023 12:10:33 GMT

Hello,

Thanks for your answer.

I installed sdk according to the recommendations using the tool for that. And I have tried two different pc's with same result.

I have built as you suggest using bash terminal and it builds but with a number of warnings. Actually it also builds in VS code. But does not execute. (note 1#)

I realize that the messages I describe above are warnings, despite they appear quite substantial like

"No SOURCES given to Zephyr library: lib__libc__common"

I also note that the "PROBLEMS" listing holds different warnings compared to the bash build - or do I have to open a logfile to see those when using west directly?

Anyway, this warning issue may be an insignificant thing, but when I debug in VS code it never enters the main program but gets stuck inside the fih_panic_loop inside the file "fault_injection_hardening.c"

I have built in VS code using debug enabled. So should that not just allow me to put a breakpoint in the main.c code and halt on that? It does not work.

You say that you tested the code with v2.4.0 so I am curious do you also get a similar list of warnings and does the debugging work?

thanks for your support. It is really a struggle to get this off the ground.

Br henning

Note 2#

inside VS code, inside "fault_injection_hardening.c" (which opens when pausing the debug session) the line
#include "bootutil/fault_injection_hardening.h"

has: #include errors detected based on information provided by the configuration Provider setting. Squiggles are disabled for this translation unit. cannot open source file "bootutil/fault_injection_hardening.h"C/C++(1696)

should that be a concern? Certainly looks like missing paths.

(Note 1#) My reasoning: The debug did not produce running code, as described, so I assumed the warnings which only manifest as errors at runtime and the reason for the broken debug code.

------------------------------------ bash build console dump ----

he@D MINGW64 ~/Documents/nRF/hello_world_thing (master)
$ west build -b thingy53_nrf5340_cpuapp_ns
-- west build: generating a build system
Loading Zephyr default modules (Zephyr base).
-- Application: C:/Users/he/Documents/nRF/hello_world_thing
-- CMake version: 3.20.5
-- Using NCS Toolchain 2.4.0 for building. (C:/ncs/toolchains/31f4403e35/cmake)
-- Found Python3: C:/ncs/toolchains/31f4403e35/opt/bin/python.exe (found suitable exact version "3.8.2") found components: Interpreter
-- Cache files will be written to: C:/ncs/v2.4.1/zephyr/.cache
-- Zephyr version: 3.3.99 (C:/ncs/v2.4.1/zephyr)
-- Found west (found suitable version "1.0.0", minimum required is "0.7.1")
-- Board: thingy53_nrf5340_cpuapp_ns
-- Found host-tools: zephyr 0.16.0 (C:/ncs/toolchains/31f4403e35/opt/zephyr-sdk)
-- Found toolchain: zephyr 0.16.0 (C:/ncs/toolchains/31f4403e35/opt/zephyr-sdk)
-- Found Dtc: C:/ncs/toolchains/31f4403e35/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
-- Found BOARD.dts: C:/ncs/v2.4.1/zephyr/boards/arm/thingy53_nrf5340/thingy53_nrf5340_cpuapp_ns.dts
-- Generated zephyr.dts: C:/Users/he/Documents/nRF/hello_world_thing/build/zephyr/zephyr.dts
-- Generated devicetree_generated.h: C:/Users/he/Documents/nRF/hello_world_thing/build/zephyr/include/generated/devicetree_generated.h
-- Including generated dts.cmake file: C:/Users/he/Documents/nRF/hello_world_thing/build/zephyr/dts.cmake
Parsing C:/ncs/v2.4.1/zephyr/Kconfig
Loaded configuration 'C:/ncs/v2.4.1/zephyr/boards/arm/thingy53_nrf5340/thingy53_nrf5340_cpuapp_ns_defconfig'
Merged configuration 'C:/Users/he/Documents/nRF/hello_world_thing/prj.conf'
Configuration saved to 'C:/Users/he/Documents/nRF/hello_world_thing/build/zephyr/.config'
Kconfig header saved to 'C:/Users/he/Documents/nRF/hello_world_thing/build/zephyr/include/generated/autoconf.h'
-- Found GnuLd: c:/ncs/toolchains/31f4403e35/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe (found version "2.38")
-- The C compiler identification is GNU 12.2.0
-- The CXX compiler identification is GNU 12.2.0
-- The ASM compiler identification is GNU
-- Found assembler: C:/ncs/toolchains/31f4403e35/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc.exe

=== child image empty_net_core - CPUNET begin ===
loading initial cache file C:/Users/he/Documents/nRF/hello_world_thing/build/empty_net_core/child_image_preload.cmake
Loading Zephyr default modules (Zephyr base (cached)).
-- Application: C:/ncs/v2.4.1/nrf/samples/nrf5340/empty_net_core
-- CMake version: 3.20.5
-- Cache files will be written to: C:/ncs/v2.4.1/zephyr/.cache
-- Zephyr version: 3.3.99 (C:/ncs/v2.4.1/zephyr)
-- Found west (found suitable version "1.0.0", minimum required is "0.7.1")
-- Board: thingy53_nrf5340_cpunet
-- Found host-tools: zephyr 0.16.0 (C:/ncs/toolchains/31f4403e35/opt/zephyr-sdk)
-- Found toolchain: zephyr 0.16.0 (C:/ncs/toolchains/31f4403e35/opt/zephyr-sdk)
-- Found BOARD.dts: C:/ncs/v2.4.1/zephyr/boards/arm/thingy53_nrf5340/thingy53_nrf5340_cpunet.dts
-- Generated zephyr.dts: C:/Users/he/Documents/nRF/hello_world_thing/build/empty_net_core/zephyr/zephyr.dts
-- Generated devicetree_generated.h: C:/Users/he/Documents/nRF/hello_world_thing/build/empty_net_core/zephyr/include/generated/devicetree_generated.h
-- Including generated dts.cmake file: C:/Users/he/Documents/nRF/hello_world_thing/build/empty_net_core/zephyr/dts.cmake
Parsing C:/ncs/v2.4.1/zephyr/Kconfig
Loaded configuration 'C:/Users/he/Documents/nRF/hello_world_thing/build/empty_net_core/zephyr/.config'
No change to configuration in 'C:/Users/he/Documents/nRF/hello_world_thing/build/empty_net_core/zephyr/.config'
No change to Kconfig header in 'C:/Users/he/Documents/nRF/hello_world_thing/build/empty_net_core/zephyr/include/generated/autoconf.h'

=== child image b0n - CPUNET (inherited) begin ===
loading initial cache file C:/Users/he/Documents/nRF/hello_world_thing/build/empty_net_core/b0n/child_image_preload.cmake
Loading Zephyr default modules (Zephyr base (cached)).
-- Application: C:/ncs/v2.4.1/nrf/samples/nrf5340/netboot
-- CMake version: 3.20.5
-- Cache files will be written to: C:/ncs/v2.4.1/zephyr/.cache
-- Zephyr version: 3.3.99 (C:/ncs/v2.4.1/zephyr)
-- Found west (found suitable version "1.0.0", minimum required is "0.7.1")
-- Board: thingy53_nrf5340_cpunet
-- Found host-tools: zephyr 0.16.0 (C:/ncs/toolchains/31f4403e35/opt/zephyr-sdk)
-- Found toolchain: zephyr 0.16.0 (C:/ncs/toolchains/31f4403e35/opt/zephyr-sdk)
-- Found BOARD.dts: C:/ncs/v2.4.1/zephyr/boards/arm/thingy53_nrf5340/thingy53_nrf5340_cpunet.dts
-- Generated zephyr.dts: C:/Users/he/Documents/nRF/hello_world_thing/build/empty_net_core/b0n/zephyr/zephyr.dts
-- Generated devicetree_generated.h: C:/Users/he/Documents/nRF/hello_world_thing/build/empty_net_core/b0n/zephyr/include/generated/devicetree_generated.h
-- Including generated dts.cmake file: C:/Users/he/Documents/nRF/hello_world_thing/build/empty_net_core/b0n/zephyr/dts.cmake
Parsing C:/ncs/v2.4.1/nrf/samples/nrf5340/netboot/Kconfig
Loaded configuration 'C:/Users/he/Documents/nRF/hello_world_thing/build/empty_net_core/b0n/zephyr/.config'
No change to configuration in 'C:/Users/he/Documents/nRF/hello_world_thing/build/empty_net_core/b0n/zephyr/.config'
No change to Kconfig header in 'C:/Users/he/Documents/nRF/hello_world_thing/build/empty_net_core/b0n/zephyr/include/generated/autoconf.h'
CMake Warning at C:/ncs/v2.4.1/zephyr/CMakeLists.txt:839 (message):
No SOURCES given to Zephyr library: lib__libc__common

Excluding target from build.

CMake Warning at C:/ncs/v2.4.1/zephyr/CMakeLists.txt:1865 (message):
__ASSERT() statements are globally ENABLED

-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/he/Documents/nRF/hello_world_thing/build/empty_net_core/b0n
=== child image b0n - CPUNET (inherited) end ===

CMake Warning at ../../../subsys/bootloader/cmake/debug_keys.cmake:36 (message):

--------------------------------------------------------------
--- WARNING: Using generated NSIB public/private key-pair. ---
--- It should not be used for production. ---
--- See CONFIG_SB_SIGNING_KEY_FILE ---
--------------------------------------------------------------

Call Stack (most recent call first):
../../../subsys/bootloader/cmake/provision_hex.cmake:37 (include)
../../../subsys/CMakeLists.txt:17 (include)

CMake Warning at C:/ncs/v2.4.1/zephyr/CMakeLists.txt:839 (message):
No SOURCES given to Zephyr library: lib__libc__common

Excluding target from build.

-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/he/Documents/nRF/hello_world_thing/build/empty_net_core
=== child image empty_net_core - CPUNET end ===

-- Found Python3: C:/ncs/toolchains/31f4403e35/opt/bin/python.exe (found version "3.8.2") found components: Interpreter
Changed board to secure thingy53_nrf5340_cpuapp (NOT NS)

=== child image mcuboot - begin ===
loading initial cache file C:/Users/he/Documents/nRF/hello_world_thing/build/mcuboot/child_image_preload.cmake
Loading Zephyr default modules (Zephyr base (cached)).
-- Application: C:/ncs/v2.4.1/bootloader/mcuboot/boot/zephyr
-- CMake version: 3.20.5
-- Cache files will be written to: C:/ncs/v2.4.1/zephyr/.cache
-- Zephyr version: 3.3.99 (C:/ncs/v2.4.1/zephyr)
-- Found west (found suitable version "1.0.0", minimum required is "0.7.1")
-- Board: thingy53_nrf5340_cpuapp
-- Found host-tools: zephyr 0.16.0 (C:/ncs/toolchains/31f4403e35/opt/zephyr-sdk)
-- Found toolchain: zephyr 0.16.0 (C:/ncs/toolchains/31f4403e35/opt/zephyr-sdk)
-- Found BOARD.dts: C:/ncs/v2.4.1/zephyr/boards/arm/thingy53_nrf5340/thingy53_nrf5340_cpuapp.dts
-- Found devicetree overlay: C:/ncs/v2.4.1/nrf/modules/mcuboot/flash_sim.overlay
-- Generated zephyr.dts: C:/Users/he/Documents/nRF/hello_world_thing/build/mcuboot/zephyr/zephyr.dts
-- Generated devicetree_generated.h: C:/Users/he/Documents/nRF/hello_world_thing/build/mcuboot/zephyr/include/generated/devicetree_generated.h
-- Including generated dts.cmake file: C:/Users/he/Documents/nRF/hello_world_thing/build/mcuboot/zephyr/dts.cmake
Parsing C:/ncs/v2.4.1/bootloader/mcuboot/boot/zephyr/Kconfig
Loaded configuration 'C:/Users/he/Documents/nRF/hello_world_thing/build/mcuboot/zephyr/.config'
No change to configuration in 'C:/Users/he/Documents/nRF/hello_world_thing/build/mcuboot/zephyr/.config'
No change to Kconfig header in 'C:/Users/he/Documents/nRF/hello_world_thing/build/mcuboot/zephyr/include/generated/autoconf.h'
CMake Warning at C:/ncs/v2.4.1/zephyr/CMakeLists.txt:839 (message):
No SOURCES given to Zephyr library: lib__libc__common

Excluding target from build.

-- Found partition manager static configuration: C:/ncs/v2.4.1/zephyr/boards/arm/thingy53_nrf5340/pm_static_thingy53_nrf5340_cpuapp.yml
MCUBoot bootloader key file: C:/ncs/v2.4.1/bootloader/mcuboot/root-rsa-2048.pem
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/he/Documents/nRF/hello_world_thing/build/mcuboot
=== child image mcuboot - end ===

CMake Warning at C:/ncs/v2.4.1/nrf/modules/mcuboot/CMakeLists.txt:310 (message):

---------------------------------------------------------
--- WARNING: Using default MCUBoot key, it should not ---
--- be used for production. ---
---------------------------------------------------------

CMake Warning at C:/ncs/v2.4.1/zephyr/CMakeLists.txt:839 (message):
No SOURCES given to Zephyr library: lib__libc__common

Excluding target from build.

-- Found partition manager static configuration: C:/ncs/v2.4.1/zephyr/boards/arm/thingy53_nrf5340/pm_static_thingy53_nrf5340_cpuapp_ns.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 'tfm_secure' 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' 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 'nonsecure_storage' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_primary_1' 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_secondary_1' is not included in the dynamic resolving since it is statically defined.
Partition 'pcd_sram' is not included in the dynamic resolving since it is statically defined.
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/he/Documents/nRF/hello_world_thing/build
←[92m-- west build: building application
[5/297] Generating include/generated/version.h
-- Zephyr version: 3.3.99 (C:/ncs/v2.4.1/zephyr), build: v3.3.99-ncs1-1
[10/297] Performing build step for 'empty_net_core_subimage'
[0/26] Performing build step for 'b0n_subimage'
[21/29] Linking C executable zephyr\zephyr_pre0.elf

[24/29] Linking C executable zephyr\zephyr_pre1.elf

[29/29] Linking C executable zephyr\zephyr.elf
Memory region Used Size Region Size %age Used
FLASH: 21588 B 34176 B 63.17%
RAM: 3416 B 64 KB 5.21%
SRAM1: 0 GB 64 KB 0.00%
IDT_LIST: 0 GB 2 KB 0.00%
[10/26] Linking C executable zephyr\zephyr_pre0.elf

[13/26] Linking C executable zephyr\zephyr_pre1.elf

[18/26] Linking C executable zephyr\zephyr.elf
Memory region Used Size Region Size %age Used
FLASH: 17682 B 222 KB 7.78%
RAM: 4040 B 64 KB 6.16%
SRAM1: 0 GB 64 KB 0.00%
IDT_LIST: 0 GB 2 KB 0.00%
[20/24] Creating signature of application
[22/24] Creating validation for zephyr.hex, storing to
[24/24] Generating zephyr/merged_CPUNET.hex
[12/297] Generating ../../tfm/CMakeCache.txt
-- Found Git: C:/ncs/toolchains/31f4403e35/mingw64/bin/git.exe (found version "2.37.3.windows.1")
-- The C compiler identification is GNU 12.2.0
-- The ASM compiler identification is GNU
-- Found assembler: C:/ncs/toolchains/31f4403e35/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc.exe
-- Found Python3: C:/ncs/toolchains/31f4403e35/opt/bin/python.exe (found version "3.8.2") found components: Interpreter
-- Found Python3: C:/ncs/toolchains/31f4403e35/opt/bin/python.exe (found suitable exact version "3.8.2") found components: Interpreter
-- Cache files will be written to: C:/ncs/v2.4.1/zephyr/.cache
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/he/Documents/nRF/hello_world_thing/build/tfm
[22/297] Performing build step for 'mcuboot_subimage'
[28/36] Linking C executable zephyr\zephyr_pre0.elf

[31/36] Linking C executable zephyr\zephyr_pre1.elf

[36/36] Linking C executable zephyr\zephyr.elf
Memory region Used Size Region Size %age Used
FLASH: 63908 B 64 KB 97.52%
RAM: 364632 B 504 KB 70.65%
IDT_LIST: 0 GB 2 KB 0.00%
[25/297] Generating ../../zephyr/net_core_app_update.bin
image.py: sign the payload
[26/297] Generating ../../zephyr/net_core_app_signed.hex
image.py: sign the payload
[27/297] Generating ../../zephyr/net_core_app_test_update.hex
image.py: sign the payload
[29/297] Performing build step for 'tfm'
[159/159] Linking C static library secure_fw\libtfm_s_veneers.a
[34/297] Performing install step for 'tfm'
-- Install configuration: "MinSizeRel"
[277/297] Linking C executable zephyr\zephyr_pre0.elf

[281/297] Linking C executable zephyr\zephyr_pre1.elf

[287/297] Linking C executable zephyr\zephyr.elf
Memory region Used Size Region Size %age Used
FLASH: 44840 B 848 KB 5.16%
RAM: 14832 B 472 KB 3.07%
IDT_LIST: 0 GB 2 KB 0.00%
[291/297] Generating ../../zephyr/app_signed.hex
image.py: sign the payload
[292/297] Generating ../../zephyr/app_update.bin
image.py: sign the payload
[294/297] Generating ../../zephyr/app_test_update.hex
image.py: sign the payload
[297/297] Generating zephyr/merged_domains.hex

he@D MINGW64 ~/Documents/nRF/hello_world_thing (master)
$

RE: Hello_world and other samples do not build properly for thingy53_NRF5340_cpuapp_ns

Menon — Mon, 07 Aug 2023 10:11:49 GMT

Hello,

Have you installed the SDK properly? Can you once try building from the command line using West? Please share the logs while building from the west. You can follow the steps mentioned here for building using West. Make sure your target board is thingy53_nrf5340_cpuapp_ns when building. I tested the hello_world sample inside NCSv2.4.0 for thingy53, and it's working fine on my side.

Kind Regards,

Abhijith