• State Verified Answer
  • Replies 9 replies
  • Subscribers 86 subscribers
  • Views 1036 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 347008
Options

Fatal error occurs when enabling flash through CONFIG_FLASH

heisenbug

I have a custom NRF9151 board with Windbond W25Q32JV flash, and some other peripherals connected. It also has GPS and LTE which I have tested and work. My UART console is connected over UART0 which I have tested separately as well. I'm trying to test the SPI flash now but when I add CONFIG_FLASH=y to the hello_world sample and flash it on my board, nothing would show up on the console. Without CONFIG_FLASH=y, a hello world message would show up expected. 

I tried debugging the micro through west debug and saw the following stack trace:

#0  arch_system_halt (reason=25) at /.../zephyr/kernel/fatal.c:30
#1  0x00017756 in k_sys_fatal_error_handler (reason=<optimized out>, esf=<optimized out>) at /.../zephyr/kernel/fatal.c:44
#2  0x000138d4 in z_fatal_error (reason=<optimized out>, esf=<optimized out>) at /.../zephyr/kernel/fatal.c:119
#3  0x0001561a in z_arm_fatal_error (reason=<optimized out>, esf=esf@entry=0x2000d380 <z_interrupt_stacks+2008>) at /.../zephyr/arch/arm/core/fatal.c:86
#4  0x00012732 in arm_fault (exc_return=<optimized out>, esf=esf@entry=0x2000d380 <z_interrupt_stacks+2008>) at /.../nrf/modules/trusted-firmware-m/fault.c:283
#5  0x00012776 in tfm_ns_fault_handler_callback () at /.../nrf/modules/trusted-firmware-m/fault.c:337
#6  0xfefffffe in ?? ()

  • 0 in reply to Benjamin

    How does SPI flash functionality differ when building for insecure vs secure variant of the board?

  • 0 in reply to heisenbug

    It should not be a difference.


    Internal flash: Can be partitioned and protected by the SPU.

    External SPI flash: Not protected by the SPU. Accessible to both secure and non-secure code unless you implement your own software-based protections.

    Have you changed any other file in the hello_world sample?

  • 0 in reply to Benjamin

    At the time I decided to run the spi flash example without TF-M. Coming back to it, I see a clearer issue. I have my SPI flash configured on SPI1 in the device tree. Without TF-M it works as expected. With TF-M, I get the following bus fault:

    [00:00:00.263,793] <err> os: ***** BUS FAULT *****
[00:00:00.263,793] <err> os:   Precise data bus error
[00:00:00.263,793] <err> os:   BFAR Address: 0x0
[00:00:00.263,824] <err> os: r0/a1:  0x00010e0c  r1/a2:  0x00000003  r2/a3:  0x40009000
[00:00:00.263,824] <err> os: r3/a4:  0x0000000a r12/ip:  0x40842500 r14/lr:  0xfffcf8f0
[00:00:00.263,854] <err> os:  xpsr:  0x01000200
[00:00:00.263,854] <err> os: Faulting instruction address (r15/pc): 0x0000b400
[00:00:00.263,885] <err> os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
[00:00:00.263,916] <err> os: Current thread: 0x2000ccd8 (unknown)
[00:00:00.325,073] <err> os: Halting system

    When I check the address location, it points the following line: zephyr/drivers/pinctrl/pinctrl_nrf.c:179

    When I replace SPI1 with SPI2, I don't see the problem anymore with TF-M enabled. Is SPI1 only meant to operate without TF-M?

  • 0 in reply to heisenbug

    I figured it out. It's because TF-M still uses UART1 for logging even though the peripheral is disabled in the device tree. Setting CONFIG_TFM_LOG_LEVEL_SILENCE=y fixed the isse

Related
Terms of service