1 files changed, 10 insertions, 10 deletions
diff --git a/book/en/src/internals/critical-sections.md b/book/en/src/internals/critical-sections.md
index a064ad0..cd66c2b 100644
--- a/book/en/src/internals/critical-sections.md
+++ b/book/en/src/internals/critical-sections.md
@@ -30,7 +30,7 @@ task we give it a *resource proxy*, whereas we give a unique reference
 
 The example below shows the different types handed out to each task:
 
-``` rust
+``` rust,noplayground
 #[rtic::app(device = ..)]
 mut app {
     struct Resources {
@@ -62,7 +62,7 @@ mut app {
 
 Now let's see how these types are created by the framework.
 
-``` rust
+``` rust,noplayground
 fn foo(c: foo::Context) {
     // .. user code ..
 }
@@ -149,7 +149,7 @@ The semantics of the `BASEPRI` register are as follows:
 
 Thus the dynamic priority at any point in time can be computed as
 
-``` rust
+``` rust,noplayground
 dynamic_priority = max(hw2logical(BASEPRI), hw2logical(static_priority))
 ```
 
@@ -160,7 +160,7 @@ In this particular example we could implement the critical section as follows:
 
 > **NOTE:** this is a simplified implementation
 
-``` rust
+``` rust,noplayground
 impl rtic::Mutex for resources::x {
     type T = u64;
 
@@ -194,7 +194,7 @@ calls to it. This is required for memory safety, as nested calls would produce
 multiple unique references (`&mut-`) to `x` breaking Rust aliasing rules. See
 below:
 
-``` rust
+``` rust,noplayground
 #[interrupt(binds = UART0, priority = 1, resources = [x])]
 fn foo(c: foo::Context) {
     // resource proxy
@@ -223,7 +223,7 @@ provides extra information to the compiler.
 
 Consider this program:
 
-``` rust
+``` rust,noplayground
 #[rtic::app(device = ..)]
 mod app {
     struct Resources {
@@ -282,7 +282,7 @@ mod app {
 
 The code generated by the framework looks like this:
 
-``` rust
+``` rust,noplayground
 // omitted: user code
 
 pub mod resources {
@@ -374,7 +374,7 @@ mod app {
 At the end the compiler will optimize the function `foo` into something like
 this:
 
-``` rust
+``` rust,noplayground
 fn foo(c: foo::Context) {
     // NOTE: BASEPRI contains the value `0` (its reset value) at this point
 
@@ -428,7 +428,7 @@ should not result in an observable change of BASEPRI.
 This invariant needs to be preserved to avoid raising the dynamic priority of a
 handler through preemption. This is best observed in the following example:
 
-``` rust
+``` rust,noplayground
 #[rtic::app(device = ..)]
 mod app {
     struct Resources {
@@ -490,7 +490,7 @@ mod app {
 IMPORTANT: let's say we *forget* to roll back `BASEPRI` in `UART1` -- this would
 be a bug in the RTIC code generator.
 
-``` rust
+``` rust,noplayground
 // code generated by RTIC
 
 mod app {