Processor SDK RTOS QSPI-McSPI

From Texas Instruments Wiki
Jump to: navigation, search


RTOS Software Developer Guide QSPI-McSPI



Overview

User Interface

Application

Debug

Introduction

SPI driver enables communication for general SPI, MCSPI (Multichannel SPI) and QSPI (Quad SPI) based peripherals on board through common API to application.
MCSPI is a generic full-duplex interface supporting transmit and receive of data over SPI bus. QSPI a variant of SPI supports four receive data lanes. Driver supports configuration for either single, dual or quad data lanes

Modes of Operation

Following modes of operations are supported:

SPI_MODE_BLOCKING
SPI_transfer() API blocks code execution until transaction has completed. By default, SPI driver operates in blocking mode. This ensures only one SPI transaction operates at a given time. This mode is supported in both interrupt or non-interrupt configurations.

SPI_MODE_CALLBACK
SPI_transfer() API returns without waiting for completion of transaction in this case. Callback function registered by application is invoked once transaction is complete.This mode is supported only in interrupt configuration.

Driver Configuration

Board Specific Configuration

All board specific configurations eg:enabling clock and pin-mux for SPI pins are required before calling any driver APIs.By default Board_Init() API supports all initialization sequence for TI supported EVMs. In addition it initializes UART instance for Console/STDIO.Refer Processor SDK RTOS Board Support for additional details.Once board specific configuration is complete SPI_init() API should be called to initialize driver.

SoC Specific Configuration

All SoC specific configurations (eg: SPI module registers base address, interrupt configurations, etc.) can be set using SPI_socSetInitCfg() SoC driver API before calling any SPI driver APIs. The default SoC specific configurations can be retrieved using SPI_socGetInitCfg() SoC driver API. 

SPI Configuration Structure

The SPI_soc.c file binds driver with hardware attributes on the board through SPI_config[] structure. This structure must be provided to the SPI driver. It must be initialized before the SPI_init() function is called and cannot be changed afterwards. For details about individual fields of this structure, see Doxygen help by opening PDK_INSTALL_DIR\packages\ti\drv\spi\docs\doxygen\html\index.html.

Driver  requires common SPI_config[]  to configure hardware attributes of MCSPI and QSPI peripherals on SOC and board. First all MCSPI related hardware attributes is defined  followed by QSPI hardware attributes. Application will need to include appropriate offset to instance while invoking SPI_open() API..

APIs

API Reference for application:

#include <ti/drv/spi/SPI.h>

SPI IP V1 driver also supports multi-channel API's:

#include <ti/drv/spi/MCSPI.h> 

Open SPI
...
Board_init(boardCfg);
...
SPI_socGetInitCfg(peripheralNum, &spi_cfg);
...
SPI_socSetInitCfg(peripheralNum, &spi_cfg);
SPI_Params_init(&spiParams);
spiParams.transferMode = SPI_MODE_BLOCKING;
spiParams.transferCallbackFxn = NULL;
handle = SPI_open(peripheralNum, &spiParams);

SPI IP V1 driver also supports multi-channel open API's:

...
Board_init(boardCfg);
...
MCSPI_Params_init(&spiParams);
spiParams.transferMode = SPI_MODE_BLOCKING;
spiParams.transferCallbackFxn = NULL;
handle = MCSPI_open(peripheralNum, channel, &spiParams);


At this point SPI driver is ready for data transfer in blocking mode on specific instance identified by handle. Pseudo/Sample code for SPI read/write transaction is included below. Refer example for additional details

...
spiTransaction.count = n;    /* Transfer Length */
spiTransaction. txBuf = transmitBuffer; /* Buffer to be written */
spiTransaction.rxBuf = NULL;  /* Buffer holding the received data */
transferOK = SPI_transfer(spi, &spiTransaction); /* Perform SPI transfer */
if (!transferOK) {
/* SPI transaction failed */
}

SPI IP V1 driver also supports multi-channel transfer API's:

...
spiTransaction.count = n;    /* Transfer Length */
spiTransaction. txBuf = transmitBuffer; /* Buffer to be written */
spiTransaction.rxBuf = NULL;  /* Buffer holding the received data */
transferOK = MCSPI_transfer(spi, &spiTransaction); /* Perform SPI transfer */
if (!transferOK) {
/* SPI transaction failed */
}
NOTE

SPI_open API supports configuration of data word length in the SPI_Params. Currently IP V1 driver (for AM3/4/5 devices) supports 8/16/32-bit word length, IP V0 driver (for Keystone devices) supports 8/16-bit word length.

Examples

SPI

Name
Description
Expected Results

SPI_FlashReadWrite

Example application

Sample application demonstrating read and write of data to a NOR flash device connected over SPI interface. By default, write test is disabled, user can enable write test by defining TEST_SPI_NOR_WRITE in test/src/SPI_board.h. If write test is enabled, write transaction is verified  for correctness by reading contents back.

Following prints on console expected:

Pass criteria:

All tests have passed.

SPI_TestApplication


Driver unit test application to validate features and interfaces for SPI driver

Following prints on console expected:
Pass criteria:
All tests have passed.
spiLoopback example


Example application to validate features and interfaces for SPI driver in loopback mode. Configures the SPI in loopback mode, transmits a test pattern and receives it back from SPI.


Note: This example is intended to demonstrate the SPI LLD API usage on the HW platforms where SPI memory is not available. Currently this example is supported on OMAPL138/C6748 platforms.

