tfm_ns_fault_handler_callback is called when booting

[Replay]

Hi,

I have a problem where tfm_ns_fault_handler_callback is called when booting the system.

This results in arm_fault and k_sys_fatal_error_handler is called. The reason is 41.

I have upgraded to SDK v2.6.1

Custom board based on nrf9160-SIP

The project is based on a azure iot hub example.

This is the error log:

[00:00:00.422,271] <ESC><err> os: ***** SECURE FAULT *****<ESC><CR><LF>
[00:00:00.422,302] <ESC><err> os:   Address: 0x22<ESC><CR><LF>
[00:00:00.422,302] <ESC><err> os:   Attribution unit violation<ESC><CR><LF>
[00:00:00.422,332] <ESC><err> os: r0/a1:  0x00000000  r1/a2:  0x00000005  r2/a3:  0x0006620c<ESC><CR><LF>
[00:00:00.422,332] <ESC><err> os: r3/a4:  0x2001d599 r12/ip:  0x200103f2 r14/lr:  0x00055723<ESC><CR><LF>
[00:00:00.422,363] <ESC><err> os:  xpsr:  0x61000000<ESC><CR><LF>
[00:00:00.422,363] <ESC><err> os: Faulting instruction address (r15/pc): 0x00056080<ESC><CR><LF>
[00:00:00.422,393] <ESC><err> os: >>> ZEPHYR FATAL ERROR 41: Unknown error on CPU 0<ESC><CR><LF>
[00:00:00.422,424] <ESC><err> os: Current thread: 0x200104a0 (unknown)<ESC><CR><LF>
[00:00:01.177,398] <ESC><err> fatal_error: Resetting system<ESC><CR>

Please feel free to contact me, if more information is needed.

BR Replay

[Sigurd Hellesvik]

Hi,

The project is based on a azure iot hub example.

Did the project ever work before?

Regards,
Sigurd Hellesvik

[Replay]

Hi,

Yes without any problem.

Here is the history:

Starting the project using 2.0.0, encountered a sdk problem. upgraded to 2.2.0 to resolve the issue.

Now using 2.2.0 without debugging enabled. A problem need more debugging information enabled.

When debug was enabled enabled the program would not start. Found a devzone post (cannot find it again) where other did encounter problems with enabling debugging on 2.2.0, when I upgraded to 2.6.1 to solve the debugging issue I meet the issue described above.

BR Replay

[Sigurd Hellesvik]

The context helps indeed.

If 2.6.1, do you see the issue both with and without debugging enabled?

[Replay]

Yes, with and without debugging enabled.

[Sigurd Hellesvik]

Do you get any logs before the crash happens?

The project is based on a azure iot hub example.

Can you build the azure IoT hub sample for the DK and run it?

Can you build the azure IoT hub sample for your custom board and run it?

These will give us useful information to when the issue happens or not

[Replay]

Sigurd Hellesvik said:

Do you get any logs before the crash happens?

Yes:

[00:00:00.422,271] <ESC><err> os: ***** SECURE FAULT *****<ESC><CR><LF>
[00:00:00.422,302] <ESC><err> os:   Address: 0x22<ESC><CR><LF>
[00:00:00.422,302] <ESC><err> os:   Attribution unit violation<ESC><CR><LF>
[00:00:00.422,332] <ESC><err> os: r0/a1:  0x00000000  r1/a2:  0x00000005  r2/a3:  0x0006620c<ESC><CR><LF>
[00:00:00.422,332] <ESC><err> os: r3/a4:  0x2001d599 r12/ip:  0x200103f2 r14/lr:  0x00055723<ESC><CR><LF>
[00:00:00.422,363] <ESC><err> os:  xpsr:  0x61000000<ESC><CR><LF>
[00:00:00.422,363] <ESC><err> os: Faulting instruction address (r15/pc): 0x00056080<ESC><CR><LF>
[00:00:00.422,393] <ESC><err> os: >>> ZEPHYR FATAL ERROR 41: Unknown error on CPU 0<ESC><CR><LF>
[00:00:00.422,424] <ESC><err> os: Current thread: 0x200104a0 (unknown)<ESC><CR><LF>
[00:00:01.177,398] <ESC><err> fatal_error: Resetting system<ESC><CR>

Sigurd Hellesvik said:

Can you build the azure IoT hub sample for the DK and run it?

Yes, I can build and run the sample for DK. With and without debug enabled.

Sigurd Hellesvik said:

Can you build the azure IoT hub sample for your custom board and run it?

Yes, I can build and run the sample for my custom board. With and without debug enabled.

[Sigurd Hellesvik]

Interesting.

Can you in broad terms list the main feature differences between the Az ure IoT Hub sample and your app?

Also, try to check TF-M logs and see what they say

[Replay]

Okay maybe this not the best way of finding the error.

But it all started when using 2.2.0 and enabling debug.

I did go back and tried it again.

I use mcuboot in the project. This is the differences in .config files when building without vs with debugging enabled.

Without:

CONFIG_BOOT_FIH_PROFILE_OFF=y

# CONFIG_BOOT_FIH_PROFILE_LOW is not set

*** Booting Zephyr OS build v3.2.99-ncs1 ***<CR><LF>
I: Starting bootloader<CR><LF>
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3<CR><LF>
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3<CR><LF>
I: Boot source: none<CR><LF>
I: Swap type: none<CR><LF>
I: Bootloader chainload address offset: 0x10000<CR><LF>
I: Jumping to the first image slot<CR><LF>

With:

# CONFIG_BOOT_FIH_PROFILE_OFF is not set

CONFIG_BOOT_FIH_PROFILE_LOW=y

*** Booting Zephyr OS build v3.2.99-ncs1 ***<CR><LF>
I: Starting bootloader<CR><LF>
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3<CR><LF>
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3<CR><LF>
I: Boot source: none<CR><LF>
I: Swap type: none<CR><LF>

Here the bootloader just stops.

The execution stops in

context_boot_go

After this check: - BOOT_SWAP_TYPE(state) is

BOOT_SWAP_TYPE_NONE

if (BOOT_SWAP_TYPE(state) != BOOT_SWAP_TYPE_NONE)

Notable differences:
- Using mcuboot as bootloader.
- Added FOTA.
- Using external SPI-NOR flash for image storage.

BR Replay