A software test can be utilized to
test the basic functionality of the module and to inject diagnostic errors and check
for a proper error response. Such tests can be executed at boot or periodically.
Necessary software requirements are defined by the software implemented by the
system integrator.
Ideas for creating some
module-specific functionality and error tests are given below:
- Software tests of the input and
output X-BAR module can be performed by having a loop created (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 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.
- 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 the
enable (XINTxCR.ENABLE) functionalities as well.
- eCAP and eQEP functionality can
be checked by looping back the PWM, HRPWM, 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.3.3.14.
- The ePWM 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) sub-modules. The
individual sub-modules can be tested by providing appropriate stimulus using
ePWM and observing the response using one of the capture (time stamping) 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 sub-modules, getting high
coverage is possible using a software test.
- A software test of SRAM wrapper
logic must provide diagnostic coverage for arbitration between various
controllers 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 (see Section 6.3.3.19).
- The interconnect (INC) functionality can be tested by writing
complimentary data-patterns, such as 0xA5A5, 0x5A5A, or other common test cases,
to the processing units in the CPU and reading those patterns back from the
registers of the various IPs connected through different interconnect bridges.
The read-back data can be compared with expected golden values to verify
a fault-free interconnect operation. This exercise can be repeated for different
data width types of accesses (16 and 32 bits) and wide address ranges, as
applicable. The CPU accesses can be repeated for different instances of
peripherals used in application connected to various bridges as shown in Figure 4-1.
- To test core functionality of the
ADC module and post processing block (PPB), a set of predetermined voltage
levels can be provided on the ADC input pin by external circuit or internal DAC.
The ADC and PPB results obtained can be cross checked against the expected value
to verify proper operation. Extreme corner values of the ADC used in an
application can be applied and tested to check the successful conversion across
the operational range. ADC configuration registers can be checked by writing
complementary data-patterns that are read back and compared to expected
values.
- Comparator sub-system (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. These data-patterns are read back and
compared against the expected values. Features of the CMPSS module, such as ramp
decrement, can be checked for counting down of RAMPDLYA after RAMPDLYA is loaded
from RAMPDLYS by a rising PWMSYNC signal. Always verify that the decrementer
reduces to zero and stays 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 the registers
to a variety of SAMPWIN (sample window) and THRESH (majority voting threshold)
values, and then verifying COMPHSTS/COMPLSTS changes with changes in the filter
output. An applicable range of filter-clock, pre-scaler values (CTRIPLFILCLKCTL)
can be exercised to verify that the filter samples correctly.
- The general operation of the CPU timers can be tested through
a software test by loading 32-bit counter register TIMH from period register
PRDH. The TIMH counter register then starts decrementing on every clock cycle.
When the 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 the clock source as SYSCLK, INTOSC1,
INTOSC2, or XTAL. Interrupt generation can be tested at the end of each timer
period. Check for the time overflow flag and timer reload (TRB) functions in 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.