OMAP-L13x/C674x Resources and FAQ
How do I get started?
Processor SDK for OMAPL138 Processors for Linux and TI-RTOS Support - Supported Devices: OMAP-L138, OMAP-L132, C6748, C6746, C6742
Processor SDK for OMAPL137 Processors for Linux and TI-RTOS Support - Supported Devices: OMAP-L137, C6747, C6745, C6743
Processor SDK Training and Guides
Note: Refer to the “Technical documentation” section of each device’s product page for a complete list of related documentation. For example:
Which drivers are available for each device?
OMAP-L138/C6748: EMAC, GPIO, I2C, McASP, McBSP, MMCSD, SPI, UART, USB
OMAP-L137/C6747: EMAC, GPIO, I2C, McASP, MMCSD, SPI, UART, USB
Where are the PDK example projects?
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.
For the OMAP-L138 and C6748 there are also ProjectSpecs (CCS projects) available in the zip below.
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?
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.
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.
IPC: How to configure the cache and memory map on DSP while ARM is running Linux?
How do I debug IPC issues?
How to modify the SPI Loopback example and LCDK to work in Master/Slave mode?
How to configure GPIO example on DSP with Linux running on the 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
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.
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
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.
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.
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.
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.
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.
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.