Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.

Unified Network Processor Interface

From Texas Instruments Wiki
Jump to: navigation, search
Welcome to the Unified Network Processor Interface WiKi.

The Wiki contains application examples, guides and documentation covering those extra steps you might need help with. The Wiki is not only managed by Texas Instruments employees but also E2E community members. Anyone can share, edit and make use of the information posted here.

Unified NPI Protocol

TI's Unified Network Processor Interface (NPI) is used for establishing a serial data link between a TI SoC and external MCUs or PCs. This is mainly used by TI's network processor solutions. NPI currently supports UART and SPI. TI provides the source code for Unified NPI, it can be found under /Components/NPI/unified within TI's SDK. Please note that this does not include the files included under /Components/NPI/ which is another version of NPI.

NPI is implemented as its own TI-RTOS task, and supports inter task communication and routing to the underlying serial interface drivers. See the diagram below for details:

NPI_breakdown.PNG

Unified NPI offers some improvements over NPI in that it offers a unified frame format that is used by all transport layers. More information about this version can be found here: http://processors.wiki.ti.com/index.php/NPI

NPI Roles

Each processor in an NPI solution must occupy the master or slave role. The TI wireless SoC generally occupies the slave role in the network processor examples included in the SDK.

Handshaking/Power Management

In order to properly manage the power domains of the device, there must be a way for an external host to wake the network processor from low power modes. This is done through the inclusion of “master ready”, MRDY, and “slave ready”, SRDY, signals which are defined below. Note when using SPI, MRDY and SRDY must be used for handshaking reasons.

Term (acronym) Definition
Master Ready (MRDY) A GPIO pin whose logic level indicates the state of the master processor. MRDY is an active low (low true) signal. An MRDY event indicates that the master processor is ready to send or receive data. See NPI timing diagrams for more info
Slave Ready (SRDY) A GPIO pin whose logic level indicates the state of the slave processor. SRDY is an active low (low true) signal. An SRDY event indicates that the slave processor is ready to send or receive data.

In the slave role, MRDY is an input pin controlled by the protocol master, and SRDY is an output pin controlled by the TI wireless SoC. Slave or master may initiate the transaction. The initiator is determined by beginning the handshake first. This sequence of setting MRDY and SRDY pins comprises a “handshake” process to guarantee both devices are awake and ready to send and/or receive data. Note that the handshake is always terminated by the master when MRDY is raised, the slave responds by raising SRDY, and the transaction is complete.The figures below illustrate both slave and master initiating a transfer.


Master Initiates
Master initiates flow.PNG
Master initiates.png
Slave Initiates
Slave initiates flow.PNG
Slave initiates.png
Bidirectional Messaging
Bidirectional messaging flow.PNG
Note: see the bidirectional messaging section for more information


Packet Format

General Frame Format

SOF

Byte 0 - 1

Byte 2

Byte 3

Byte 4 - (LEN+3)

FCS

Start of Frame

Length [13:0]
Reserved [15:14]

Type / Sub-System

Command ID

Payload

Frame Check Sequence

The Unified NPI packetformat is explained below:

  • Start of Frame(SOF) is set to be 0xFE (254)
  • Length field is 2 bytes long in little-endian format (so LSB first).
  • CMD0 is a 1 byte field that contains both message type and subsystem information
    • Bits[7:5]: Message type, see the message type section for more info.
    • Bits[4:0]: Subsystem ID field, used to help NPI route the message to the appropriate place.
    • See the link here for message type and subsystem ID field info
  • CMD1 is a 1 byte field that contains the opcode of the command being sent
  • Payload is a variable length field that contains the parameters defined by the command that is selected by the CMD1 field. The length of the payload is defined by the length field.
  • Frame Check Sequence (FCS) is calculated by doing a XOR on each bytes of the frame in the order they are send/receive on the bus (the SOF byte is always excluded from the FCS calculation):
    • FCS = LEN_LSB XOR LEN_MSB XOR D1 XOR D2 ... XOR Dlen



