feat: add basic CryptoCell RNG driver #5176

nponsard · 2026-01-05T13:34:53Z

This PR adds a CryptoCell RNG driver for the nrf91 series. I built it following the RNG driver for the other nrf chips, an example has been added for the nrf9151 to show how to use it.

It needs an updated nrf-pac, PR here: embassy-rs/nrf-pac#14

I tested the example on the nrf9160dk and Thingy:91 X (nrf9151).

Concerning the activation of the CryptoCell (Cryptocell::enable()), should this be set up by the user or the RNG driver ?

lulf

For now I think the rng driver can do it, ideally if it can check if it's enabled already first.

Also, maybe the peripheral and types could be named RNG and Rng? It aligns with existing peripherals and doesn't conflict with any other rng for those chips.

nponsard · 2026-01-05T14:09:35Z

Also, maybe the peripheral and types could be named RNG and Rng? It aligns with existing peripherals and doesn't conflict with any other rng for those chips.

It would become a conflict if it gets extended to the nrf52840 that has both RNG and CryptoCell peripherals.

Dirbaio · 2026-01-05T15:52:47Z

embassy-nrf/src/chips/nrf9160.rs

        EGU5_S as EGU5,
        FICR_S as FICR,
-        FPU_S as FPU,
+        FPU_NS as FPU,


why this change?

It came with the new generated PAC, FPU_S doesn't exist anymore. I saw that FPU_NS was used even in s mode on the nrf9120 so I made the same modification as a fix.

nponsard · 2026-01-06T15:23:07Z

Alright, squashed my fixup commits, managed to get nrf52840 supported and tested (copying cryptocell_rng from examples/nrf9151/s/, ran on the nrf52840 of my nrf9160dk).

Is there any more changes needed ?

nponsard · 2026-01-06T15:24:05Z

Oh also I changed the nrf-pac commit to be the one in main since the svd update got merged.

nponsard · 2026-01-06T15:38:12Z

Ah I just thought about the naming, should the struct be named CcRng, CCRng or Ccrng ?
I think the last one matches more UpperCamelCase

0e4ef622 · 2026-01-07T07:08:42Z

embassy-nrf/src/cryptocell_rng.rs

