PDK/PDK TDA CSL User Guide

Overview

The Chip Support Library constitutes a set of well-defined APIs that abstract low-level details of the underlying SoC device so that a user can configure, control (start/stop, etc.) and have read/write access to peripherals without having to worry about register bit-field details. The CSL services are implemented as distinct modules that correspond with the underlying SoC device modules themselves. By design, CSL APIs follow a consistent style, uniformly across Processor Instruction Set Architecture and are independent of the OS. This helps in improving portability of code written using the CSL.

CSL is realized as twin-layer – a basic register-layer and a more abstracted functional-layer. The lower register layer comprises of a very basic set of macros and type definitions. The upper functional layer comprises of “C” functions that provide an increased degree of abstraction, but intended to provide “directed” control of underlying hardware.

It is important to note that CSL does not manage data-movement over underlying h/w devices. Such functionality is considered a prerogative of a device-driver and serious effort is made to not blur the boundary between device-driver and CSL services in this regard.

CSL does not model the device state machine. However, should there exist a mandatory (hardware dictated) sequence (possibly atomically executed) of register reads/writes to setup the device in chosen “operating modes” as per the device data sheet, then CSL does indeed support services for such operations.

The CSL services are decomposed into modules, each following the twin-layer of abstraction described above. The APIs of each such module are completely orthogonal (one module’s API does not internally call API of another module) and do not allocate memory dynamically from within. This is key to keeping CSL scalable to fit the specific usage scenarios and ease the effort to ROM a CSL based application.

In general for application recommended interfaces to be used will be driver API. CSL Functional layer APIs could be used for low-level access when required. CSL Register layer memory map is available for being used under rare cases in application when required.

The source code of the CSL and examples is located under <install_directory>\packages\ti\csl directory.

CSL-FL Examples

PDK has various examples to test the functionality of API in CSL-FL layers. Kindly refer to http://processors.wiki.ti.com/index.php/PDK/PDK_TDA_Building_The_Package on steps to build the CSL examples.

The following section describes the steps to be followed to run the CSL examples.

• Boot the board in debug mode. Refer to SBL_UserGuide for configuring SYSBOOT switch in debug mode.
• Connect the EVM to CCS through JTag.
• Connect to specific core
• Load the binary
• Run the application

Note: Many CSL examples print messages on the UART Serial Console running on the host. Hence, a serial terminal application (like Tera Term/HyperTerminal/minicom) should be running on the host. The host serial port is configured at 115200 baud, Data Bits 8, no parity, 1 stop bit and no flow control. Please ensure that the local echo setting for the terminal is turned off. The serial port (DB9 connector P2) on the baseboard of the EVM is to be connected to the host serial port via a NULL modem cable.

Steps to run the individual examples are given in further sections.

ADC Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\adc\adc_singleshot_test_app.
• This app runs from Cortex M4 (on TDA3xx) and is used test ADC configured in single shot mode. The application programs ADC module to start conversion of input analog signals given through channels to digital. After complete conversion, application then prints converted digital values on the UART console. ADC module takes input form channels numbered - 3, 4, 5 and 6. User should provide inputs for Analog to digital conversion through pins ADC_IN2, ADC_IN3, ADC_IN4 and ADC_IN5.
• This example is tested on TDA3xx EVM.

CRC Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\crc\crc_semicputest_app.
• This app runs from Cortex M4 and C66x (on TDA3xx) and is used test CRC configured in semi-cpu mode. The application programs CRC to generate signature of pre-determined data pattern stored in memory. After generation of signature, application then compares it with pre-calculated signature value to check data integrity.
• Note: The application uses 32-kHz Synchronized Timer (COUNTER_32K) for calculating performance. Hence while running application on C66x_DSP1 core, put CortexM4_IPU1_C0 core in free run mode.
• This example is tested on TDA3xx EVM.

