CC2640 as SPI slave. NPI / TL protocol

Hi Jose,

I understand that MRDY/SRDY wording is confusing in our wiki. I will work to update it. This is from our SNP software developer's guide:

"The timing diagram in Figure 8 shows that MRDY is de-asserted only after the transfer on the serial

bus has completed. This behavior however, is dependent on which underlying serial bus is being used.

For SPI, the SNP has no concept of when the SPI transfer has finished because the AP is in control of

SCLK and determines how many bytes are clocked. It is the AP’s job then to clock the correct amount

of bytes and then de-assert MRDY which signals to the SNP that the transfer has indeed completed.

The correct amount of bytes is determined by a length field that is present with the SPI frame that is

being transferred."

Though you may not be using the SNP, this blurb applies to the NPI protocol with SPI. Does that clear things up? Regarding your issue from the other E2E thread, I will look into the issue more and comment in that thread.

Hi Sean,

Thank you for your interest.

After reading your explanation (and more details in the SNP software developer's guide), I still have the same doubt.  I will try to summarize it in the following points , all of them related to the provided NPI implementation (please, feel free to comment, clarify or correct the ones you consider):

1. SRDY de-assertion is governed only and exclusively by the own slave's SPI driver (NPITL_transmissionCallBack()).
2. MRDY de-assertion must be governed only by the master SPI driver (implementation not provided).
3. So, there is NOT a direct relationship (cause-effect or temporary) between the two de-assertions, and there is nothing that guarantees which de-assertion is detected first in the slave side (my tests also seem to confirm this behaviour: for transactions started by the slave, most of times SRDY de-assertion happens first, but sporadically MRDY is detected first).
4. If MRDY is detected first, then SPI transaction is cancelled.

Are these points true?

Thank you very much.

BR

José Antonio Martínez.

Jose,

I am commenting your last post from the RTOS forum here for context:

Hi Sean,
Some points I would like to clarify:
1. Do you mean a capture of any transaction or a capture in the moment that the problem appears? If it is the second, I guess it is almost impossible: there are several thousands of correct transactions until the problem appears, and with my logic analyzer I am only capturing one transaction each time (triggering capture with lowing edge of SRDY for example). Maybe can I capture more transactions each time? any suggestion?.
2. To see all the remaining SPI signals I will need to request our HW team to develop a product exposing that trails, since our custom board has not pins to that signals. I can not promise you if we will have advances achieving this point.
3. You say "MRDY should always have a rising edge before SRDY" but this confuse me a lot, since this is not what I see in my captures, and also it is not what I should expect that the code is working. Moreover, in this case, I don't understand the explanation: "The NPI master must parse the message coming from the slave to know when to assert MRDY".

Hi Sean, Svend,

At the end, I have captured a bunch of transaction with all SPI signals:

20151111_1726_fail_at_95M_4_MHz_240_M_Samples.zip

I have a breakpoint in the SPICC26XXDMA_hwiFxn() function, just when the fail is detected (as a null pointer object->currentTransaction). This breakpoint stops execution aprox. at 21sg. from the start of the capture (as you can see, after this point only MRDY line has activity).

Could you please take a look to this capture to see if it can help understand what is happening. Of course, I am fully available to any test or explanation about the capture that you need.

Thank you very much.

BR

José Antonio Martínez.

Hi again,

All this time, I'm still trying to determine if the problem can be reproduced using only one SPI channel. Only for this purpose, I disable all code that uses SPI0 and generate some data to send over SPI1 (simulating the data generated by accelerometer connected in SPI0). Doing this, I note that CC2640 stops sending data over NPI/SPI0 after some seconds (about 55 seg. in this test). Capturing data with analyzer, I see a weird behaviour (from my point of view) in the MISO line: it stays low "too much" time:

20151112_1029_miso_stays_low_4_MHz_240_M_Samples.zip

I already noted this behaviour when running in "normal mode" (both SPI channels working), as it can be seen in the previous capture. However, it this case I noted that MISO even remains low between two consecutive transfers (at 53sec. and 56sec. aprox.). I don't know if this is related with the original problem or with the fact that the CC2640 stops sending data over NPI aprox. at this same time.

Thank you very much.

BR

José Antonio Martínez.

Hi,

Last researches lead me to the following point: my NPI code is exactly the original one provided with ble stack 2.0.0, except for two things:

a) Define SRDY and MRDY pins for our design in npi_config.h

b) We had to comment the following line in NPITL_transmissionCallBack() function:

#ifdef POWER_SAVING
// Reset mrdy state in case of missed HWI
//mrdy_state = PIN_getInputValue(MRDY_PIN);

Now, it seems that this can be related, at least, with the behaviour of the MISO line. I take a look to code managing this variable (mrdy_state) in the new ble stack version (2.1.0) and I see that the following lines were added at the end of NPITL_MRDYPinHwiFxn():

// Check the physical state of the pin to see if it matches the variable
// state. If not then edge has been missed
if (mrdy_state != PIN_getInputValue(MRDY_PIN))
{
mrdy_state = PIN_getInputValue(MRDY_PIN);

if (mrdy_state == 0)
{
mrdyPktStamp = txPktCount;
NPITL_setPM();

if (taskMrdyCB)
{
taskMrdyCB();
}
}
else
{
transportStopTransfer();
}
}

