SPRACM7 December 2020 F29H850TU , F29H859TU-Q1 , TMS320F280021 , TMS320F280021-Q1 , TMS320F280023 , TMS320F280023-Q1 , TMS320F280023C , TMS320F280025 , TMS320F280025-Q1 , TMS320F280025C , TMS320F280025C-Q1 , TMS320F280040-Q1 , TMS320F280040C-Q1 , TMS320F280041 , TMS320F280041-Q1 , TMS320F280041C , TMS320F280041C-Q1 , TMS320F280045 , TMS320F280048-Q1 , TMS320F280048C-Q1 , TMS320F280049 , TMS320F280049-Q1 , TMS320F280049C , TMS320F280049C-Q1 , TMS320F28384D , TMS320F28384D-Q1 , TMS320F28384S , TMS320F28384S-Q1 , TMS320F28386D , TMS320F28386D-Q1 , TMS320F28386S , TMS320F28386S-Q1 , TMS320F28388D , TMS320F28388S , TMS320F28P550SG , TMS320F28P550SJ , TMS320F28P559SJ-Q1 , TMS320F28P650DH , TMS320F28P650DK , TMS320F28P650SH , TMS320F28P650SK , TMS320F28P659DH-Q1 , TMS320F28P659DK-Q1 , TMS320F28P659SH-Q1
C2000 is a trademark of Texas Instruments Incorporated.
All trademarks are the property of their respective owners.
The critical need for any real-time closed loop control system is to remain stable throughout life, as shown in Figure 1-1, and have a way to handle any out-of-bound system scenario in the safest possible way. At the time of design, the control systems are architected to handle a range of system variables, parameters and scenarios.
When the system is in use, if any of these variables or parameters were to go beyond what the control loop is designed for, then the stability of the whole system is at stake. While real-time debug and trace techniques exist, these can only help in a development environment with a debugger or trace receiver hooked up. These technologies cannot be used once the system is actually functioning in the end equipment.
A good example of such a scenario is a motor controller in servo drive or any real time motor in an electric vehicle. In a development environment, real-time debuggers and trace technologies can be used to collect data, perform offline analysis and use this to tune and modify the system. But once this goes into a production system, the above said mechanism for on-chip monitoring is a critical requirement.
C2000 MCU architecture includes a new and advanced peripheral Embedded Real-time Analysis & Diagnostic (ERAD) that facilitates sophisticated non-intrusive detection and monitoring of the MCU operation in real time. This mechanism in the architecture can run in parallel to the main CPU along with the user application. In the event of detecting a dangerous situation in the architecture, the hardware mechanism helps with a quick response to address the problem by taking the best possible corrective action runtime.
With a typical control loop, the transfer function can be described as a sequence of operations starting with the input peripherals (like the analog-to-digital converter (ADC) that creates inputs for the control routine), the critical system software running on the CPU doing the necessary computations and deciding the next set of actions on the output peripherals (like the PWM). The exact sequence and details of such system an operation will be different for different end applications. However, in all real-time systems, sequences like the one described above need to run within a certain time period. If not, there will be serious implications since they are controlling equipment’s like motors and power supplies.
A lot of care is taken during the development phase to handle out of range inputs and different system use conditions. However, when these systems go into a production environment, there is certainly a possibility of encountering something beyond what the system designer had anticipated during development. While there is no expectation for the system to function properly under such out-of-bound conditions, it is quite important that this situation be handled in a graceful manner without any significant damage to the final end equipment. It is this detection and handling that poses a significant challenge in real-time systems and it is here the ERAD peripheral will come to rescue the system designer.
ERAD can be used to realize hardware breakpoints and few more profiling options are available with debugger connected, but focus is purely on run-time monitoring and diagnostics in the coming sections.
ERAD is a hardware module that can be configured to non-intrusively monitor and profile critical CPU buses and device events.
ERAD is a hardware module with enhanced bus comparators and system event counters and sits within the MCU bus architecture as shown in the overview diagram. ERAD on its own can generate system level interrupts and flags and can also feed into other peripherals such as the CLB (configurable logic block) for further enhancing the capabilities. For complete understanding of the relationship between these two modules, see the CLB documentation located in the device-specific TRM.
ERAD monitors the CPU interfaces in a non-intrusive manner and also monitors some critical CPU internal buses and signals that convey information about the CPU code execution and pipeline. Most of the critical CPU interfaces are monitored by a comparator unit, which can be configured to match any address/data/instruction patterns that appear on the CPU interface and generate events based on this, as shown in Figure 1-2. There are multiple such units that can generate multiple events in parallel with different pattern matching capabilities. The comparator supports bit masking while comparing, which helps to detect/trigger events on ranges and not just discrete times alone. A simple example would be to generate an event when an address of interest is accessed for a read or write.
Other examples would be to trigger an event if code access goes beyond a certain safe zone or detecting a stack overflow as shown in the examples to follow.
The following is a list of CPU interfaces that can be monitored by EBC (F28004x):
In addition to monitoring the critical CPU interfaces, monitoring various events in the system like interrupts and peripheral activity is another important requirement for any real-time system. All the key system events like interrupts, DMA triggers and important peripheral events are brought into the ERAD IP. Hence, these can be time-stamped, counted and measured with relation to the CPU activity. Using state machines in CLB, it is possible to further define sequences of operations and events. Counter block allows the system events, as well as CPU activity, to be measured and analyzed with reference to other events, too.
Simple examples of linking CPU activity and system events are:
Counter supports a unique start stop mode, where in counter records the CPU cycles spent between any start and stop event. Moreover there is additional hardware which continuously keeps a record of the maximum count value reached by this counter across multiple start/stop iterations. Importantly, all the above mentioned metrics are achieved with zero software overhead.
Some of the unique benefits rendered by this counter are:
List of events that can be profiled by SEC (F28004x) are:
A frequently encountered issue with embedded code development is detecting an overflowing stack. With ERAD, a single enhanced bus-comparator unit can be used., Then, map the stack end address with a small margin to generate an interrupt when there is a write that is attempted. With the example below, just use a comparator with address 0x99FF0 and mask the last 4-bits for comparison. Any write access to 0x99FF0 to 0x99FFF would generate an event/interrupt, which can then be handled appropriately based on kind of the application.
Example: C2000Ware_3_03_00_00\driverlib\<f28004x/f28002x/f2838x>\examples\erad\c28x_hwbp_stack_overflow\erad_ex8_hwbp_stack_threshold_detection.c
The same example shown in Section 2.1 can simply be extended to a bigger region. You can certainly detect if there are any writes performed to a location or the region that is not intended to. Since these modules can be configured on the fly, you can certainly re-configure (enable/disable) these blocks at different times giving different context at which these units will be active and not.