DCAN Loopback Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\dcan\dcanLoopback.
• For TDA3xx, this example has three sets of tests: DCAN External Loopback Test, DCAN Internal Loopback Test and DCAN ECC Test and for TDA2xx, TDA2Px, TDA2Ex and TDA2Ex_17x17, this example has three tests- DCAN External Loopback Test, DCAN Internal Loopback Test and DCAN Parity Test. This app runs from Cortex M4 (on TDA3xx, TDA2Ex, TDA2Ex_17x17, TDA2xx, TDA2Px) and Cortex A15 (on TDA2xx/TDA2Px)
• DCAN External Loopback Test: This application tests DCAN external loopback test mode. In this example, the input of the CAN core is connected to the input buffer of the Tx pin. In this mode, the CAN core tests the feedback from Tx output to the input buffer of the Tx pin and from the input buffer of the Tx pin to Rx input. In this mode, transmitted messages are treated as received messages and can be stored into message objects if they pass acceptance filtering. This example is tested on TDA2xx, TDA2Px, TDA2Ex, TDA2Ex_17x17 and TDA3xx EVM.
• DCAN Internal Loopback Test: This application tests DCAN internal loopback test mode. . DCAN internal loopback test mode tests the internal feedback from Tx output to Rx input of CAN core. In this mode, transmitted messages are treated as received messages and can be stored into message objects if they pass acceptance filtering. This example is tested on TDA2xx, TDA2Px, TDA2Ex, TDA2Ex_17x17 and TDA3xx EVM.
• DCAN ECC Test: This application tests DCAN ECC Feature. In this example, Single Error Correction and Double Error Detection (SECDED) ECC Feature is tested. This example will corrupt single bit of the DCAN Message RAM data in RDA Test Mode and checks whether single bit error is detected and corrected. This verifies DCAN Single Error Correction ECC Feature. This example will corrupt two bit of the DCAN Message RAM data in RDA Test Mode and checks whether double bit error is detected. This verifies DCAN Double Error Detection ECC Feature. This example is tested on TDA3xx EVM.
• DCAN Parity Test: This application tests DCAN Parity Feature for parity error checks. This example will corrupt single bit or more bits of the DCAN Message RAM data in RDA Test Mode and checks whether parity error is detected. This verifies DCAN Parity Feature. This example is tested on TDA2xx/TDA2Px EVM.

DCC Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\dcc\dcc_singleshotmode_app.
• This app runs from Cortex M4 (on TDA3xx) and is used test DCC configured in single shot mode. The application programs DCC module to use System Clock (SYS_CLK1) as a reference clock and DPLL_GMAC_H12 as a test clock. First, application configures DCC module for 5% allowed drift and generates DONE interrupt. After getting DONE interrupt, application changes the test clock frequency by programming respective DPLL while keeping rest of the configurations same, forcing test clock to drift more than 5%. This generates ERROR interrupt. This concludes the application and status is printed on the UART console.
• This example is tested on TDA3xx EVM.

DDR Test Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\ddr\ddr_test_app.
• The DDR stress test example is a test running from a15 core of tda2xx and tda2ex EVM and M4 core of tda3xx EVM. This example runs four test cases to test the entire DDR.
• The first test case does a full memory read write test. It writes a pattern to the memory reads back the data in memory and checks if the patterns match.
• The second test case does a random memory read/write test. The user has to enter the starting address, number of times to generate the random memory and the number of times the test has to be repeated. It writes a pattern to the memory, reads back the data in memory and checks if the patterns match.
• The third test case does a sequential memory read/write test where the user has to enter the starting address of the DDR memory, the size, the pattern to be tested and the number of times the test has to be repeated. It writes the pattern to the memory reads back the data in memory and checks if the patterns match.
• The fourth test case does a sequential increment pattern memory read/write test where the user has to enter the starting address of the DDR memory, the size, the pattern to be tested and the number of times the test has to be repeated. It writes the incremented pattern to the memory reads back the data in memory and checks if the patterns match.
• The example will finish testing the DDR and prints the appropriate message on the UART console if the test passes or fails.