So, I uncomment my change in NPITL_transmissionCallBack() and added this lines to manage mrdy_state in the same way as the ble stack 2.1.0 is doing it, and what I see is that MISO is now in low state most of time (instead of high state as I would expect):

20151112_2251_fail_with_new_version_npi_code_4_MHz_240_M_Samples.zip

I am not still able to explain this behaviour from the changes in the code, but what do you think? maybe is all this issue with the "mrdy_state" var and the MISO line behaviour related with my fail?. If I don't find another way I will try to update ble stack, or at least the full NPI component (could it be updated separately?) to see if it solves or changes anything.

Any suggestion is welcome. 

Thank you very much. BR

José Antonio Martínez

Hi,

I have replaced the full npi component (taking folder Components/npi from ble_2_1_0). It is fully compatible with the version of ble_2_0_0, I only had to do two modifications:

1. Define my own MRDY/SRDY pins in npi_config.h (we are using IOID_9 and IOID_13).
2. Change calls from NPIRxBuf_GetRxBufLen() to NPIRxBuf_GetRxBufCount() in my app.

Everything else is the original NPI code from 2_1_1.

Tests have reproduced the same failure (breakpoint triggered when unexpected object->currentTransaction == NULL in SPICC26XXDMA_hwiFxn()), though it seems that is "more dificult" to reproduce it (I needed about 10 minutes transmitting data, when tipically it failed in about 1/2 mins with the 2_0_0 original code).

By the way, this is the new capture of this test (fail detected and breakpoint triggered about 40 sec.):

20151113_1123_full_npi_2_1_0_ported_4_MHz_240_M_Samples.zip

Any ideas or comments?

Thank you very much. BR

José Antonio Martínez

Hi again,

I have been reading about MISO and required pullup/pulldown on this SPI line. After that, I am thinking that maybe the MISO behaviour is not the related with the problem detected. It seems (as explained for example here ) :

"As far as I know, SPI lines are always actively driven in both directions.

I sometimes put a pulldown on the MISO line because it could be floating for extended periods of time. Only the slave with slave select asserted is allowed to drive the line, so when no slave is selected, the line floats.

Floating MISO doesn't cause any data problems because it only floats when its value is meaningless and the master shouldn't be looking at the line anyway. However, intermediate voltages on some digital inputs can cause trouble. They can cause oscillations and higher than specified current draw inside the receiving chip. A weak, even 100 kΩ, pulldown keeps the line at the logic low level when not in use."

What do you think? Do you agree? Any suggestions or ideas?

Thank you very much. Regards.

José Antonio Martínez

Hi José,

I have notified Sean again on this thread.
The MISO pin on the CC26XX SPI is high impedance when not used (CSN is high) but there is a pull-down enabled on that pin in the driver to avoid undefined voltage levels and high current draw on the corresponding pin on the host processor.

Edit: This applies only to SPI master mode. For slave configuration the following is set in the driver:

      spiPinTable[i++] = hwAttrs->mosiPin | PIN_INPUT_EN;
      spiPinTable[i++] = hwAttrs->misoPin | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_INPUT_DIS | PIN_DRVSTR_MED;
      spiPinTable[i++] = hwAttrs->clkPin  | PIN_INPUT_EN;
      spiPinTable[i++] = object->csnPin   | PIN_INPUT_EN | PIN_PULLUP;

Regards,
Svend

Hi Sean,