Following prints on console expected:
Pass criteria:
All tests have passed.



QSPI

Name
Description
Expected Results

QSPI_FlashReadWrite

Example application

Sample application demonstrating read and write of data to a flash device connected over QSPI interface. Write transaction is verified  for correctness by reading contents back.

Following prints on console expected:

Pass criteria:

All tests have passed.

QSPI_TestApplication


Driver unit test application to validate features and interfaces for QSPI driver

Following prints on console expected:
Pass criteria:
All tests have passed.



MCSPI

Name
Description
Additional EVM Configuration
Expected Results
MCSPI_Serializer Example application

Sample Application demonstrating reading data generated from industrial input module.  Application uses GPIO pins to assert load signal in order to generate date from industrial input module.

AM57x IDK EVM : 

Short pins 1 and 2 on header J37(Industrial I/O)

AM335x ICE v2:

Short pins 1 and 2 on  header J14(Industrial I/O)

AM437x IDK EVM:
Short pins 1 and 2 on header J1(Industrial I/O)


   

Following prints  on console expected:

Pass criteria:

All tests have passed.

MCSPI_Dma_Serializer Example application

Sample Application demonstrating reading data generated from industrial input module through EDMA.  Application uses GPIO pins to assert load signal in order to generate date from industrial input module.

AM57x IDK EVM : 

Short pins 1 and 2 on header J37(Industrial I/O)

AM437x IDK EVM:

Short pins 1 and 2 on  header J1(Industrial I/O)


   

Following prints  on console expected:

Pass criteria:

All tests have passed.

MCSPI_SerialFlash

Sample Application demonstrating writing and reading data from the serial flash through MCSPI EDMA interface.

AM335x GP EVM:

Set the EVM in profile 2 (SW8[1] = OFF, SW8[2] = ON, SW8[3:4] = OFF)


   

Following prints  on console expected:

Pass criteria:

All tests have passed.

MCSPI_slavemode example application

Application demonstrates slave recieve and transmit features of McSPI. Application use case requires two EVMs. One acts as Master and Another as slave. McSPI connections information and addtional details are as follows.

No of Boards Required:

2

Connection requirements:

Consider EVM1 as Master and EVM2 as slave.
MasterSPI_CLK -------SlaveSPI_CLK
MasterSPI_D0----------SlaveSPI_D1
MasterSPI_D1----------Slave SPI_D0
MasterSPI_CS0--------SlaveSPI_CS0
DGND----------------------DGND

Additional Requirements:

Run "MCSPI_SlaveMode_SlaveExample_<BoardType><arm/c66x/m4>ExampleProject" first on Slave EVM and then "MCSPI_SlaveMode_MasterExample<BoardType>_<arm/c66x/m4>ExampleProject" on Master EVM.


Note:

A DGND connection may be required from expansion connector on each board to make sure the data transfer is proper.


Pin Connections:

IDK AM571x or IDK AM572x:
EVM1(master)==== EVM2(slave)
J21-Pin24(CLK) ----- J21-Pin24(CLK)
J21-Pin26(MISO) --- J21-Pin28(MISO)
J21-Pin28(MOSI) --- J21-Pin26(MOSI)
J21-Pin30(CS) ------ J21-Pin30(CS)
J21-Pin22(DGND) -- J21-Pin22(DGND)

 

IDK AM437x:

EVM1(master)====EVM2(slave)
J16-Pin24(CLK) ----- J16-Pin24(CLK)
J16-Pin26(MISO) --- J16-Pin28(MISO)
J16-Pin28(MOSI) --- J16-Pin26(MOSI)
J16-Pin30(CS) ------ J16-Pin30(CS)
J16-Pin22(DGND) -- J16-Pin22(DGND)


ICEv2 AM335x:
EVM1(master)====EVM2(slave)
J3-Pin12(CLK)---------J3-Pin12(CLK)
J3-Pin14(MIS0)------- J3-Pin16(MISO)
J3-Pin16(MOSI)------- J3-Pin14(MOSI)
J3-Pin18(CS)-----------J3-Pin18(CS)
J3-Pin2(DGND)--------J3-Pin2(DGND)


BBB AM335x:
EVM1(master)====EVM2(slave)
P9-Pin31(CLK)-------P9-Pin31(CLK)
P9-Pin29(MISO)------P9-Pin30(MISO)
P9-Pin30(MOSI)------P9-Pin29(MOSI)
P9-Pin28(CS)---------P9-Pin28(CS)
P9-Pin1(DGND)-------P9-Pin1(DGND)


K2G EVM:
EVM1(master)====EVM2(slave)
J12-Pin9(MISO)-------J12-Pin9(MISO)
J12-Pin11(MOSI)------J12-Pin11(MOSI)
J12-Pin13(CLK)------J12-Pin13(CLK)
J12-Pin15(CS0)---------J12-Pin15(CS0)
J12-Pin49(DGND)-------J12-Pin49(DGND)

On slave EVM console:
SPI initialized
Slave: PASS: Txd from master SPI


On Master EVM console:
SPI initialized
Master: PASS: Txd from slave SPI
Done

Additional References

Document Location
API Reference Manual $(TI_PDK_INSTALL_DIR)\packages\ti\drv\spi\docs\doxygen\html\index.html
Release Notes $(TI_PDK_INSTALL_DIR)\packages\ti\drv\spi\docs\ReleaseNotes_SPI_LLD.pdf