A software test can be utilized to
test 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. Software
requirements necessary are defined by the software implemented by the system
integrator.
Ideas for
creating some module specific tests functionality and error tests are given
below:
- SDFM functionality can be checked
by sending a known input test sequence to the C2000 MCU, process it using the
digital decimation filters and cross check the value against a known value. For
detecting faults in comparator interrupt generation logic, a test pattern can be
created to configure the high/low threshold register values to min/max values
respectively. Interrupt should always be generated with such a
configuration.
- 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.
- EMIF functionality can be checked
by moving a known good data from an external memory to the internal memory and
vice versa and checking for data consistency using CRC or other mechanisms. The
test should be repeated for all the masters having access to the external
memories. In addition, the test should provide coverage to all the interface
pins used for connecting external memory to the C2000 MCU.
- Software test of 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 it 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.
- 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
enable (XINTxCR.ENABLE) functionality as well.
- IPC functionality can be checked
by using interrupts or polling method by periodically sending test commands and
message as defined by software. Time stamping information using the
IPCCOUNTERH/L can be embedded along with the message to estimate the delay in
communication.
- 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.3.7.
- 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) sub-modules. The
individual sub-modules can be tested by providing suitable stimulus using PWM
and observing the response using one of the capture (time stamping) modules
(eCAP, XINT, eQEP, and so forth). It is recommended to cover the various
register values associated with application configuration while performing the
software test. Due to the regular linear nature of the various sub-modules, it
is possible to get high coverage using a software test.
- A software test of SRAM wrapper
logic should provide diagnostic coverage for arbitration between various masters
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.12).
- The interconnect (INC) functionality can be tested by writing
complementary data-patterns like 0xA5A5,0x5A5A, and so forth from processing
units viz CPU and CLA, and reading back it from registers of the IPs’ connected
via different bridges .The read-back data can be compared with expected golden
values to ensure 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 1-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 reset feature by configuring the registers to
0xA5A5 pattern, asserting soft reset of DAC, reading back the registers and
comparing the read back value with the expected reset value. Lock register can
be checked to ensure it is set-once. Also, the registers which are getting
locked must not update when written. To test core functionality of the DAC
module, it 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
ensure proper operation. Extreme corner values of DAC as per application can be
programmed and tested to check the successful conversion of digital to analog
module across a valid range.
- 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 can be read back and compared
against expected values. These accesses can be covered by applicable masters
viz. DMA, CLA and CPU. Features of the CMPSS module such as ramp decrement can
be checked for counting down of RAMPDLYA after it is loaded from RAMPDLYS by a
rising PWMSYNC signal. It should be ensured 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 them to a variety of N and T values, and
then verifying COMPHSTS/COMPLSTS changes with change in filter output.
Applicable range of filter clock pre-scaler values (CTRIPLFILCLKCTL) can be
exercised to ensure 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,
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 also vary
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
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 ensure that all access other than
execute access is blocked.