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 TMS320F28004x 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 and low threshold register values to minimum and maximum 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.
- 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.
- eCAP, HRCAP 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 and HRCAP, 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 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 suitable stimulus using ePWM 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 from 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 and 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.
-
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 / PPB results
thus obtained can be cross checked against the expected value to ensure proper
operation. Extreme corner values of ADC being used in 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, read back
and compared to expected values.
- 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
SAMPWIN (Sample window) and THRESH (Majority voting threshold) 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, or XTAL. 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.