How the General Frame Format is used:


Note that all the links to the respective subsystems are clickable. Follow the links to learn more about each subsystem.

Peripherals RF4CE Bluetooth Low Energy ZigBee

SOF

LEN

Type

SubSystem

0x10

CMD

Payload

FCS

SOF

LEN

Type

SubSystem

0x0A
0x0B

CMD

Payload

FCS

SOF

LEN

Type

SubSystem

0x15
0x16

CMD

Payload

FCS

SOF

LEN

Type

SubSystem

0x02
-
0x09

CMD

Payload

FCS

Synchronous Request

SOF

LEN

Type

SubSystem

001

CMD

Payload

FCS

Asynchronous Request

SOF

LEN

Type

SubSystem

010

CMD

Payload

FCS

Synchronous Response

SOF

LEN

Type

SubSystem

011

CMD

Payload

FCS

Message Types

There are three message types supported by Unified NPI. The type of message being sent is often dependent on which processor initiated the transaction.

Code Message Type
0x01 Synchronous Request (SREQ)
0x02 Asynchronous Request/Indication (AREQ/AIND)
0x03 Synchronous Response (SRESP)


Synchronous Messages A Synchronous Request (SREQ) is a frame, defined by data content instead of the ordering of events of the physical interface, which is sent from the Host to NP where the next frame sent from NP to Host must be the Synchronous Response (SRESP) to that SREQ.

Note that once a SREQ is sent, the NPI interface blocks until a corresponding response(SRESP) is received.

Asynchronous Messages Asynchronous Request – transfer initiated by Host Asynchronous Indication – transfer initiated by NP.

Both types of asynchronous messages use the same message type bit field (0x02). The type of message (request/indication) depends on which processor initiated the transaction.

Bidirectional Messaging

With any protocol that allows asynchronous messaging, where a signal transition denotes the start of a message as with MRDY and SRDY, there are inherent collisions between messages. Instead of requiring intricate collision handling, the NP framework allows for bidirectional messaging to occur. This means that data can be sent from the AP to NP and from NP to the AP in the same message window regardless of the handshake order.

While reducing collision handling, bidirectional messaging adds some complexity to what operations must be performed or initiated by each device. For every AIND the NP initiates, it must prepare to read as well as write when MRDY is asserted. For every REQ, the AP must prepare to read as well as write once SRDY is asserted. Each device will also need to handle any FIFOs that could potentially be overrun during a message and check at the end of every message to see what, if anything, has been received.

Note that bidirectional messaging is enabled regardless of power savings options

NPI Supported Drivers

Currently TI has provided implementations for the NPI protocol using UART and SPI drivers on CC26xx devices. These drivers are provided in source format and can be found in the Components/npi/unified folder of the TI SDK. There are certain driver specific settings that can be configured, these are defined in the following sections.

Initially the NPI task doesn't initiate the MRDY and SRDY pins, letting them default to IOID_UNUSED. It is up to the application layer to define these pins for example to use the up and down keys of the SmartRF06 board: The below code should be placed in the application layer task.

#define MDRY_PIN            Board_KEY_UP
#define SDRY_PIN            Board_KEY_DOWN
...
// NP Parameters for opening serial port to NP
static NPI_Params portParams;
...
#ifdef NPI_USE_UART
  NPITask_Params_init(NPI_SERIAL_TYPE_UART, &portParams);
#elif defined(NPI_USE_SPI) 
  NPITask_Params_init(NPI_SERIAL_TYPE_SPI, &portParams);
#else
#error "Must define NPI_USE_UART or NPI_USE_SPI for any project including NPI"
#endif //NPI_USE_UART
  portParams.stackSize = NPI_TASK_STACK_SIZE;
  portParams.mrdyPinID = MDRY_PIN;
  portParams.srdyPinID = SDRY_PIN;
  portParams.bufSize   = 530;
 
  // Kick off NPI
  NPITask_open(&portParams);


