Self-Test Application¶
This section will describe the Self-Test Application (or STA) example project delivered with the diagnostic library. The STA is an example which provides a demonstration of the SDL modules and diagnostic functions.
The STA is designed to act as an example application which configures the system and calls the SDL APIs to perform the safety diagnostic tests made available in the diagnostic library. The STA is not intended to limit the customer to any implementation of safety diagnostic functions. Instead, it is intended to aid integration of the SDL into the user’s end application or system by providing a demonstration of how to use the library. It is the responsibility of the system integrator to meet any and all safety compliance standards in their end application.
The STA has been tested on the controlCARD and docking station.
Getting Started¶
The Code Composer Studio project containing the STA can be imported into CCS by going to Project -> Import CCS Projects… and browsing to the search directory below.
<C2000Ware_install>\libraries\diagnostic\<device>\examples\test_application
Right click on the newly imported project in the Project Explorer pane and select Build Project. This will build the default RAM configuration of the project. The project provides several other build configurations for different levels of optimization and running the application from Flash, but the RAM configuration is a good starting point for getting familiar with the STA.
Connect and power your controlCARD according to the controlCARD info sheet in directory
<C2000Ware_install>\boards\controlCARDs\
The STA uses the SCIA module to communicate test progress and results through the controlCARD’s USB-to-UART adapter. Before running the application, set up a terminal session with 9600 baud rate, 8-N-1. Note that CCS contains a terminal window that can be accessed by going to View -> Terminal.
With the test application project selected in the Project Explorer, go to Run -> Debug. This will launch a debug session using the .ccxml to which the project is linked. By default, the XDS100v2 is used as this is the on-board debug probe for the controlCARD.
Run the application. In the terminal, you should see a looping message indicating test cases passing.
Fig. 2 Passing Terminal Output¶
Example Behavior¶
Most tests will display a PASS message in the terminal when they execute successfully with error injection disabled and display a FAIL message when they execute successfully when error injection is enabled. To toggle error injection, add the enableErrorInject variable to the CCS Expressions view. Setting its value to 1 will enable error injection. Setting it back to 0 will disable it.
The STA has built in profiling code for measuring cycle counts of the library functions as they are used by the STA. This functionality is turned on by default and uses CPU Timer 1 to capture time elapsed and records the result to an array called STA_Tests_cycleCounts which can be viewed in the CCS Expressions view.
The profiling can be turned off by changing the value of macro STA_UTIL_PROFILE to 0 and recompiling. More details about the functions used for profiling can be found in the Integration Notes section.
Note that it is not possible to inject an error for the all tests. In particular, the STA_MARCH, STA_MARCH_CAN, and STA_MARCH_MCAN tests are expected to return PASS even when enableErrorInject is set. The core API used by these tests is STL_March_testRAM(). This function performs the March13n algorithm on the RAM memory addresses specified without a copy and restore of their original contents unlike STA_MARCH_COPY, STA_MARCH_CAN_COPY, and STA_MARCH_MCAN_COPY. Since the first operation performed on the memory as part of the algorithm is a write which triggers a recalculation of the parity or ECC, any error injected prior to running the test will be overwritten before it can be detected.
In STA_LCM_TEST the compare error force check (STL_LCM_checkCompareError()) will always fail when running with the debugger connected. To see it pass, you will need to disconnect the debugger and reset the device. See the Debug Mode with LCM section of the device Technical Reference Manual for more details.
The STA_SP_TEST may be affected by placing breakpoints when the code is executing from Flash. The same hardware watchpoints used by the STL_SP module to monitor the stack are used by CCS to place breakpoints in Flash (RAM breakpoints are software breakpoints). If CCS has ownership of the watchpoints, the STL_SP code will don’t be able to claim them.
STA Utility Functions¶
This section provides an API reference guide for the utility functions that are part of the STA project.