ECC Test Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\ecc\ecc_test_app.
• This example has three sets of tests: EMIF ECC Test, OCMC ECC Test and IPU ECC Test. This app runs from Cortex M4 (on TDA3xx, TDA2xx, TDA2Px, TDA2Ex and TDA2Ex_17x17) and from Cortex A15 (on TDA2xx, TDA2Px, TDA2Ex and TDA2Ex_17x17)
• EMIF ECC Test: This application tests ECC feature of EMIF. ECC is enabled for EMIF defined address and tests if the EMIF data is corrupted for 1bit or 2bit EMIF data and then it checks for 1-bit and 2bit ECC errors are occurred or not. If I access non quanta aligned data or address and then it checks for Address ECC errors are occurred or not. This verifies EMIF ECC Feature. EMIF ECC is not supported for TDA2Ex_17x17 platform.
• OCMC ECC Test: This application tests ECC feature of OCMC. ECC is enabled for OCMC defined address and tests if the OCMC data is corrupted for 1bit or 2bit OCMC data and then it checks for 1-bit and 2bit ECC errors are occurred or not. If I corrupt ECC bits for the defined OCMC address and then it checks for Address ECC errors are occurred or not. This verifies OCMC ECC Feature.
• IPU ECC Test: This application tests ECC feature of IPU L2RAM and L1Data. ECC is enabled for IPU L2RAM/ L1Data for defined address and tests if the data of IPU L2RAM/ L1Data is corrupted for 1bit or 2bit data and then it checks for 1-bit and 2bit ECC errors are occurred or not. This verifies IPU L2RAM and L1Data ECC Feature.
• EMIF ECC Test and OCMC ECC Test are tested on TDA3xx, TDA2xx, TDA2Px and TDA2Ex EVM. IPU ECC Test is tested on TDA3xx EVM.

Note:

1. Make sure macro VISION_SDK_CONFIG is set to 0 in multicore_reset gel files while running ECC example
2. For EMIF ECC Test on TDA2xx/TDA2Px/TDA3xx/TDA2Ex, before connecting the EVM to CCS through JTag, modify the gel files and then reload these gel files as stated below
   Enable the macro ENABLE_ECC in ddr config gel files. i.e., TDA2xx_ddr_config.gel (TDA2xx/TDA2Px), TDA2Ex_ddr_config.gel(TDA2Ex), TDA3xx_ddr_config.gel(TDA3xx)

EDMA Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\edma\edma_polled_mode_test.
• This test case transfers 64 bytes of data from _srcBuff1 to _dstBuff1 but the interrupt is not enabled hence we poll for the IPR bit to be set after triggering the transfer.
• This example is tested on TDA2xx, TDA2Px, TDA2Ex and TDA2Ex_17x17 EVM PG1.0 on Cortex A15 and IPU core and TDA3xx EVM on IPU core.

EPWM Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\epwm\epwm_duty_cycle_test_app.
• The PWM test application sets a particular duty cycle in PWMSS1 output A (EHRPWM1A) which can be verified through external pin probing. In the current application, the duty cycle is set to 25% with a frequency of 1 KHz. The same can also be verified by checking the application ends in 10 seconds using PWM period ISR.
• In case of TDA2xx/TDA2Px/TDA2Ex EVM, probe VIN2A_VSYNC0 pin (RU19 pin 12).
• In case of TDA3xx EVM, probe GPMC_BEN0 pin (R9017/M1 of VISU connector).

ESM Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\esm\esm_eve_reset_test_app.
• This app runs from Cortex M4 (on TDA3xx) and is used test ESM configured in normal mode. The application programs ESM module to generate interrupt when EVE is given a reset. First, application configures ESM module for generation of interrupt to IPU core on detection of EVE CPU reset. Then it waits for EVE CPU reset to happen. It prints status of the application on the UART console.
• Note: Before running the binary loaded on CortexM4_IPU1_C0, make sure to connect to the EVE core.
• This example is tested on TDA3xx EVM.