In my tests, I am always using TI-RTOS 2.11.1.09. (the one provided with the original ble sdk we are using 2.0.0). Specifically, all components are the ones reported in e2e.ti.com/.../1687802 (as commented in previous posts (https://e2e.ti.com/support/embedded/tirtos/f/355/p/458078/1656045#1656045) we are trying to port and update all our project to the new versions, but this can not be done yet).

Thank you. BR.
José Antonio Martínez.

Thank you José.

Looking at the SPI drivers from the 2.11 RTOS. It seems to me that there are a few ways the currentTransaction can be set to NULL:
1. Opening the SPI driver
2. Later in the HWI function that you're breaking in
3. Calling transfer cancel
4. Memory corruption (doubtful, lets discount for now)

Also, I cannot yet pinpoint this to being your issue, but it seems like the last transfer which occurred before you broke did not follow the NPI packet format:
at ~39s:284ms you send a SOF on MOSI. This is the first byte of the current transaction. According to the NPI frame format for SPI, the following byte should be the length byte, which can be between 0-255. You set the length byte to 0x1C (28 in dec), but then send many more bytes. There should be one spi frame (SOF, LEN, payload, FCS) per handshake. This is vital to the NPI protocol working correctly.

Hi Sean,

Thank you for your answers. Some points I would like to clarify:

1. My NPI packet is tipically 28 bytes length. However, the original NPI implementation you provided always transmit "NPI_TL_BUF_SIZE" bytes (fixed to 270). Regarding to the last transfer you refer, there is a SOF(254), then LEN(28), and then  payload (28 bytes) and FCS (which is 20 for that packet). The rest of the bytes (until 270) are 0, but they are added by the own NPI implementation. That is, at the end I am calling the function NPITLSPI_writeTransport(len) to transmit, with the param "len=28", that is the length of my packet, but since NPI_TL_BUF_SIZE=270 this function completes until 270 bytes (with zeros as I can see) when transmitting using SPI_DRV_MasterTransfer(). Is that correct? or is there any adjust I should be doing?.
2. Regarding the points that can cause currentTransaction to be NULL, they are the same ones as I had detected. From my investigations I think the most probable cause in this case is 3, since I was debugging and I could discard 1. and 2. when reproducing the issue. I could not discard 3 yet, and I still don't understand the reason that could cause such behaviour (maybe a sort of race condition...?)...

Thank you very much.

Hi Sean,
I have configured a test environment with the following conditions:

• CC2640 only uses SPI1, where it is configured as a SPI slave, to try to transmit a TL/NPI packet each second. No SPI0 is used nor initialized.
• MKL27 does not transmit. It is configured as a SPI master, and only reads transmissions from CC2640.

Then, I observe the following:

Each time CC2640 wants to transmit a packet it does the following:

1, It configures SPI_transfer() to transmit 270 bytes (NPITLSPI_writeTransport()):

// set up the SPI Transaction
spiTransaction.count = NPI_TL_BUF_SIZE;
spiTransaction.txBuf = TransportTxBuf;
spiTransaction.rxBuf = TransportRxBuf;

// Check to see if transport is successful. If not, reset TxBufLen to allow
// another write to be processed
if( ! SPI_transfer(spiHandle, &spiTransaction) )

2. Enables SRDY: (NPITL_writeTL()):

SRDY_ENABLE();

Then, it's the SPI master code on MKL27. Originally, it was configured to read NPI_TL_BUF_SIZE (270) bytes, so, as the master, it generated clock until this amount of bytes were readed, then it raised MRDY to finish transaction. This situation corresponds to the captures already discussed in previous posts, where there is a padding of zero bytes until reaching 270 bytes. From your comments, and the documentation it seems to me that master should use the known TL packet length to raise MRDY when the suitable number of bytes have been received, without expecting to complet 270 bytes, am I right?

What I have found is that if I change master implementation to read a lower number of bytes (for example 170), then what happens is next:

1. After MRDY deassertion, clock is generated by master until these 170 bytes are received. As in previous case, zero bytes are readed from the end of the NPI/TL packet until 270 are reached, so I guess this is right, is that true?
2. NPITLSPI_CallBack() is never called, so SRDY is never deasserted and no more that one transmission can be done. Is this behaviour expected? In that case, I guess that I can not configure master to read only the amount of bytes that corresponds to the NPI/TL packet. It had to read always the same NPI_TL_BUF_SIZE (270) bytes before deasserting MRDY (which is not what I understand from you comments as said before).

This behaviour can be seen in the following analyzer capture:

20151119_2022_size_master_150_4 MHz_80_M_Samples.zip

Could you help me clarify all this mess?. Thanks a lot.

José Antonio Martínez

Hi José,

Sure, I'm here to help. NPI can be confusing, I understand that. I just suggested this post as an answer so other forum goers could see the "proposed" resolution of the first issue we were seeing (object->currentTransaction == NULL crashes).


It looks like your response is not showing up here for some reason, but I saw it in my email and reviewed the trace. We are getting close!
Within the NPI slave (26xx in your case) SRDY is pulled high within NPITL_transmissionCallBack (in NPI_tl.c) , which should be triggered after your frame is sent. Can you put a breakpoint in this function and see if you are reaching it?

Hi Sean,
Thank you for your help, and sorry for unmark suggested answer. What I was trying to do was to reply to your answer adding more info, but, in fact, I deleted my answer some minutes after have writted it. Please discard the info it contains. I was forgotten a minimal hack added by myself to original NPI code during test: that is, as said some days ago, I had commented the call to transportStopTransfer(). Then I forgot to undo this change, and this was causing the SRDY/MISO lines not to be rised. I recover full original NPI code (and check it fully this time!), and now SPI transactions have exactly the expected form in the logic analyzer captures.

I still can not say if the null pointer issue still remains with the changes in the NPI master implementation (now there is not zero padding until 270 bytes). Please, let me make some tests this weekend and I will inform you about the results at the beginning of the next week.

Sorry for the annoyance caused, and thank you very much. BR

José Antonio Martínez.

Hi Sean,

Indeed, as you well anticipated, the problem seems to be fixed. I have been testing the product these days with full functionallity (both SPI channels working in CC2640), and I could not reproduce any fault. So, to summaryze, at the end, the cause of the problem was a faulty NPI master implementation. Implementing the algorithm you suggested (read NPI/TL packet's header first and then read the remaining packet's bytes) not only seems to fix my problem, also it let me optimize the memory used in transmission buffers.

So, I would like to express my gratitude for all your help with this issue. 

Best wishes.

José Antonio Martínez.