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.

../_images/terminal.jpg

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.

Also, note that executing HWBIST can terminate the debugger connection. Therefore, the STA provides two macros, STA_UTIL_HWBIST_MICRO and STA_UTIL_HWBIST_FULL, to include or exclude the HWBIST micro-run test and the full test respectively.

When error injection is enabled, the STA will iterate through the five error injection techniques for HWBIST. Additionally, since the HWBIST may terminate the debugger connection and access to debugger information, the STA writes some debugging information to global arrays. These global arrays are STA_Tests_memDumpMicro and STA_Tests_memDumpFull. The information includes:

  1. The error injected using enumerated type STL_HWBIST_Error

  2. Information whether or not the previous NMI vector was restored

  3. The return value from the test function

  4. The status of the global error flags

The global arrays are large enough to hold the information from 5 runs of the HWBIST (20 by 32-bits)–that is one for each of the 5 different types of tests executed by the STA.

Some of these tests will return a passing value although an error was injected. The expected behavior of a full run is described in the table below:

errorType

Error Value

Return Status

NMI

NO_ERROR

0x0000

0x0003 (BIST_DONE OR MACRO_DONE)

No

TIMEOUT

0x000A

0x0029 (TO_FAIL OR BIST_FAIL)

Yes

FINAL_COMPARE

0x00A0

0x0003 (BIST_DONE OR MACRO_DONE)

No

NMI_TRAP

0x0A00

0x0005 (BIST_DONE OR NMI)

Yes

LOGIC_FAULT

0x2000

0x001B (BIST_DONE OR MACRO_DONE OR BIST_FAIL OR INT_COMP_FAIL)

Yes

More details about the behavior of injected errors can be found in this HWBIST application note.

STA Utility Functions

This section provides an API reference guide for the utility functions that are part of the STA project.