GPIO Interrupt Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\gpio\gpio_interrupt.
• The GPIO Test example is a simple test running from a15 core of tda2xx EVM and m4 core 0f tda3xx EVM to show how to read from GPIO pin from a CPU and to demonstrate the GPIO interrupt usage when the input state changes. The application provides user interface through Uart console to select the type of interrupt change. The application provides user to configure GPIO, to detect four types of input state change (LOW, HIGH, RISING EDGE and FALLING EDGE). Below are the pins to be used in the example. A15 core prints the status of the pin on the Uart depending on the status of the pin and the type, GPIO is configured to detect input.
• On TDA2xx/TDA2Px EVM GPIO1 IP’s pin 15 is used. On the EVM this pin comes out on a DCAN1 Rx pin with a mux mode of DCAN1 pins.
• On TDA3xx EVM GPIO1 IP’s pin 10 is used. On the EVM this pin comes out on a DCAN1 Rx pin with a mux mode of DCAN1 pins.

GPIO Toggle Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\gpio\gpio_toggle.
• The GPIO Test example is a simple test running from a15 core of tda2xx, tda2ex and TDA2Ex_17x17 EVM and M4 core of tda3xx EVM to show how to toggle a GPIO pin from a CPU. Below are the pins to be used for probing. These pins can be probed to get a square wave when the app is running continuously. This example does not use any interrupt.
• On TDA2xx/TDA2Px, TDA2Ex and TDA2Ex_17x17 EVM GPIO1 IP’s pin 14 is used. On the EVM this comes out on a DCAN1 TX pin with a mux mode of DCAN1 pins.
• On TDA3xx EVM GPIO4 IP’s pin 9 is used. On the EVM this comes out on a DCAN1 TX pin with a mux mode of DCAN1 pins.

GPMC Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\gpmc\nor_read_write.
• This app runs on Cortex M4 Core of TDA2xx, TDA2Px and TDA3xx. GPMC configuration is done to access the NOR flash. The NOR flash can be accesses in memory mapped mode. An EDMA transfer is setup to copy the content of NOR flash to a DDR location.
• This example is tested on TDA2xx, TDA2Px and TDA3xx EVM PG1.0.

I2C LED Blink Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\i2c\i2c_led_blink.
• The I2C LED test is an example running either from CORTEXA15 or CORTEXM4 core to write to an I2C slave device on the EVM and getting a visible indication by LEDs going on and off. Below are the I2C slave devices connected to 4 LEDs called USER_LED1/2/3/4. When a value of 0x00 and 0xF0 is written to this device over I2C0 the LEDs glow on to off. This example is implemented using I2C driver.
• On TDA2xx, TDA2Px, TDA2Ex and TDA2Ex_17x17 EVM there is a PCF8575 Remote 16 bit I2C Expander (U58) for tda2xx, TDA2Ex EVM PG1.0 and (U66) for TDA2Ex_17x17, connected to LEDs.
• On TDA3xx there is a TCA6424 24 bit Expander (U8006) connected to LEDs.

Mailbox Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\mailbox\mailbox_sender_receiver_app.
• The mailbox test is an example running from A15, M4 and DSP cores to show a mailbox communication between the multiple cores. This example will use the SYSTEM Mailbox2 instance 1 for TDA2xx, TDA2Px, TDA2Ex, TDA2Ex_17x17 and TDA3xx EVM. This example works in two modes: interrupt mode and polled mode.
• In each of the platform one core will run as receiver and all other cores run as sender. The receiver will initialize the mailbox and waits for the new message in polled mode or gets an interrupt when new message is sent. The sender will waits for the queue not full interrupt and sends a message to mailbox. When sender sends the message the receiver receives from the mailbox and prints on UART console.
• On TDA2xx, TDA2Px, TDA2Ex and TDA2Ex_17x17 DSP, M4 run sender app and A15 core will run receiver app.
• On TDA3xx, DSP run sender app and M4 core will run receiver app.

