pub struct SCB { /* private fields */ }
Expand description

System Control Block

Implementations

Returns the active exception number

Enables I-cache if currently disabled.

This operation first invalidates the entire I-cache.

Disables I-cache if currently enabled.

This operation invalidates the entire I-cache after disabling.

Returns whether the I-cache is currently enabled.

Invalidates the entire I-cache.

Enables D-cache if currently disabled.

This operation first invalidates the entire D-cache, ensuring it does not contain stale values before being enabled.

Disables D-cache if currently enabled.

This operation subsequently cleans and invalidates the entire D-cache, ensuring all contents are safely written back to main memory after disabling.

Returns whether the D-cache is currently enabled.

Cleans the entire D-cache.

This function causes everything in the D-cache to be written back to main memory, overwriting whatever is already there.

Cleans and invalidates the entire D-cache.

This function causes everything in the D-cache to be written back to main memory, and then marks the entire D-cache as invalid, causing future reads to first fetch from main memory.

Invalidates D-cache by address.

  • addr: The address to invalidate, which must be cache-line aligned.
  • size: Number of bytes to invalidate, which must be a multiple of the cache line size.

Invalidates D-cache cache lines, starting from the first line containing addr, finishing once at least size bytes have been invalidated.

Invalidation causes the next read access to memory to be fetched from main memory instead of the cache.

Cache Line Sizes

Cache line sizes vary by core. For all Cortex-M7 cores, the cache line size is fixed to 32 bytes, which means addr must be 32-byte aligned and size must be a multiple of 32. At the time of writing, no other Cortex-M cores have data caches.

If addr is not cache-line aligned, or size is not a multiple of the cache line size, other data before or after the desired memory would also be invalidated, which can very easily cause memory corruption and undefined behaviour.

Safety

After invalidating, the next read of invalidated data will be from main memory. This may cause recent writes to be lost, potentially including writes that initialized objects. Therefore, this method may cause uninitialized memory or invalid values to be read, resulting in undefined behaviour. You must ensure that main memory contains valid and initialized values before invalidating.

addr must be aligned to the size of the cache lines, and size must be a multiple of the cache line size, otherwise this function will invalidate other memory, easily leading to memory corruption and undefined behaviour. This precondition is checked in debug builds using a debug_assert!(), but not checked in release builds to avoid a runtime-dependent panic!() call.

Invalidates an object from the D-cache.

  • obj: The object to invalidate.

Invalidates D-cache starting from the first cache line containing obj, continuing to invalidate cache lines until all of obj has been invalidated.

Invalidation causes the next read access to memory to be fetched from main memory instead of the cache.

Cache Line Sizes

Cache line sizes vary by core. For all Cortex-M7 cores, the cache line size is fixed to 32 bytes, which means obj must be 32-byte aligned, and its size must be a multiple of 32 bytes. At the time of writing, no other Cortex-M cores have data caches.

If obj is not cache-line aligned, or its size is not a multiple of the cache line size, other data before or after the desired memory would also be invalidated, which can very easily cause memory corruption and undefined behaviour.

Safety

After invalidating, obj will be read from main memory on next access. This may cause recent writes to obj to be lost, potentially including the write that initialized it. Therefore, this method may cause uninitialized memory or invalid values to be read, resulting in undefined behaviour. You must ensure that main memory contains a valid and initialized value for T before invalidating obj.

obj must be aligned to the size of the cache lines, and its size must be a multiple of the cache line size, otherwise this function will invalidate other memory, easily leading to memory corruption and undefined behaviour. This precondition is checked in debug builds using a debug_assert!(), but not checked in release builds to avoid a runtime-dependent panic!() call.

Invalidates a slice from the D-cache.

  • slice: The slice to invalidate.

Invalidates D-cache starting from the first cache line containing members of slice, continuing to invalidate cache lines until all of slice has been invalidated.

Invalidation causes the next read access to memory to be fetched from main memory instead of the cache.

Cache Line Sizes

Cache line sizes vary by core. For all Cortex-M7 cores, the cache line size is fixed to 32 bytes, which means slice must be 32-byte aligned, and its size must be a multiple of 32 bytes. At the time of writing, no other Cortex-M cores have data caches.

If slice is not cache-line aligned, or its size is not a multiple of the cache line size, other data before or after the desired memory would also be invalidated, which can very easily cause memory corruption and undefined behaviour.

Safety

After invalidating, slice will be read from main memory on next access. This may cause recent writes to slice to be lost, potentially including the write that initialized it. Therefore, this method may cause uninitialized memory or invalid values to be read, resulting in undefined behaviour. You must ensure that main memory contains valid and initialized values for T before invalidating slice.

slice must be aligned to the size of the cache lines, and its size must be a multiple of the cache line size, otherwise this function will invalidate other memory, easily leading to memory corruption and undefined behaviour. This precondition is checked in debug builds using a debug_assert!(), but not checked in release builds to avoid a runtime-dependent panic!() call.

