• State Verified Answer
  • Replies 22 replies
  • Subscribers 74 subscribers
  • Views 2063 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
  • 0

    Hi,

    The project is based on a azure iot hub example.

    Did the project ever work before?

    Regards,
    Sigurd Hellesvik

  • 0 in reply to Sigurd Hellesvik

    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

  • 0 in reply to Replay

    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

  • 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

Reply
  • 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

Children
Related
Terms of service