MCAN Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\mcan\mcanEvmLoopback.
• This application runs from Cortex M4 on TDA3xx SR2.0 EVM REV D or on TDA2Px. This application tests MCAN EVM to EVM loopback mode. MCAN EVM to EVM loopback mode tests the external feedback from Tx output to Rx input with transceiver.
• In this mode, MCAN is tested by connecting the CAN Transceiver of two boards as shown below. In this mode, the board 1(Say “MCAN node configured as Rx”) will receive the data transmitted from board 2 (Say “MCAN node configured as Tx”).
• Steps to run the application:
  • Load the application on one board and then run the Rx option.
    • In this option, CAN node will wait for incoming CAN messages
  • Load the application on other board and then run the Tx option
    • Tx option will send 15 CAN-FD messages with fixed CAN ID and with various changing payload size and then print status on the UART console.
  • After reception, Rx side of the application validates the received CAN messages and then prints results accordingly on the UART console.
• Make sure below connections are made prior to running the application(Board 1 => Board 2):
  • For TDA3xx Rev. D EVM:
    • J6120/CANBUS2 pin 1 => J6120/CANBUS2 pin 1 (CAN_H)
    • J6120/CANBUS2 pin 2 => J6120/CANBUS2 pin 2 (GND)
    • J6120/CANBUS2 pin 3 => J6120/CANBUS2 pin 3 (CAN_L)
  • For TDA2Px EVM:
    • J20/DCAN1 pin 3 => J6120/DCAN1 pin 3 (CAN_L)
    • J20/DCAN1 pin 4 => J6120/DCAN1 pin 4 (CAN_H)
    • J20/DCAN1 pin 5 => J6120/DCAN1 pin 5 (GND)
• NOTE:
  • Arbitration Phase Bitrate: 1Mbps and Data Phase Bitrate: 5Mbps
  • If application is running on TDA2Px, please run primary A15 core prior to running MCAN application.

MCASP Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\mcasp\mcasp_transmit.
• The mcasp test is an example running on tda2xx/tda2ex/TDA2Ex_17x17 A15 and M4 core and tda3xx M4 Core.. This example demonstrates the mcasp as master to run at 10MHz bit clock frequency performing specific functional requirements. The mcasp outputs two different patterns on both the serializers. The output can be viewed on the CRO. Serializer 0 and Serializer 1 should yield the output frequency equal to (1/8th) and (1/4th) of Bit Clock respectively. These frequency ratios depend on the data patterns that are sent to particular serializers. In this case, for Serializer 0, data pattern is ‘0xFF’ and data pattern for Serializer 1 is ‘0xCC’.

MCSPI Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\mcspi\mcspiMasterSlave.
• The application configures the Dat0 and Dat1 line as per the connection shown above. One of the EVM should be the master and other one slave. Load the binaries appropriately and execute the slave first. The slave will be waiting for data, start the master application. Once after receiving the data, slave will verify it and then displays the result on the CCS console.

MMC SD Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\mmcsd\mmc_raw_access.
• This application configures the eMMC chip connected on the EVM, to one of the MMC/SD interface.
• The example will write a pattern to first page, read it back and compares for the data integrity.

Note: Make sure that the switch 3 in SW6 is switched on to select eMMC.

A15 MMU Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\mmu\a15_data_validation.
• The mmu data validation test is an example that runs on A15 core and demonstrates A15 Cache and MMU operations. This application is build and tested on TDA2xx, TDA2Px platform.
• The application first enables the L1 and L2 cache for A15. Then the application does the MMU configuration and writes data at the virtual address 0xD0000000. After this the MMU is disabled and the data is read from the physical address 0x90000000 and the data integrity is checked. Application prints a success if the data matches and failure otherwise.

MMU TLB Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\mmu\mmu_tlb_twl.
• The MMU example runs from DSP/EVE core. In this example For DSP writes the pattern data at physical address 0xB0000000 and 0x82000000 and then configures MMU TLB (Translation Look aside Buffer) and MMU TWL(Table walk through logic) to map these physical addresses to virtual addresses 0x81000000 and 0xA0000000 as preserved entries to protect them against global flush. Then DSP then does the global flush and reads the data from virtual address. If the pattern matches as written to physical address then the MMU is configured successfully and entries are protected against global flush. On success the message is printed on CCS console. If the pattern does not match test failure message is displayed on the CCS console. This example is tested on TDA2xx/TDA2Px EVM PG1.0, TDA2Ex and TDA2Ex_17x17 EVM and TDA3xx EVM PG1.0.
• For mmu_tlb_twl_app_arp32 on TDA2xx, TDA2Px, Before connecting the EVM to CCS through JTag, modify the gel files and then reload these gel files as stated below.
• For TDA2xx, TDA2Px, Enable the macro EVE_SW_CONFIG in TDA2xx_multicore_reset.gel