+
+        let on_drop = OnDrop::new(|| {
+            self.stop();
+            self.disable_irq();


disable_irq should come before stop, since stop stops the RNG_CLK and "The registers of a cryptographic engine are only accessible when its clock is enabled."

I didn't think about that, this should be fixed now.

0e4ef622 · 2026-01-07T07:13:01Z

embassy-nrf/src/cryptocell_rng.rs

+    fn enable_irq(&self) {
+        pac::CC_HOST_RGF
+            .imr()
+            .write(|w| w.set_rng_mask(pac::cc_host_rgf::vals::RngMask::IRQENABLE));
+        self.r
+            .rng_imr()
+            .write(|w| w.set_ehr_valid_mask(pac::cc_rng::vals::EhrValidMask::IRQENABLE));
+    }


Not sure if this is considered a pac bug or not, but the default value of IMR from nrf-pac is 0, which means enable all the interrupts. (According to the datasheet and SVD file, the reset value is all 1's.). You could use modify instead. Same issue exists in disable_irq.

Ah my bad, I used write too often when experimenting. Should be good now.

0e4ef622 · 2026-01-07T07:13:42Z

embassy-nrf/src/cryptocell_rng.rs

+    fn disable_irq(&self) {
+        self.r.rng_icr().write(|w| w.set_ehr_valid_clear(true));
+        pac::CC_HOST_RGF.icr().write(|w| w.set_rng_clear(true));
+        self.r
+            .rng_imr()
+            .write(|w| w.set_ehr_valid_mask(pac::cc_rng::vals::EhrValidMask::IRQDISABLE));
+    }


did you forget CC_HOST_RGF.IMR here?

Thanks, I now added the instruction to mask the rng interrupt

0e4ef622 · 2026-01-07T16:00:57Z

examples/nrf9151/s/src/bin/cryptocell_rng.rs

+
+    // https://docs.nordicsemi.com/bundle/ps_nrf9151/page/cryptocell.html#ariaid-title96
+
+    pac::CRYPTOCELL.enable().write(|w| w.set_enable(true));


is this still necessary?

0e4ef622 · 2026-01-07T23:47:32Z

embassy-nrf/src/cryptocell_rng.rs

+                // without calling its destructor.
+
+                for i in 0..6 {
+                    let bytes = r.ehr_data(i).read().to_be_bytes();


Why to_be_bytes? I saw you use from_ne_bytes elsewhere.

from_ne_bytes comes from the rng driver on main, I tend to use to_be_bytes by default with no real reason. It shouldn't matter as it's random bits right ? Is there a performance impact ?

I can change it to to_ne_bytes if you want.

There is at least a size impact, it's one extra instruction.

Changed to_be_bytes occurrences to to_ne_bytes

0e4ef622 · 2026-01-08T00:05:46Z

Mentioned on matrix earlier, but I tested this on an nrf5340 and blocking api works, but async doesn't. The CRYPTOCELL interrupt never fires for some reason. But if I read some registers, like CRYPTOCELL.ENABLE or the RNG_ISR register, then the interrupt fires, might be an undocumented erratum.

Interestingly, I found a library within TF-M for using the cryptocell, and it seems like they always busy wait for RNG interrupts specifically.

nponsard · 2026-01-08T09:25:39Z

I can try to add nrf5340 support.

What's the best way to busy wait ? Is it a good idea to make the task sleep for short durations using Timer::after_millis(1).await; so other tasks can be executed ?

Signed-off-by: Nils Ponsard <[email protected]>

Dirbaio · 2026-01-08T17:05:24Z

Is it a good idea to make the task sleep for short durations using Timer::after_millis(1).await; so other tasks can be executed ?

it's better to do loop { yield_now().await }. It still lets other tasks run but loops as fast as possible.

Sleeping adds ltency, plus embassy-time is an optional dep.

0e4ef622 · 2026-01-08T17:57:46Z

I'd also be fine with excluding the async functionality from nrf53.

nponsard · 2026-01-09T09:41:25Z

I made it so only the async driver of the nrf5340 CryptoCell is behind a async-ccrng-nrf5340 feature. Makes a bit of a mess in the imports that I tried to mitigate in e6118b2

lulf reviewed Jan 5, 2026

View reviewed changes

Dirbaio reviewed Jan 5, 2026

View reviewed changes

nponsard force-pushed the cryptocell branch 2 times, most recently from 9958880 to f85f144 Compare January 6, 2026 15:21

nponsard requested a review from lulf January 6, 2026 15:23

0e4ef622 reviewed Jan 7, 2026

View reviewed changes

nponsard force-pushed the cryptocell branch from 816de77 to 7ebf2dc Compare January 7, 2026 16:47

0e4ef622 reviewed Jan 7, 2026

View reviewed changes

nponsard added 6 commits January 8, 2026 15:01

feat: update nrf-pac

1f9f120

Signed-off-by: Nils Ponsard <[email protected]>

feat: implement CryptoCell RNG

13cd0ba

Signed-off-by: Nils Ponsard <[email protected]>

feat: add nrf5340 ccrng support

9383221

Signed-off-by: Nils Ponsard <[email protected]>

docs: add nrf9151 example for Cryptoncell RNG

05a4cc6

Signed-off-by: Nils Ponsard <[email protected]>

docs: use cryptocell to generate seed for embassy_net stack

96d1c06

Signed-off-by: Nils Ponsard <[email protected]>

docs: add nrf5340 ccrng example

7af2a2f

Signed-off-by: Nils Ponsard <[email protected]>

nponsard force-pushed the cryptocell branch from 10dfa27 to 7af2a2f Compare January 8, 2026 14:01

nponsard added 4 commits January 9, 2026 10:19

fixup! feat: add nrf5340 ccrng support

40ef70c

fixup! docs: add nrf5340 ccrng example

0d25b7e

fixup! feat: implement CryptoCell RNG

b56cffe

fixup! fixup! feat: add nrf5340 ccrng support

e6118b2


		// https://docs.nordicsemi.com/bundle/ps_nrf9151/page/cryptocell.html#ariaid-title96

		pac::CRYPTOCELL.enable().write(\|w\| w.set_enable(true));

feat: add basic CryptoCell RNG driver #5176

Are you sure you want to change the base?

feat: add basic CryptoCell RNG driver #5176

Uh oh!

Conversation

nponsard commented Jan 5, 2026

Uh oh!

lulf left a comment

Choose a reason for hiding this comment

Uh oh!

nponsard commented Jan 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nponsard commented Jan 6, 2026

Uh oh!

nponsard commented Jan 6, 2026

Uh oh!

nponsard commented Jan 6, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nponsard Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0e4ef622 commented Jan 8, 2026

Uh oh!

nponsard commented Jan 8, 2026

Uh oh!

Dirbaio commented Jan 8, 2026

Uh oh!

0e4ef622 commented Jan 8, 2026

Uh oh!

nponsard commented Jan 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

nponsard Jan 8, 2026 •

edited

Loading