NRF52840: Using the CryptoCell310 with a preemptive OS

RE: NRF52840: Using the CryptoCell310 with a preemptive OS

WilliamEriksson — Tue, 05 May 2020 13:49:31 GMT

Hi, although a little late here is a snippet that worked for me to mask the basepri:

NVIC_EnableIRQ(CRYPTOCELL_IRQn);
NRF_CRYPTOCELL->ENABLE = 1;

SaSi_LibInit();

/* First read the current basepri value */
uint32_t prevBasepri = __get_BASEPRI();

/* Mask (disable) all interrupts with priority greater or equal to 1 */
__set_BASEPRI( 1 << ( 8 - __NVIC_PRIO_BITS) );

CRYS_RndInit(&state, &buf);

/* Restore the previous basepri */
__set_BASEPRI(prevBasepri);

Related reading where I also posted the snippet:

https://devzone.nordicsemi.com/f/nordic-q-a/45500/nrf52840-and-cc310-random-number-generator-hanging/179450?focus=true

RE: NRF52840: Using the CryptoCell310 with a preemptive OS

Red_devil — Fri, 07 Feb 2020 13:02:00 GMT

Hi Jean,

I tried the above mentioned solution. I am facing the same issue even after adding "no-interrupts" library.

RE: NRF52840: Using the CryptoCell310 with a preemptive OS

Rudy U — Tue, 30 Jul 2019 13:14:30 GMT

Thanks for your quick response, Jean-Marc. We have tried the no interrupt library and it seems to be working fine. I guess that why Nordic made this library for the Rtos. Hopefully they fix this interrupt issue in the future :-)

yours sincerely,

Rudy

RE: NRF52840: Using the CryptoCell310 with a preemptive OS

Jean-Marc Koller — Tue, 30 Jul 2019 11:33:41 GMT

Some time after the initial post, I noticed that, in the SDK 15.3, another CC310 library made its appearance: a new folder named "no-interrupts" with a .a file in it. After switching to this library, we didn't experience any problems related to the CC310 and external interrupts. The backside might be that the current consumption might be a bit higher as the processor will actively wait for the crypto-cell to finish, but the CC310 operations are mostly quite short.

RE: NRF52840: Using the CryptoCell310 with a preemptive OS

Rudy U — Tue, 30 Jul 2019 09:44:28 GMT

Hi Damian and Jean-Marc,

We are facing the same problem with FreeRtos and the BLE stack. The CC310 is hanging in the SaSi_HalWaitInterrupt.

How did you manege to mask the interrupts? Could you post a snippet of the code or point us in the right direction

Thanks in advance,

Rudy

RE: NRF52840: Using the CryptoCell310 with a preemptive OS

Einar Thorsrud — Tue, 04 Dec 2018 11:46:41 GMT

Hi,

You are right that this is not handled in a very good way, and your workaround is probably the best solution at this point. We hope to improve this in a future release of the CC310 runtime library, but that will not happen in the near future.

RE: NRF52840: Using the CryptoCell310 with a preemptive OS

Jean-Marc Koller — Mon, 03 Dec 2018 16:11:31 GMT

The problem we did face (I'm a colleague of DamianV, by the way) is that the library did block on our pre-emptive OS.

Trying for example to use the RNG functions of the cryptocell library leads to the process calling to remain waiting forever within the SaSi_HalWaitInterrupt function. My suspicion is that this function may have not been foreseen so that other interrupts than the one coming from the cryptocell may resume from the WFE, like a timer or a peripheral.

I tried to modify our test application so that the interrupt priority mask prior to calling the problematic functions is set in order to only have the cryptocell interrupt enabled, and our application didn't block anymore!

But, without confirmation that it has to be done this way, I'm a bit reluctant to do this systematically!

I did not find any example within the SDK using the cryptocell and FreeRTOS, in order to check if special handling is required in the case of a pre-emptive OS.

RE: NRF52840: Using the CryptoCell310 with a preemptive OS

run_ar — Tue, 27 Nov 2018 08:28:35 GMT

Hi,

Cryptocell is interfaced using the cryptography library in our sdk. This is also where you can find most of the documentation. I do not see an issue in using this with a preemptive OS, as the cryptocell will interface ram using DMA. But it would make sense to make sure only one buss master access the AHB slave at the same time (see memory and AHB multilayer for details).