MMU Fault Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\mmu\translation_fault_handle.
• The MMU example runs from DSP core and A15 (on TDA2xx, TDA2Px/TDA2Ex/TDA2Ex_17x17) / M4 (on TDA3xx) and requires A15 (on TDA2xx, TDA2Px /TDA2Ex/TDA2Ex_17x17) / M4 (on TDA3xx) binary to be running before running DSP binary. This example demonstrates the case of handling translation fault. Here DSP configures MMU for required memory mapping and tries to access the memory which is not configured either in TLB or TWL. This results in translation fault sending an interrupt to cortex A15 (on TDA2xx/TDA2Px/TDA2Ex/TDA2Ex_17x17) / M4 (on TDA3xx) and DSP core halts. Cortex A15(on TDA2xx/TDA2Px/TDA2Ex/TDA2Ex_17x17) / M4 (on TDA3xx) on receiving the interrupt resets the DSP core and bring DSP core out of reset. DSP core then prints the test successful message on the CCS console. This example is tested on TDA2xx, TDA2Px, TDA2Ex , TDA2Ex_17x17 and TDA3xx EVM PG1.0.

OCMC Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\ocmc\ocmc_basic.
• This test runs from M4 and CORTEXA15 (on TDA2xx, TDA2Px & TDA2Ex/TDA2Ex_17x17) / DSP (on TDA3xx). M4 gets the virtual address pointer and writes a sub frame and sends a message to CORTEXA15 (on TDA2xx, TDA2Px & TDA2Ex/TDA2Ex_17x17) / DSP ( on TDA3xx) using mailbox indicating the sub frame write completion and keeps waiting till it gets a read completion message from CORTEXA15 (on TDA2xx, TDA2Px & TDA2Ex/TDA2Ex_17x17) / DSP ( on TDA3xx). CORTEX-A15 (on TDA2xx, TDA2Px & TDA2Ex/TDA2Ex_17x17) / DSP (on TDA3xx) then reads the sub frame and sends a message to M4 with last word read as the message. The same continues for other two sub frames and the M4 prints the test pass or failure message on the UART terminal. This test also gives interface for the user using UART to configure OCMC ECC mode.

PCIE Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\pcie\write_loopback.
• This app does board to board communication and runs from Cortex A15 on both boards. First both the boards wait to establish the link. When link gets established, RC will write data on EP side. EP will then read the data written and write it back to RC. RC will then compare the data which is written back with the data it wrote on EP. If the data matches then test is reported as success otherwise failure is reported.
• This example is tested on TDA2xx EVM PG1.0, TDA2Px, TDA2Ex and TDA2Ex_17x17 EVM

QSPI Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\qspi\qspi_test.
• This example is tested on TDA2xx, TDA2Px, TDA2Ex, TDA2Ex_17x17 and TDA3xx EVM PG 1.0. This example reads the QSPI flash device ID and Manufacturer ID and prints on UART and then erases the flash and writes a pattern in the QSPI flash memory, and reads back the data in memory mapped mode and checks if the patterns match. Repeat the test with different clock frequency and different read commands. Supported combination are 12 MHz 4 pin Normal read, 48 MHz 4 pin Fast read, 64 MHz 4 pin Fast read, 64 MHz 4 pin Dual read, 64 MHz 6 pin QUAD read.

