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

ARM fault when switching to a higher priority thread during spm_ functions.

spm_test.zip

Hi,

We have seen random ARM faults.

After some time we have seen that the lr register often pointed to entropy_cc310_rng_get_entropy.

This is our setup:

- Environment: Zephyr, SDK 1.2

- An IRQ giving a semaphore to a thread A

- A thread A with higher priority than thread B waiting for a semaphore given by the IRQ.

- A thread B with a lower priority than thread A using a function that boils down to a spm_xxx call such as spm_request_random_number.

The problem arises when we get an interrupt and zephyr switches to the higher priority thread (thread A) while thread B executes the spm_xxx function.

I have enclosed a simple project that in general fails within a couple of hundred counter interrupts. The project runs fine if the following modification is done to the entropy_cc310 driver in the nrf repo:

diff --git a/drivers/entropy/entropy_cc310.c b/drivers/entropy/entropy_cc310.c
index 6888b218..e471e428 100644
--- a/drivers/entropy/entropy_cc310.c
+++ b/drivers/entropy/entropy_cc310.c
@@ -34,7 +34,9 @@ static int entropy_cc310_rng_get_entropy(struct device *dev, u8_t *buffer,
        /** This is a call from a non-secure app that enables secure services,
         *  in which case entropy is gathered by calling through SPM
         */
+       k_sched_lock();
        res = spm_request_random_number(buffer, length, &olen);
+       k_sched_unlock();
        if (olen != length) {
                return -EINVAL;
        }

    Thank you for looking into this.

    best regards,

    Daniel.

Related