A software test can be utilized to test the basic functionality of the module and to inject diagnostic errors and check for proper error response. Such a test can be executed at boot or periodically. The necessary software requirements are defined by the software implemented by the system integrator.

Ideas for creating module-specific functionality tests and error tests are described below:

• DMA functionality can be checked by transferring a known good data from a source memory to the destination memory and checking for data integrity after the transfer. The transfer can be initiated using the software trigger available (CONTROL.PERINTFRC). On-chip timer can be used to profile the time required for such a data transfer.
• A software test of input and output X-BAR module can be performed by creating a loop (output X-BAR can be used as stimulus to input X-BAR) using the input and output X-BAR, sending a known test sequence at the input and observing the sequence at the final output. Integrity of ePWM X-BAR can be checked by sending the test stimulus and observing the response using ePWM trip or sync functionality.
• A software test of XINT functionality can be checked by configuring the input X-BAR and forcing the corresponding GPIO register to generate an interrupt. The diagnostic coverage can be enhanced by performing checks for the polarity (XINTxCR.POLARITY) and enabling (XINTxCR.ENABLE) functionality as well.
• ECAP and EQEP functionality can be checked by looping back the PWM or GPIO outputs to the respective module inputs, providing a known good sequence (as required by the module), and observing the module output. In the case of ECAP, the test can be done internally with the help of input X-BAR.
• ROM prefetch functionality can be checked using similar techniques as given in Section 6.4.3.33.
• The PWM module consists of time-base (TB), counter compare (CC), action qualifier (AQ), dead-band generator (DB), PWM chopper (PC), trip zone (TZ), event trigger (ET), and digital compare (DC) submodules. The individual submodules can be tested by providing appropriate stimulus using PWM and observing the response using one of the capture (timestamping) modules (eCAP, XINT, eQEP, and so forth). TI recommends covering the various register values associated with application configuration while performing the software test. Due to the regular, linear nature of the various submodules, getting high coverage using a software test is possible.
• A software test of SRAM wrapper logic must provide diagnostic coverage for arbitration between various initiators having access to the particular SRAM and correct functioning of access protection. This is in addition to the test used to provide coverage of SRAM bit cells (refer to Section 6.4.3.3).
• The interconnect (INC) functionality can be tested by writing complementary data-patterns, like 0xA5A5,0x5A5A and so forth, from processing units like CPU and CLA and reading back the data-patterns from registers of the IPs that are connected through different bridges. The readback data can be compared with the expected golden values to verify fault-free interconnect operation. This exercise can be repeated for different data width types of accesses (16/32 bits) and wide address ranges (as applicable) using both CPU and CLA. The CPU accesses can be repeated for different instances of peripherals used in application connected to various bridges, as shown in Figure 4-1.
• DAC has a set of control registers that can be checked by writing complementary data-patterns, like 0xA5A5, 0x5A5A and so forth, in 16-bit access mode. All the registers can be read back and compared to expected values. Registers can be checked for the reset feature by configuring the registers to 0xA5A5 pattern, asserting soft reset of DAC, reading back the registers, and comparing the readback value with the expected reset value. Lock register can be checked to verify the DAC is set-once. Also, the registers, which are getting locked, must not update when written. To test core functionality of the DAC module, the DAC can be configured using software to provide a set of predetermined voltage levels. These voltage levels can be measured by external or internal ADC and results thus obtained can be cross checked against the expected value to verify proper operation. Extreme corner values of DAC, as per the application, can be programmed and tested to check the successful conversion of a digital to analog module across a valid range.
• Comparator subsystem (CMPSS) has a set of registers which can be checked by writing complementary data-patterns, like 0xA5A5, 0x5A5A, and so forth, in both 16 and 32-bit access modes. The registers can be read back and compared against expected values. These accesses can be covered by applicable initiators like DMA, CLA, and CPU. Features of the CMPSS module, such as ramp decrement, can be checked for counting down of RAMPDLYA after the DAC module is loaded from RAMPDLYS by a rising PWMSYNC signal. The decrementer must reduce to zero and stay there until next reload from RAMPDLYS. Extreme values of RAMPDLYS can be configured before count down. Digital filter CTRIPHFILCTL/CTRIPLFILCTL registers can be checked by configuring them to a variety of N and T values and then verifying the COMPHSTS/COMPLSTS changes with the change in filter output. The applicable range of filter clock prescaler values (CTRIPLFILCLKCTL) can be exercised to verify that filter samples correctly.
• The general operation of the CPU timers can be tested by a software test by loading 32-bit counter register TIMH from period register PRDH. The PRDH register starts decrementing of the counter on every clock cycle. When counter reaches zero, a timer interrupt output generates an interrupt pulse. While testing the timer functionality, vary the timer prescale counter (TPR) value and input clocks by selecting clock source as SYSCLK, INTOSC1, INTOSC2, XTAL, or AUXPLLCLK. Test interrupts generation capability at the end of the timer counting. Check for the time overflow flag and timer reload (TRB) functions in the TCR register for correct functioning.
• A software test function in DCSM can be implemented independently in zone1, zone2, and unsecured zone to check DCSM functionality. Device security configurations are loaded from OTP to DCSM during the device boot phase. The test function can implement access filtering checks (read-write and execute permissions) to RAMs and flash sectors belonging to the same zone and different zone. An additional check for EXEONLY configuration can also be implemented for the RAMs and flash sectors to verify that all access (other than execute access) is blocked.