To meet the demand for more safety and comfort in automotive and industrial applications, a variety of different control and memory units are required. This leads to the question of how to combine different software modules in a single control unit without taking any risks. As a rule, pure software-based solutions do not offer the necessary safety and, besides, are very expensive. To rule out interaction and possible error propagation, strict encapsulation of all the software modules to be deployed is a vital issue. The encapsulation of software modules by means of hardware-based memory protection (MPU) leads to an appreciable reduction of the test and certification efforts and at the same time it also enables simple and safe function integration and protects, in the event of system crash or damage, against possible unjustified product liability claims. However, the development of such complex systems presumes that all tools in use support the encapsulation of software modules.

With drive applications (which are available as a drive demo kit), the basic system consists of the real-time operating system PXROS-HR, the driver and protocols, debug monitor, and a motor control unit. All the components of this basic system are encapsulated and protected by the MPU. This means the whole system is protected against error propagation.

The typical configuration of software modules (PXROS-HR tasks) is shown here. Two of the four data protection registers configure the sectors for the constants, stack and data of a task. The two remaining registers can be used for exchanging messages. Sending a message from Task1 and receiving this message in Task2 corresponds to the handover of an encapsulated memory sector (object) including its access right.

The protected message object can thus have any size. Memory consumption is minimal in comparison to approaches which realise protection by mapping (MMU). It is a well-known fact that the memory efficiency to be achieved particularly in embedded applications is a crucial point since in most cases there is only a small amount of RAM available. PXROS-HR in combination with the MPU of the TriCore architecture guarantees a fine-grained protection which is safe and highly efficient at the same time with a managing overhead of only about 5%. In practice this approach offers significant advantages for all parties involved: the system designer, the software developer, and the product manager. For the system designer, the encapsulation of software modules in particular means that the complexity of the software system is considerably reduced. The software modules are free of interaction and configured with their allocated resources. The absence of interaction allows a risk-free combination of safety-critical and non-safety-critical software modules. In total, this leads to a simplified and cost-effective certification process of such applications. For software developers, encapsulation means among other advantages that, with the independence of software modules, a simple module testing is possible. The MPU forces the software developer to adhere to the memory resources predetermined by the system designer. A protection violation caused, for example, by an inadvertent pointer access or transient error does not lead to any interference whatsoever with the remaining system. Safe and simple function integration is made possible by the encapsulated structure since faults in software modules can be detected at an early stage of development.

To make a smooth operation possible, it is vital that the debug tools in use observe the corresponding mechanisms and support two essential operating modes (as in the case of the universal debug engine UDE provided by pls).

The first operating mode uses a JTAG debugger for debugging the PXROS-HR kernels. The memory protection unit employed by the operating system is generally used for realising a maximum of four hardware code breakpoints plus additional data breakpoints. The MPU resources are to be shared between the debugger and PXROS-HR. The current implementation enables the setting of two code breakpoints within the debugger. The memory protection provided by the remaining memory protection unit is realised by the operating system. The second operating mode enables debugging of currently up to two reloadable PXROS-HR tasks (VCU). Since it is not desirable to halt the hardware in this case, debugging of the application takes place via a debug monitor integrated in the target operating system. The monitor encapsulates task-specific breakpoints, context handling and call stacks for the debugger which is transparent to a large extent and addressable via a gdb-compatible command interface. Ethernet and serial interfaces serve as standard connections to the target monitor. However, JTAG as a communication channel is also usable with the universal debug engine and an enhanced monitor. The latter is an advantage since ethernet is not a typical interface for TriCore targets, and because both kernel and application debugging can take place via a JTAG connection if required.