Hi,
I need to use the cryptocell in a project with a preemptive OS. Are there any relevant code examples available, or at least some general guidelines and precautions (e.g., for the initialization of the cryptocell)?
Thanks,
Damian
Hi,
I need to use the cryptocell in a project with a preemptive OS. Are there any relevant code examples available, or at least some general guidelines and precautions (e.g., for the initialization of the cryptocell)?
Thanks,
Damian
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).
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.
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.
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.