The PDK contains Windows and Linux scripts used to create example and test CCS projects for all PDK sub-components. The following guide details how the scripts are used to create the CCS projects.

PDK Example and Test Project Creation

For the OMAP-L138 and C6748 there are also ProjectSpecs (CCS projects) available in the zip below.

omapl138_c6748_ccs_projectspecs.zip

Extract the above zip and place the ccs_examples folder in ~ \pdk_omapl138_1_0_11\. They can then be directly imported from CCS.

More information on ProjectSpecs can be found here: ProjectSpecs in CCS

The pdkProjectCreate.bat script says it cannot find the specified path

Make sure you have run the pdksetupenv script first.
If using a different version of CCS than what is specified in the Processor SDK Release Notes, you will need to update the CCS path in the pdkProjectCreate script to point to your CCS directory.

How do I link libraries with the Processor SDK PDK?

How do I boot my application using the ROM Bootloader?

Using the OMAP-L132/L138 Bootloader Application Report

OMAPL138/C6748 ROM Bootloader Resources and FAQ

Using the OMAP-L1x7 Bootloader

Using the TMS320C6748/C6746/C6742 Bootloader

Using the TMS320C6747/45/43 Bootloader

Using the Serial Flash Utilities

The LCDK out-of-box demo is not working

There have been reports on the E2E forums of the LCDK flash contents being corrupted. Due to this we have provided the binaries used by the board manufacturer to flash and run the demo. If you run into the same issue, you can restore your flash with the factory image or run diagnostics if you wish to just confirm board functionality. The procedure is described in the “Procedure to Flash and Boot the LCDK” section of the following application note.

OMAP-L138/C6748 Low-Cost Development Kit User’s Guide

Is there an eMMC driver and example?

The MMCSD driver and example in Processor SDK can be modified to work with eMMC by following the procedure in the following guide.

Enabling eMMC on OMAPL138 and C6748.pdf

IPC: How to configure the cache and memory map on DSP while ARM is running Linux?

Linux IPC: How to configure DSP memory map for cache with Linux running on ARM on OMAPL138

How do I debug IPC issues?

Debugging Tools and Techniques With IPC3.x

How to modify the SPI Loopback example and LCDK to work in Master/Slave mode?

TMS320C6748: Build SPI Loopback example and modify to work in Master/Slave mode

How to configure GPIO example on DSP with Linux running on the ARM?

OMAPL138B-EP: GPIO LED Blink example on C6748 with Linux running on ARM

How to configure cache on c674x when using TI-RTOS?

On C674x, L2 cache is configured by setting the appropriate MAR bits. More information on cache and MAR bits can be found in the TMS320C674x DSP Megamodule Reference Guide

CCS provides a GUI for configuring the cache. To access the GUI, right click on the project’s cfg file > open with > XGCONF > Select “Cache” in the “Outline” window > click “Device-specific Cache support” to open the cache configuration window. Once configured, the cfg file can be viewed with the text editor to see the code changes.

McASP Resources and Training

The McASP Primer Training Series

McASP design guide: Tips, tricks and practical examples

How does the McASP driver work?

The McASP driver exposes a set of APIs to be used by the application layer to send and receive data via the McASP peripheral. The driver also exposes a set of OS abstraction APIs to keep the driver OS-independent. The McASP driver uses the CSL McASP register layer for all McASP MMR access.

The McASP driver also uses the EDMA to move data from memory to the MCASP interface (TX path) and to move data received on the MCASP interface to memory (RX path), on every transfer event from the MCASP.

The EDMA channel controller services the MCASP in the background without requiring any DSP intervention. The EDMA channels can be configured to continuously service the McASP throughout device operation. Each event available to the EDMA has its own dedicated channel and all channels operate simultaneously. The only requirements are to use the proper channel for a particular transfer and to enable the channel event in the Event Enable Register.

When programming an EDMA channel to service the MCASP, it is necessary to know how data is to be presented to the DSP. Data is always provided with some kind of synchronization event as either one element per event (non-bursting) or multiple elements per event (bursting).

The following section provides a high-level overview of the McASP LLD. More detailed information on this can be found in the McASP SDS in the PDK but is provided below for better findability and in a more digestible format.

1. MCASP Driver Initialization

The McASP driver initialization only needs to occur once per application.

mcaspInit

This function initializes the internal driver data structures such as the device objects. Application developers need to ensure they call this before initializing the McASP Peripheral.

2. MCASP Peripheral Configuration

McaspDevice_init

This function initializes the McASP using a sample implementation sequence. It also initializes all instance specific information such as base address of the instance CFG registers, FIFO address for the instance, TX and RX CPU event numbers, TX and RX EDMA event numbers, etc. The function also sets the “inUse” field of the McASP instance module object to “False” so that the instance can be created by the application. Mute buffers are also initialized.

