• State Verified Answer
  • Replies 22 replies
  • Subscribers 65 subscribers
  • Views 809 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 327664
Options

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

Parents Reply Children
  • 0 in reply to Sigurd Hellesvik
    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.

  • 0 in reply to Replay

    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

  • 0 in reply to Sigurd Hellesvik

    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

  • 0 in reply to Replay
    Replay said:
    - Using mcuboot as bootloader.

    The Azure IoT Hub sample is also using MCUboot by default for the nRF9160DK.

    Replay said:
    - Added FOTA.

    Same for this.

    So that makes me wonder, what did you do to add those?
    Maybe something happended when you were trying to add something that is already enabled.

    Replay said:
    - Using external SPI-NOR flash for image storage.

    This is often something that can fail.
    Try to disable external flash temporarily, to test if it works without.

  • 0 in reply to Sigurd Hellesvik
    Sigurd Hellesvik said:
    Also, try to check TF-M logs and see what they say

    I'm having a hard time getting the TF-M to log any information.

    My problem is using UART2 for logging, but none of the configs enables it for UART2.

    I have tried with

    CONFIG_TFM_SECURE_UART0,
    CONFIG_TFM_SECURE_UART1,
    CONFIG_TFM_SECURE_UART22
Related