Documentation: CC2650 + Host processor Interchange

Amanda, RNP communicates on the CC26xx is done via the "unified" NPI (Network Processor Interface). I'm not aware of any specific implementation done on a PIC or any other bare-metal example. The general use case has been to interface an RNP via an embedded Linux platform (for which we do have an NPI server). 

The NPI wiki documents the frame format for UART and SPI. For RF4CE, the only real difference between the two is that via SPI, the MRDY and SRDY pins are required (based on RF4CE's requirements).

Can you elaborate on this:

Amanda Ross95 said:

We've looked at the wiki page and have also seen the porting guide which discusses how to port with a TI-RTOS based Host Processor. But the stack structure used in the document is different from what gets dropped in CCSTUDIO by the ‘project importer’ ofr us. 

RF4CE projects use TI-RTOS, but they don't look anything like a stock simple TI-RTOS example. With that said, I'm not aware of a TI-RTOS examples that talks to an RF4CE remote network processor via NPI. What's the general application for this? I'm trying to understand if RF4CE is what the customer is really looking for.

Tom

Hey Amanda:

Yea, need you to respond to Tom's request to better understand what you are experiencing from going through the Wiki site. Have you been able to establish basic UART communications such that you can send an NPI command and receive a response back?

Tim

We are using SPI, and have the following info which discusses the CC253x. There's no equivalent doc for the CC26xx, so please correct any misconceptions on whether the CC2650 NP should behave identically with SPI link:

From RemoTI Network Processor Interface Specification Document Number: SWRA271F

4.1.5 Protocol Scenarios

4.1.5.1 Synchronization of Host and Network Processors

Before SPI communication can be performed between the host and network processors, a

synchronization sequence must occur. The following figure shows this process.

Our observation so far has been:

At power up, the NP is driving SRDY low, our PIC responded by driving MRDY low, then provides SCLK, and obtained 00 FE 00 00 4A 0D (FCS = 47) from the NP, consistent with an RTI_ResetInd().

RTI_ResetInd() - AREQ Byte 0 - 1 Byte 2 Byte 3 Length Type / Sub-System Command ID 0x00 0x4A 0x0D

00 FE 00 00 4A 0D (FCS = 47)

 

Host drives MOSI  with RTI_InitReq() - AREQ but gets no reply from the NP. Please suggest an alternate debug strategy if the following is flawed, or expand on the idea so we can trace NP responses to Host AREQ and SREQ: use CCSTUDIO to see if npi_tl_spi.c in rnp_app was ever entered at all; are there any accessible hardware registers/flags CCSTUDIO can read to trace the SPI MOSI traffic up to the NPI Transport Layer and subsequently into NPITask_routerHostToSS() as described in RemoTI-2.0.0-Network Processor Developers Guide?

 

Are there any PC tools/examples to generate Master UART traffic in Hyperterm/Teraterm for example to verify the CC2650  NP is actually functional?

Further detail:

We noticed there is a discrepancy between the (A):"RemoTI Network Processor Interface Specification Document Number: SWRA271F" and (B):"processors.wiki.ti.com/.../Unified_Network_Processor_Interface"

In (A), we see this below, SRDY is leading MRDY,

 

while in (B), we see this below, MRDY is leading SRDY,

Also, from the scope we capture, the SRDY was never set to high after the frame is transmitted. See below,

Hi Ronald,

I'm happy to see that you really get into the details. There is a discrepancy in the two protocols. NPI for CC25xx and Unified NPI for CC26xx. I'll try to be brief on the history here. CC25xx family consists of a variety of devices with different supported RF protocols. Each "RF protocol stack", or SDK, was develop with similarities in the core functionality rather than using the same core functionality. The NPI protocol used by RemoTI is similar, but not identical to that used by other SDKs.

With CC26xx and CC13xx we had a chance to improve the situation. We defined Unified NPI which can now be used by all SDKs. It's really independent of RF. It is just based on TI-RTOS, which all SDKs for CC26xx and CC13xx use.

The Unified NPI supports full-duplex communication. In other words, as long as a transaction is ongoing either side can send data. MRDY/SRDY are most important for flow control in regards to power management. The difference you have identified relates to the use of SRDY in NPI protocol to indicate that the slave's SRSP is ready. Synchronous transfers with Unified NPI is achieved via higher level pend on expected response.

To summarize, for RemoTI (RF4CE):

1. RemoTI-1.4.1 and lower
   1. Support CC253x devices
   2. Support the old NPI protocol.
2. RemoTI-2.0.0 and higher
   1. Support CC26xx devices
   2. Support the Unified NPI protocol

There is a good chance Unified NPI will simply be referred to as NPI to in the future, as most new products are developed with the CC26xx or CC13xx device family.

Thank you Torbjorn,

Could you explore more in detail regarding "Synchronous transfers with Unified NPI is achieved via higher level pend on expected response.", I want to know what actual frame should we send, and the sequences of signals, for us to receive a response.

I have tried send a SREQ, RTI_ReadItem() to the NP, but there is no response, i.e. the Slave (NP) never try to initiate a response by driving SRDY low? Or, I have a wrong expectation?

The following is what I see,

After "zooming in" on the MOSI, I verified the frame I am sending as follow, 00 FE 04 00 2A 21 00 FF A8 02 5A, where FF = profile RTI, A8 = Vendor ID, 02 = length of Vendor ID.

In my previous attempt, I tried to send, 00 FE 04 00 2A 21 00 00 80 02 (FCS), 00 = profile GDP, 80 = verison, 02 = length of version, was also no response.

But, then SRDY never goes low, and the bus is idle....

My goal is to send the most direct and simple frame, in hope to get a response from the NP. More less like a "ping". Thanks!