Run-Time Logging NPI Protocol¶
Overview¶
TI’s network processor interface (NPI) can be used to establish communication between TI’s RF system-on-chips and a PC or external microcontroller. Sensor Controller Studio uses this protocol to transfer commands, status and data during run-time logging.
This document may be relevant when performing run-time logging with a custom application programmed into flash.
This document does not describe the NPI concept and protocol in general. Basic knowledge of NPI is needed to understand some of the details described below.
NPI Protocol¶
Sensor Controller Studio supports NPI communication over UART or TCP/IP. This section describes the parts of the NPI protocol that is specific for run-time logging with Sensor Controller Studio.
NPI messages support a 16-bit length field, and have an 8-bit checksum that is the previous bytes XOR’ed. Messages received with invalid checksum are ignored.
All run-time logging NPI messages use the following parameters:
cmd0
:RPC_SYS_PERIPHERAL | RPC_CMD_AREQ
cmd1
:0x20 |
message ID
The following NPI messages from Sensor Controller Studio to the target must be implemented:
Message / ID | Description | Payload byte array |
0x01 |
Requests a This message is sent one time when the run-time logging session begins. No other communication shall occur until a |
None |
0x02 |
Controls the Sensor Controller tasks, including which tasks that are enabled for run-time logging and which data structures that shall be logged. The tasks can be started, stopped, paused or unpaused. While paused, all logged data is discarded by the target. The target shall respond with a |
[0] Command:
|
For the [1] Task selection:
|
||
For the [2: …] One byte for each task (including unselected tasks):
|
||
0x03 |
Sets all members in a single data structure to the specified values. The run-time logging application shall ensure that the operation takes effect atomically while the Sensor Controller is idle. The target shall respond with a |
[0] Task ID |
[1] Data structure ID:
|
||
[2: …] New data structure contents (two bytes per data structure member, little-endian). The length is given implicitly by the task and data structure IDs. | ||
0x04 |
Sets multiple independent data structure members to the specified values. The run-time logging application shall ensure that the operation takes effect atomically while the Sensor Controller is idle. The target shall respond with a |
For each data structure member: |
[0] Task ID | ||
[1] Data structure ID:
|
||
[2:3] Offset into the data structure (+1 per 16-bit word) | ||
[4:5] Value (little-endian) | ||
0x05 |
Requests a The status indicates the number of successful commands since the last |
None |
The following NPI messages from the target to Sensor Controller Studio must be implemented:
Message / ID | Description | Payload byte array |
0x08 |
Response to all messages except the The message contains the number of successfully handled requests since the last |
[0] Number of successful CTRL commands. |
[1] Number of successful SET_ENTIRE_STRUCT commands. |
||
[2] Number of successful SET_STRUCT_MEMBER_LIST commands. |
||
[3] The current control state:
|
||
0x09 |
Contains all data structures logged by one The logged data structures are ordered by data structure ID. There can be multiple instances of the output data structure when multi-buffering is used. |
One or more of the following: |
[0] Task ID | ||
[1] Data structure ID:
|
||
[2: …] Data structure contents (two bytes per data structure member, little-endian). The length is given implicitly by the task and data structure IDs. | ||
0x0A |
Response to a The message contains one CRC-16 signature for each data structure for each task. The signature is calculated over data structure member names and array sizes, and is included in the generated SCIF driver as The run-time logging session is aborted if one or more signatures do not match. |
For each data structure for each task: |
[0:1] CRC-16 signature for the data structure, or 0x0000 if the data structure contains no members. |