It is hard to discuss protection units without understanding protection context and visa-versa. These two topics work hand and hand to implement security between the different bus masters in the PSoC™ 6. Bus masters include the CPUs (CM0+ and CM4), crypto block, test controller (Debug Port), and DMA. Protection units use protection context to control access of memory areas and registers that control the many IP blocks in the PSoC™ 6.
Protection units are hardware blocks that can be programmed to disallow some bus masters access to specific memory regions and hardware blocks. The protection units are an important feature especially when you have multiple CPUs that share the same memory and peripherals. The designer has the option to isolate a subsection of memory and peripherals for each CPU making it effectively like two independent systems. This can be ideal when creating secure and non-secure domains. If one CPU attempts to access memory (SRAM and Flash) or peripherals assigned to the other CPU, a page fault will occur. Unprotected areas will remain as shared memory or peripherals.
There are four types protection units. Some are dedicated to specific block such as a PWM or ADC and others can be used across any memory area. Below is a list of the protection units.
The diagram below shows how each of the protection units are arranged in the PSoC™ 6 architecture. The ARM MPUs that are part of the CPUs are standard IP from ARM. The remaining protections units are custom Infineon design and provide features not found in other devices.
The SMPUs (Shared Memory Protection Unit) are intended to partition and protect the SRAM and Flash, but may be used through the entire memory area. Each SMPU can cover a region between 256 bytes to 4 GB in powers of 2. This region is then divided up into 8 sub-regions which may be enabled or not. For example, if you programmed a SMPU to cover a 64K region, the sub-regions would be 1/8 or 8K. You could then choose to only protect 5 of those sub-regions for a total protected area of 40K (5 * 8K). The table below shows some of the parameters that can be programmed into the SMPUs:
There are two types of Peripheral Protection Units, fixed (PPU) and programmable (PPPU). The fixed PPUs are dedicated to a fixed region of registers, usually a single peripheral. For example, there will be one specific PPU for each TCPWM (Timer Counter Pulse Width Modulator), or SCB (Serial Communication Block). The PPPU on the other hand can be programmed over a range of registers or blocks, not just a single TCPWM or SCB. For example, if you want to protect 8 TCPWM blocks you could either program the 8 PPUs associated with those TCPWMs or you could use a single PPPU to protect all TCPWMs with a single protection unit. The PPPUs are most useful to protect sets of registers that aren’t as specific as a TCPWM, but instead like a specific range of the clocking section you want to secure. Like the SMPU you can restrict read and/or write access to a select group of bus masters.
The ARM MPUs that are part of the CPU blocks, are meant to be configured by an RTOS to protect one tasks memory from another and do not support protection context. The non-ARM MPUs that are used for the test controller and the Crypto block are simple protection units used to limit the access by these two bus masters and do not affect operation with other bus masters.
PSoC™ 6 has 8 different protection context values from 0 to 7. Protection context 1 thru 7 have equal priority and are just used to designate different bus master groups. Protection context of 0, is a special case. A bus master set to PC=0, has access to all memory and peripherals no matter how the protection units are configured. Think of PC=0 as super user mode.
By default, the CPUs are set to PC=0 after reset. In the dual core parts, it is recommended that the protection units and bus master PC values/masks all be set before the CM4 is enabled. After configuration, the last PC value to change would be the one for the CM0+. It is good practice to change the CPUs and all bus masters to PC != 0. Once a CPU has been changed from PC=0 to another PC value, it cannot change itself back to PC=0. There is one exception to this rule. The CMO+ may be configured so that an interrupt will save its current PC value and set the PC value to 0 while executing the interrupt. When it returns from this special interrupt, the original PC value will be returned to its original value. This special case is already configured during the boot process to implement the systems calls.
A bus master is programmed with a mask of what PC values it can be assigned, and a current PC value. At any one time, the bus master can have only one current PC value, although it can change its current PC value to one enabled in the mask, but not to a PC value not in the mask. If a bus master’s PC mask enables PC values of 1, 2, and 3 it can change its current PC value to any of these. If an attempt is made to change the PC value to PC=4, an error will occur and the PC value will not be changed. Without this feature, any bus master could just change its PC to any value. The DMA bus master is unique in that it automatically inherits the PC value from the CPU (CM0+ or CM4) that configures it.
Protection units are not assigned to bus masters, but instead you select which protection contexts are valid to access the region specified by the protection unit. Each protection unit has a PC mask that determines which PC values are accepted. Protection units do not have a “current” PC value like a bus master, instead all the PC values enabled with the mask are valid concurrently.
For example, if an SMPU was set up with a PC mask that allowed PC values of 4 and 5, bus masters with a PC value 4 or 5 could access this region of memory. A bus master with a PC=1 cannot access the region specified by this SMPU.
One or all bus masters can share the same protection context, or they may all be different. For example, sharing the SRAM with everyone but blocking any CPU from executing the code in the SRAM. A bus master with a PC=0, always has full read/write/execute to the entire memory space no matter the configuration of any protection units.
Although a bus master PC mask may allow several PC values, the currently selected PC value is the only one that matters when accessing a protected memory area. For example, a CM4 (bus master) had a PC mask that allowed PC values 1, 2, and 3 and had a current PC value of 3. If it attempted to access a region protected by an SMPU that only allowed 1 or 2, the access would fail and cause a hard fault because the bus master’s current value was not 1 or 2. If CM4 had changed its protection context to 1 or 2 before accessing the region, the operation would work without error.
The protection units in the PSoC™ 6 are very flexible and can be used to configure almost any secured system you can design. Protection context allow you divide your code by CPU and/or by task. For example, you might allow your bootloader to have access to all memory, but the CM4 and CM0+ projects only the memory area they each operate.
Modus Toolbox includes the “Prot” (Protection) library to simplify the programming of the protection units and protection context. All the protection units except the CPU MPUs, are supported by this library.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
By technically required cookies we mean cookies without those the technical provision of the online service cannot be ensured. These include e.g. cookies supporting essential services like a smooth reproduction of video or audio footage. So called ‘functional cookies’ are also assigned belonging to this category. Functional cookies store information in order to provide you comfortable use of our online services (e.g. language selection). The legal basis for the processing of personal data by means of cookies of this category is Infineon’s legitimate interest. This includes, among other things, the interest in having a professional external presentation as well as an optimal balancing of the loads on the server due to technical reasons.
By performance and marketing cookies we mean cookies which are technically not required. We use performance and marketing cookies only if you have given us your prior consent. With such cookies, we collect information about how users interact with our website and which pages have been visited. This helps us to understand user activity on our website on an aggregated as well as on a personal level to provide you relevant content and services.