Cleans D-cache by address.

  • addr: The address to start cleaning at.
  • size: The number of bytes to clean.

Cleans D-cache cache lines, starting from the first line containing addr, finishing once at least size bytes have been invalidated.

Cleaning the cache causes whatever data is present in the cache to be immediately written to main memory, overwriting whatever was in main memory.

Cache Line Sizes

Cache line sizes vary by core. For all Cortex-M7 cores, the cache line size is fixed to 32 bytes, which means addr should generally be 32-byte aligned and size should be a multiple of 32. At the time of writing, no other Cortex-M cores have data caches.

If addr is not cache-line aligned, or size is not a multiple of the cache line size, other data before or after the desired memory will also be cleaned. From the point of view of the core executing this function, memory remains consistent, so this is not unsound, but is worth knowing about.

Cleans an object from the D-cache.

  • obj: The object to clean.

Cleans D-cache starting from the first cache line containing obj, continuing to clean cache lines until all of obj has been cleaned.

It is recommended that obj is both aligned to the cache line size and a multiple of the cache line size long, otherwise surrounding data will also be cleaned.

Cleaning the cache causes whatever data is present in the cache to be immediately written to main memory, overwriting whatever was in main memory.

Cleans a slice from D-cache.

  • slice: The slice to clean.

Cleans D-cache starting from the first cache line containing members of slice, continuing to clean cache lines until all of slice has been cleaned.

It is recommended that slice is both aligned to the cache line size and a multiple of the cache line size long, otherwise surrounding data will also be cleaned.

Cleaning the cache causes whatever data is present in the cache to be immediately written to main memory, overwriting whatever was in main memory.

Cleans and invalidates D-cache by address.

  • addr: The address to clean and invalidate.
  • size: The number of bytes to clean and invalidate.

Cleans and invalidates D-cache starting from the first cache line containing addr, finishing once at least size bytes have been cleaned and invalidated.

It is recommended that addr is aligned to the cache line size and size is a multiple of the cache line size, otherwise surrounding data will also be cleaned.

Cleaning and invalidating causes data in the D-cache to be written back to main memory, and then marks that data in the D-cache as invalid, causing future reads to first fetch from main memory.

Set the SLEEPDEEP bit in the SCR register

Clear the SLEEPDEEP bit in the SCR register

Set the SLEEPONEXIT bit in the SCR register

Clear the SLEEPONEXIT bit in the SCR register

Initiate a system reset request to reset the MCU

Set the PENDSVSET bit in the ICSR register which will pend the PendSV interrupt

Check if PENDSVSET bit in the ICSR register is set meaning PendSV interrupt is pending

Set the PENDSVCLR bit in the ICSR register which will clear a pending PendSV interrupt

Set the PENDSTSET bit in the ICSR register which will pend a SysTick interrupt

Check if PENDSTSET bit in the ICSR register is set meaning SysTick interrupt is pending

Set the PENDSTCLR bit in the ICSR register which will clear a pending SysTick interrupt

Returns the hardware priority of system_handler

NOTE: Hardware priority does not exactly match logical priority levels. See NVIC.get_priority for more details.

Sets the hardware priority of system_handler to prio

NOTE: Hardware priority does not exactly match logical priority levels. See NVIC.get_priority for more details.

On ARMv6-M, updating a system handler priority requires a read-modify-write operation. On ARMv7-M, the operation is performed in a single, atomic write operation.

Unsafety

Changing priority levels can break priority-based critical sections (see register::basepri) and compromise memory safety.

Enable the exception

If the exception is enabled, when the exception is triggered, the exception handler will be executed instead of the HardFault handler. This function is only allowed on the following exceptions:

  • MemoryManagement
  • BusFault
  • UsageFault
  • SecureFault (can only be enabled from Secure state)

Calling this function with any other exception will do nothing.

Disable the exception

If the exception is disabled, when the exception is triggered, the HardFault handler will be executed instead of the exception handler. This function is only allowed on the following exceptions:

  • MemoryManagement
  • BusFault
  • UsageFault
  • SecureFault (can not be changed from Non-secure state)

Calling this function with any other exception will do nothing.

Check if an exception is enabled

This function is only allowed on the following exception:

  • MemoryManagement
  • BusFault
  • UsageFault
  • SecureFault (can not be read from Non-secure state)

Calling this function with any other exception will read false.

Pointer to the register block

👎Deprecated since 0.7.5: Use the associated constant PTR instead

Returns a pointer to the register block

Trait Implementations

The resulting type after dereferencing.
Dereferences the value.

Auto Trait Implementations

Blanket Implementations

Gets the TypeId of self. Read more
Immutably borrows from an owned value. Read more
Mutably borrows from an owned value. Read more

Returns the argument unchanged.

Calls U::from(self).

That is, this conversion is whatever the implementation of From<T> for U chooses to do.

The type returned in the event of a conversion error.
Performs the conversion.
The type returned in the event of a conversion error.
Performs the conversion.