CC2640R2F: Simple NP Project: NPI de-asserting MRDY pin before clock or data is stopped

Hi,

I sent it to a concerned engineer. We will look into it and get back to you ASAP. Please bare with us.

Thanks,

PM

Good morning:

Following up on this. Has anyone had a chance to look into our issue? It is really putting our development at a standstill.

Looking forward to your reply,

Gary

Hi Gary,

Please see this related thread: https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/463083?CC2640-as-SPI-slave-NPI-TL-protocol

BR,

Seong

Seong:

I read through the suggested post, but the OP's issue and resolution don't seem to be very applicable to my issue. Maybe you could re-read my post. Nowhere in the referenced post is bi-directional communication referenced, which seems to be the only point of failure in our implementation. We have no issues sending or receiving one-way data over NPI. Only when there is a bidirectional transfer do we seem to have an issue. We are using the simple_np project, and have reused the NPI_TL code in our Application Processor. This means any handling of MRDY and SRDY is identical on both the master and slave. Also, there is a line of code in the NPITask_Fxn() task which should prevent the NP from beginning a TX to the AP on MISO if there is already a transaction in progress:

if (NPITask_events & NPITASK_TX_READY_EVENT)
{
  // Cannot send if NPI Tl is already busy.
  if (!NPITL_checkNpiBusy())
  {

....

How is it possible, given this code snippet above, for the NP to send data to the AP when the AP initiated an NPI transaction?

Hi Gary,

The 2 byte Length field must be in little-endian format, so to define a 27 byte length, try writing 0x1B00 instead of 0x001B.

BR,

Seong

We are already using little-endian format. I have clarified this now in my original post, where previously I had combined them as they appear in the NPI notes. That seemed to add confusion, so I included the more raw-format.

Recall from my original post that we do get successful communication from AP to NP and NP to AP, just not when the NP tries to send something over during an AP-initiated transfer.

Note that we are using DMA_TransmitReceive() for all NPI transactions on the AP side, and are parsing any RX data we get during a TX from AP to NP. The issue still remains where a response from AP is never received by the NP. 

Also, upon further inspection, you can see that in the trace shots we captured in the original post, the data on MISO does not start at the beginning of the clock pulses, and when it does start, it is not an SOF (0xFE). This is evident by comparing the large high pulse on MOSI where our SOF marker starts the actual TX response to NP.

We are struggling here to find any clues as to what we can do to remedy this, or if the issue is in the NP. Please provide some insight. Thank you.

Gary

Good morning. I have not yet received any response from TI that really touches on the issue we are having. I am hoping that this message will get the right people involved. We are having a hard time looking for the potential problem and need assistance.

Thank you,

Gary

Hi Gary,

Apologies for the late reply. We're currently looking into this issue and will reply again shortly.

Thanks,

Seong

Hi Gary,

Thank you for your patience.

Could you please consider the following lines of thought?

If we focus on the unexpected data on the MISO line:

      1)      Is there “someone” using the MISO pin on one or the other side?

• Could be nice to verify this by having a look to the board files of both devices.
• Could be also nice to try using a different pin for the MISO line (on both devices and for test only)

2)      Is the second SPI the source of the problem?

• If both SPI are in use: verify the pin used by the second SPI
• If both SPI are in use: verify if somewhere for some reasons some transfers are performed on the wrong SPI.
• If both SPI are in use: (for test only) try to deactivate the SPI transactions issued from the other SPI
• Try to use the second SPI as base for the NPI and see if the same kind of problem appears.

3)      Is the unexpected data on the MISO line produced by a SPI transfer?

• Try to instrument the SPI driver to toggle a PIN every time a transfer is started. I see at least two good candidates for this instrumentation: the function NPITLSPI_CallBack() and the function SPICC26XXDMA_transfer() in SPICC26XXDMA.c

4)      Is it possible that the transfer is caused by some data corruptions?

• Can you try to increase the NPI stack size? (note: it’s one of the fields of the NPI_Params structure)
• Can you try to increase the stack size of the different tasks?
• Can you verify the content of the npiTxBuf buffer when the error occurs?

5)      Is the function NPITL_checkNpiBusy() working as expected?

• You can instrument the function to see if the NPI is detected as busy when needed. (e.g. set a gpio to zero or to one depending on the status sent back)

I hope this will help,

Best regards,

Hi Gary,

Do you have some updates regarding the issue?

Regards,

Clément:

Thank you very much for your troubleshooting ideas and follow-up. We made progress on this specific issue (can't connect) but are having essentially identical issues with normal communication, in that the phone sends a request (read or write), the request is sent from NP to AP, the response is sent from AP to NP, but the NP never receives it, and therefore doesn't send it to the phone app. This causes the connection to terminate 30 seconds later (in Android).

This seems to occur only when there is a lot of Bluetooth traffic (when we turn on notifications for live readings from our device, which occur every 250 ms, as well as having reads/writes occurring every 200ms).

Also, another issue we face is that when we attempt to increase the MTU size (beyond even small sizes like 30 or 40 bytes) we start getting Error responses from our device (not sure if they originate from AP or NP, but they end up on the Bluetooth traffic) when the phone app sends read requests, stating "out of resources". We hoped you could point us in the right direction for this issue as well. Perhaps these are all related issues.

To respond to some of the items you suggested:

---------------------------------------------------------------------------------------------------------------------------

If we focus on the unexpected data on the MISO line:

      1)      Is there “someone” using the MISO pin on one or the other side?

• Could be nice to verify this by having a look to the board files of both devices.
• Could be also nice to try using a different pin for the MISO line (on both devices and for test only)

There is another user of the SPI port, but it is blocked with a semaphore in software, and in this case the device is actually removed from the board. We also removed any code on the AP that starts SPI transactions with this other device, and still faced the issue.

2)      Is the second SPI the source of the problem?

• If both SPI are in use: verify the pin used by the second SPI
• If both SPI are in use: verify if somewhere for some reasons some transfers are performed on the wrong SPI.
• If both SPI are in use: (for test only) try to deactivate the SPI transactions issued from the other SPI
• Try to use the second SPI as base for the NPI and see if the same kind of problem appears.

Regarding "second SPI", are you referring the the second SPI in the CC2640 device? I don't think so but will confirm.

3)      Is the unexpected data on the MISO line produced by a SPI transfer?

• Try to instrument the SPI driver to toggle a PIN every time a transfer is started. I see at least two good candidates for this instrumentation: the function NPITLSPI_CallBack() and the function SPICC26XXDMA_transfer() in SPICC26XXDMA.c

4)      Is it possible that the transfer is caused by some data corruptions?

• Can you try to increase the NPI stack size? (note: it’s one of the fields of the NPI_Params structure)
• Can you try to increase the stack size of the different tasks?
• Can you verify the content of the npiTxBuf buffer when the error occurs?

5)      Is the function NPITL_checkNpiBusy() working as expected?

• You can instrument the function to see if the NPI is detected as busy when needed. (e.g. set a gpio to zero or to one depending on the status sent back)

---------------------------------------------------------------------------------------------------------------------------

Thanks again. We will try items 3-5 and update you accordingly. 

Gary

Hi Gary,

Thanks for the update.

Just one clarification: yes, when I talk about the "second SPI" I am talking about the second SPI of the CC2640.

Best regards,