UART

To use this configuration, the UART project configuration should be selected(if available). This configuration allows low power modes through the inclusion of the MRDY and SRDY signals. If a pre-made project configuration is not included in the SDK, then NPI_USE_UART must be defined as well as including the CC26xx UART drivers. If power management is needed, be sure to define POWER_SAVING and use the MRDY/SRDY signals. The NPI task sets up the UART port with the following settings

UART Parameters Default Value
Port CC26xx_UART0
Baud Rate 115200
Data Length 8
Parity None
Stop Bits 1
Flow Control None

Changing the Baud Rate

Changing the baud rate can be done in the NPITask_Params_init() function as below:

  1. #if defined(NPI_USE_UART)
  2.     UART_Params_init(&params->portParams.uartParams);
  3.     params->portParams.uartParams.readDataMode = UART_DATA_BINARY;
  4.     params->portParams.uartParams.writeDataMode = UART_DATA_BINARY;
  5.     params->portParams.uartParams.readMode = UART_MODE_CALLBACK;
  6.     params->portParams.uartParams.writeMode = UART_MODE_CALLBACK;
  7.     params->portParams.uartParams.readEcho = UART_ECHO_OFF;
  8.     params->portParams.uartParams.baudRate= 460800;

SPI

In order to allow full duplex communication, the SPI configuration requires the use of MRDY and SRDY regardless of whether or not power management is enabled. In order to use SPI, use the project configuration included in the SDK (if applicable). If a project configuration is unavailable, then NPI_USE_SPI should be defined. If power savings is needed, be sure to define POWER_SAVINGS.

The NPI task will initialize the SPI with the following parameters

SPI Parameters Default Value
Port CC26xx_SPI1
Bit Rate 800000
Data Length 8

Changing the Bit Rate

Changing the bit rate can be done in the NPITask_Params_init() function as below:

  1. #elif defined(NPI_USE_SPI)
  2.     SPI_Params_init(&params->portParams.spiParams);
  3.     params->portParams.spiParams.mode = SPI_SLAVE;
  4.     params->portParams.spiParams.bitRate = 8000000;
  5.     params->portParams.spiParams.frameFormat = SPI_POL1_PHA1;

Sample Logic Captures

UART
Asynchronous Request

Asynchronous Request


Asynchronous Indication

Asynchronous Indication


Note that synch messages follow the same format, but are blocking and have a different CMD0 field.

SPI
To be completed



Implementing An NPI Master

As stated above the TI Wireless SoC device operates as an NPI slave. This means the external MCU must implement the master role. When developing for the NPI master role on an external MCU there are a couple things to keep in mind:

  • The NPI master controls MRDY, and thus controls when the NPI frame has completed. Even when the slave is sending data, the master must use the payload format to determine how many bytes it expects and raise MRDY when it has rx'd them.
  • Since all packets use the same frame format regardless of protocol the NPI master can use the frame format to determine when to raise MRDY

An example of an NPI master implementation on UART can be found under /Components/npi/unified/npi_tl_uart_m.c
NPI_MASTER must also be defined as a preprocessor symbol to use the above file.

When using MRDY/SRDY it is important to remember the following rules:

  1. Each device must always initiate a read prior to asserting its respective output pin (MRDY wrt AP) regardless of the state of the its respective input pin (SRDY wrt AP).
  2. Each device can only begin to write (or clock data in the case of SPI) once both MRDY and SRDY are asserted.

E2e.jpg For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article Unified Network Processor Interface here.
Hyperlink blue.png Links

Amplifiers & Linear
Audio
Broadband RF/IF & Digital Radio
Clocks & Timers
Data Converters

DLP & MEMS
High-Reliability
Interface
Logic
Power Management

Processors

Switches & Multiplexers
Temperature Sensors & Control ICs
Wireless Connectivity