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
| 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:
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
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.
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.
|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.
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|
There are three message types supported by Unified NPI. The type of message being sent is often dependent on which processor initiated the transaction.
|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.
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);
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|
Changing the Baud Rate
Changing the baud rate can be done in the
NPITask_Params_init() function as below:
params->portParams.uartParams.readDataMode = UART_DATA_BINARY;
params->portParams.uartParams.writeDataMode = UART_DATA_BINARY;
params->portParams.uartParams.readMode = UART_MODE_CALLBACK;
params->portParams.uartParams.writeMode = UART_MODE_CALLBACK;
params->portParams.uartParams.readEcho = UART_ECHO_OFF;
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|
Changing the Bit Rate
Changing the bit rate can be done in the
NPITask_Params_init() function as below:
params->portParams.spiParams.mode = SPI_SLAVE;
params->portParams.spiParams.bitRate = 8000000;
params->portParams.spiParams.frameFormat = SPI_POL1_PHA1;
Sample Logic Captures
Note that synch messages follow the same format, but are blocking and have a different CMD0 field.
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:
- 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).
- Each device can only begin to write (or clock data in the case of SPI) once both MRDY and SRDY are asserted.