Note: This initialization sequence is only a sample and has been kept at the application level so developers can modify and customize it for their application.

3. Driver Instance Binding

After initializing the McASP, the application needs to bind the driver instance to a hardware instance.

mcaspBindDev

This function should be called after MCASP device initialization. It acquires the device handle for the specified McASP instance and configures the instance with the specified parameters (or default parameters, if there is no external configuration). Each driver instance corresponds to one hardware instance of the McASP. This function performs the following:

Check if the instance being created is already in use by checking “inUse”.
Update the instance object with the user supplied parameters.
Initialize all the channel objects (TX and RX) with default parameters.
Initialize queues to hold the pending frames and currently executing frames (floating queue).
Configure the MCASP to receive the Frame Sync and bit clocks either externally or internally for both receiver and transmitter depending on the user supplied parameters.
Return the device handle.

4. Channel Creation

Once the application has created a device instance, it needs to create a communication channel for transactions with the underlying hardware. The driver allows at most two channels per MCASP instance to be created – a transmit channel, e.g. audio playback, and a receive channel, e.g. microphone input. The application needs to specify the appropriate mode (output or input) when creating a channel.

mcaspCreateChan

The application needs to supply this function with the parameters from chanParams which will characterize the features of the channel, e.g. number of slots, slot width, etc. This function performs the following actions:

Validates the input parameters given by the application.
Checks if the requested channel is already opened or not. If it is already opened then the driver will flag an error to the application else the requested channel will be allocated.
Updates the appropriate channel object with the user supplied parameters.
MCASP is configured with the appropriate word width.
EDMA parameters for the requested channel are setup.
If the global error callback function registration is enabled, the appropriate user supplied function is registered to be called in case of an error.
If the channel creation fails then it will perform a cleanup and also free all the resource allocated by it till now.
If the complete process of channel creation is successful, then it will return a unique channel handle to the application. This handle should be used by the application for further transactions with the channel. This handle will be used by the driver to identify the channel on which the transactions are being requested.

5. I/O Frame Processing

After creating the necessary channel(s), the application can submit I/O packets/bufs (frames) to be loaded for data transfer.

mcaspSubmitChan

The application needs to supply this function with the appropriate channel handle and IOBuf (frame) containing the operation to be performed and required parameters needed for programming the EDMA channels to program the underlying hardware for data transfer. This function performs the following actions:

The input Mcasp_IOBuf frame is validated.
If the driver has sufficient frames then the current frame is loaded in to the pending queue.
Otherwise the frame is programmed into the link PARAMs of the EDMA.
In NON LOOP JOB mode, the first frame is always loaded in to the main transfer channel. The subsequent two frames are loaded into the spare PARAM sets of the EDMA. Also if this is the first frame for the driver then the clocks are started as per the configuration of the channel. Any other frames after this are loaded into the pending queue. These frames will be loaded by the EDMA callback into the appropriate PARAM set of the EDMA.

Asynchronous I/O Mechanism

The MCASP driver allows the application to submit multiple I/O requests without causing it to block while waiting for the previous I/O requests to complete. The application can submit multiple I/O requests using mcaspSubmitChan(). The application callback function registered during the transfer request submission will be called upon transfer completion by the driver. The driver internally will queue the I/O frames submitted to support the asynchronous I/O functionality.

6. Control Commands

The McASP driver supports control commands for device specific functionality that can be utilized by the application. The control commands are prefixed with “Mcasp_IOCTL_” and the complete list can be found in mcasp_drv.h. Typical commands are PAUSE, RESUME, STOP, START, MUTE, etc.

7. Channel Deletion

Once a channel has completed all the transactions, it can be closed to free all allocated channel resources.

mcaspDeleteChan

The application can call this function to delete the specified McASP channel for an instance. This function performs the following actions:

The channel to be deleted is reset.
The reset operation aborts all the packets in the pending queue and also the packets in the current active queue.
The EDMA transfer for this channel is disabled.
The MCASP state machines are stopped.
The interrupt handlers are unregistered.

8. Driver Instance Unbinding/Deletion

Once the instance channels are closed/deleted, the application can unbind/delete the driver instance to free all allocated instance resources.

mcaspUnBindDev

This function performs the following actions:

Check if both the TX and the RX channels are closed.
Update the instance object.
Set the status of the driver instance to “DELETED”.
Set the status of the instance “inUse” to FALSE (so that instance can be used again).

McASP Driver Example

The McASP driver example is an audio loopback example that programs the AIC31 codec and McASP to receive input from the “AUDIO IN” port and loop it back out of the “AUDIO OUT” port.

More information on the McASP driver and example can be found in the Processor SDK RTOS Software Developer’s Guide at the following link.

Processor SDK RTOS Device Drivers - McASP

over 3 years ago

Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

Processors

Processors forum

[FAQ] OMAP-L13x/C674x Resources and FAQ