This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BUS FAULT when calling SYS_INIT and using secure services

Hi!

I'm running into quite a strange problem which is that when trying to use SPM secure services in my program, I get a BUS FAULT error.

What's also really strange is that the error doesn't occur on the function call but a few ms after. The function exits correctly and returns the expected value and then, the program crashes.

When I try to remove the secure function call, the BUS FAULT error stops occurring as well as when I remove all SYS_INIT. No matter which one I keep, I get the BUS FAULT error.

K_SEM_DEFINE(sem_end, 0, 1)

void main(void)
{
	printk("Calling secure function\n");

	uint32_t result;

	int ret = spm_request_read(&result, (uint32_t)&NRF_FICR_S->INFO.PART,
		sizeof(uint32_t));

	if (ret != 0) {
		printk("Could not read FICR (err: %d)\n", ret);
	}
	printk("FICR.INFO.PART = 0x%08X\n\n", result);

	printk("Calling secure function success!\n");

	k_sem_take(&sem_end, K_FOREVER);
}

LOG output:

Calling secure function
FICR.INFO.PART = 0x00009120

Calling secure function success!
[00:00:01.583,923] <inf> protobuf: Initializing protobuf
[00:00:02.583,953] <err> os: ***** MPU FAULT *****
[00:00:02.583,984] <err> os:   Instruction Access Violation
[00:00:02.583,984] <err> os: r0/a1:  0x00000000  r1/a2:  0xe000ed00  r2/a3:  0x200156c0
[00:00:02.583,984] <err> os: r3/a4:  0x20014a00 r12/ip:  0x871dfabe r14/lr:  0x0001c80d
[00:00:02.584,014] <err> os:  xpsr:  0x61000000
[00:00:02.584,014] <err> os: Faulting instruction address (r15/pc): 0xab55d3c4
[00:00:02.584,014] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:02.584,014] <err> os: Current thread: 0x20014a00 (unknown)
[00:00:02.646,697] <err> os: Halting system

There is nothing special happening in that protobuf function except the LOG output (I disabled everything else):

static int protobuf_init(const struct device *dev)
{
	ARG_UNUSED(dev);

	LOG_INF("Initializing protobuf");

	return 0;
}

SYS_INIT(protobuf_init, APPLICATION, CONFIG_APPLICATION_INIT_PRIORITY);

Thanks by advance to anyone that can help me with this issue !

  • Update: I think I need to give a little more information.

    I use an nRF9160 with the Modem Library. This seems to be closely related to the issue since I doesn't occur when the NRF_MODEM_LIB_SYS_INIT config is set to false.

    Here is most of the project's configuration:

    # General
    CONFIG_CONSOLE=y
    CONFIG_UART_CONSOLE=y
    CONFIG_LOG=y
    CONFIG_REBOOT=y
    CONFIG_GPIO=y
    CONFIG_ASSERT=y
    
    CONFIG_HW_STACK_PROTECTION=y
    
    # System
    CONFIG_MAIN_STACK_SIZE=8000
    CONFIG_IDLE_STACK_SIZE=1024
    CONFIG_ISR_STACK_SIZE=2048
    CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=5000
    CONFIG_HEAP_MEM_POOL_SIZE=8192
    CONFIG_LOG_STRDUP_MAX_STRING=200
    CONFIG_LOG_STRDUP_BUF_COUNT=16
    
    # Modem
    CONFIG_NRF_MODEM_LIB=y
    CONFIG_NRF_MODEM_LIB_SYS_INIT=y
    
    # Socket
    CONFIG_NETWORKING=y
    CONFIG_NET_NATIVE=n
    CONFIG_NET_SOCKETS=y
    CONFIG_NET_SOCKETS_OFFLOAD=y
    CONFIG_NET_SOCKETS_POSIX_NAMES=y
    
    CONFIG_MODEM_INFO=y
    
    # General config
    CONFIG_NEWLIB_LIBC=y
    CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y
    CONFIG_RESET_ON_FATAL_ERROR=n
    
    # LTE link control
    CONFIG_LTE_LINK_CONTROL=y
    CONFIG_LTE_NETWORK_MODE_LTE_M=y
    CONFIG_LTE_AUTO_INIT_AND_CONNECT=n
    
    # UART
    CONFIG_UART_INTERRUPT_DRIVEN=y
    CONFIG_AT_HOST_LIBRARY=n
    
    CONFIG_SPM=y
    CONFIG_SPM_SECURE_SERVICES=y
    CONFIG_SPM_SERVICE_REBOOT=y
    CONFIG_SPM_SERVICE_BUSY_WAIT=y
    CONFIG_SPM_SERVICE_READ=y
    CONFIG_SPM_SERVICE_RNG=y
    
    

  • Hi,

     

    The fault happens 1 second after protobuf init.

    You can use arm-none-eabi-addr2line to resolve a address to source code:

    arm-none-eabi-addr2line -e ../build-folder/zephyr/zephyr.elf 0xFAULTING_ADDRESSES

    The content of LR (0x1c80d in this case) can be interesting to look at.

     

    In addition, you can also map the failing thread by looking at build/zephyr/zephyr.map, and look for this address:

    [00:00:02.584,014] <err> os: Current thread: 0x20014a00 (unknown)

     

    Could you try this and see where those addresses point to?

     

    Kind regards,

    Håkon

  • Hi Håkon,

    First of all, thank you for your answer.

    Before reading your answer, I tried several things and finally tried to update the sdk_nrf and this happened to fix the issue. I know it is not the best kind of fix since I don't know for sure what was causing the issue but looking at the modifications made to SPM, this seems to be related to the FPU driver. Indeed, on the update, the FPU driver is no longer used in favor of the CC3XX driver for RNG (Random Number Generation).

    Please note that reading the "select FPU" attribute on the SPM subsys Kconfig leads to the FAULT error coming back which is what lead me to think it was related to it.

    Anyway, thank you again for your help!

    Kind regards,

    Farès 

  • Hi,

     

    I am glad to hear that the issue is seemingly fixed at your end.

    This might be the PR that fixed the problem for you:

    https://github.com/nrfconnect/sdk-nrf/pull/4702

     

    As per the commit msg, spm needs to have the fpu disabled now:

    This prevents problems related to FPU mismatch.
    FPU must now be disabled in SPM, and the app is free to use FPU like
    normal.

     

    Kind regards,

    Håkon

Related