RTI Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\rti\rti_dwwdtest_app.
• This app runs from Cortex M4 (on TDA3xx) and is used test RTI configured as DWWD. The application needs to be run twice to see full DWWD functionality. In first run, application programs RTI to generate reset to the system after specific time out period which is 10 sec. In second run, RTI is configured to generate reset after 10 sec but reset will not be generated as RTI is serviced before the timeout occurs. Application prints UART message when 10 sec are elapsed. However RTI will generate reset after 18 sec as it is not serviced again.
• Note: Before loading app binary second time, disconnect and connect CortexM4_IPU1_C0 core. It will run Gel script under TDA3xx Misc Module configurations-> OnTargetConnect_API which is needed for second run.
• This example is tested on TDA3xx EVM and should be run with gel.

Spinlock Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\spinlock\spinlock_test.
• This example is tested on TDA2xx, TDA2Px, TDA2E, TDA2Ex_17x17 and TDA3xx EVM PG1.0. This test runs on CortexA15, DSP and M4 core for TDA2xx, TDA2Px, TDA2Ex and TDA2Ex_17x17 and runs on DSP and M4 core for TDA3xx. Here the core which is run first acquires the lock and other cores ran after this keep waiting for the lock to get release. Each core prints the status of the lock on the UART terminal

Timer Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\timer\timer_app.
• This app runs from Cortex A15, Cortex M4 & C66x on TDA2xx, TDA2Px, TDA2Ex and TDA2Ex_17x17, runs from Cortex M4 & C66x on TDA3xx.
• On TDA2xx, TDA2Px, TDA2Ex, TDA2Ex_17x17 and TDA3xx this app is used to test Timer for different IRQ XBAR instances. The app will be run in a loop for particular core. Firstly the interrupt will be configured for first IRQ XBAR instance. Then Timer is configured for overflow interrupt. Timer will generate interrupt 10 times and count value will become zero. Then the interrupt will be configured for next IRQ XBAR instance and so on. Then success message is printed on UART console.
• This example is tested on TDA2xx EVM PG1.0, TDA2Px, TDA2Ex/TDA2Ex_17x17 EVM PG1.0 and TDA3xx EVM.

UART EDMA Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\uart\uart_edma.
• This app runs from Cortex (on TDA2xx, TDA2Px, TDA2Ex and TDA2Ex_17x17)/ M4 (on TDA3xx) and is used test UART working in the dma mode. The application echoes the characters that user types on the console. UART will send the data to Console using edma and ask user to enter 8 bytes of data. Then the data entered by user will be echoed back to the user using edma.
• This example is tested on TDA2xx, TDA2Px, TDA2Ex, TDA2Ex_17x17 and TDA3xx EVM PG1.0.

UART Interrupt Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\uart\uart_intr.
• This app runs from Cortex M4 and is used test UART working in the interrupt mode. UART will first send data to UART console using THR interrupt. Then the data entered by user will be echoed back using the RHR interrupt.
• This example is tested on TDA2xx, TDA2Px, TDA2Ex, TDA2Ex_17x17 and TDA3xx EVM PG1.0.

UART Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\uart\uart_test.
• This app runs from Cortex A15 (on TDA2xx, TDA2Px, TDA2Ex and TDA2Ex_17x17)/ M4 (on TDA3xx) and is used test UART working for different line characteristics configurations (baud rate, parity, stop bit and word length). Parity is set to “None” in the app. Please select parity as “None” while opening Terminal. UART is configured depending on the test case Id. User is asked to enter some data on UART console which is echoed back.
• This example is tested on TDA2xx, TDA2Px, TDA2Ex, TDA2Ex_17x17 and TDA3xx EVM PG1.0.

WDTimer Example

• This example is present in <PDK_INSTALL>\packages\ti\csl\example\wdtimer\wdtimer_reset_app.
• This app runs from Cortex A15 and is used test watchdog timer. This example will use the WDTimer instance 2 for TDA2xx, TDA2Px. WDTimer setup is done for reset period of around 4s. In order to prevent reset user should continuously enter data from UART terminal with gap less than 4s. If no data is entered for reset period, the A15 core will be reset.
• This example is tested on TDA2xx, TDA2Px, TDA2Ex and TDA2Ex_17x17 EVM PG1.0.