• State
  • Replies 21 replies
  • Subscribers 52 subscribers
  • Views 327 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

CC2642R: CC2642R

Chinmay Lotake
Prodigy 20 points
Part Number: CC2642R

Tool/software:

Hello,

We have developed one application in which CC2642 act as pass through. It connects mobile application over Bluetooth Low Energy and parses the command and sent it to Main MCU via SPI lines.

Clock Freq - 3 MHz

Setting - POL0 PHA1
Clock Polarity - low
Clock Phase - rising edge

The CC2642 act as SPI Slave device and Main MCU is SPI Master. CS is configured as Software driven where CC2642 waits for Master Ready(HW Pin Interrupt) before calling SPI Transfer(). Because this device runs on Battery, to save power we have two handshaking signal for SPI, One is SRDY - Slave Ready and another is MRDY - Master Ready. Anyone can initiate the request to other by asserting respective line first and then waits for other to assert other pair of it to Logic Level low. This assertion is detected by PIN HW Interrupt where we starts time and call SPI Transfer will appropriate data. One the MRDY gets de-asserted, CC2642 understands that there might be data available as a response or a new request. This is understood by upper layer as it is following the protocol.

Recently we fixed a race condition in timeout timer (protocol timer for message exchange timeout) and MRDY assertion both happening simultaneously. ( I had earlier thread on community for the same). We had put the execution of MRDY de-assertion interrupt handler into Critical Section as this piece of code stopping Timer.

Recently we had observed that when we get a request from Main MCU, there is a bit flip in RX Buffer which makes the CRC error and packets getting dropped by CC2642 MCU. When we put MRDY interrupt code kept in Critical Section (Uses ICALL Api's), the frequency of occurrence is much greater.

We verified using Saleae Logic Pro 16 that the voltage levels and clock signals are proper. Please suggest do we need to have it seen on Oscilloscope? 

Please help me guide on all possible scenarios where there can be a data corruption in SPI RX Buffer.

Thanks and Regards,

Chinmay Lotake

  • 0
    TI__Mastermind 36660 points

    Hi Chinmay,

    Thank you for reaching out. Can you share the SDK version you are using? You mentioned that your application connects to a phone through BLE. Is this behavior reproduce able in a non-ble example?

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 20 points

    Hello Jan,

    Thanks for your quick response. The SDK Version is 5.10.00.48.

    Yes, The application connects to phone/laptop through BLE, I mentioned all details about my application to give rough idea as to what all we are resource we are using. CC2642 acts as passthrough (protocol converter) where it passes the command it got over BLE to proprietary command to Main MCU via SPI lines. Main MCU can be any MCU which can talk over SPI lines.
    Request coming from RF side is passed by CC2642 to Main MCU and response from Main MCU is passed to RF side.

    The issue that we are experiencing happens when CC2642 is in Advertising mode as well as BLE Connection mode. But a point to note is when We disable RF side, we dont get the issue.

    As I mentioned above, Main MCU is master and BLE MCU is slave, but because of handshaking signal, any once can initiate the request. Mostly the speed of communication is dependent on Handshaking lines. If any of the MCU is not able to process the request it will not raise its MRDY/SRDY lines. When we force the communication at higher speed like a request/response every 10-15 mSec I see the issue frequently.

    Please let me know if you need more info.

    Thank and Regards,
    Chinmay Lotake

  • 0 in reply to Chinmay Lotake
    TI__Mastermind 36660 points

    Hi,

    Got it. Thank you for the additional details. You mentioned you recently fixed a race condition issue. Was this new issue present before the fix was applied? If not, then can you share the code that fixed the other issue?

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 20 points

    Hello Jan,

    Thanks for your response. Apologies for my late response. I was on leave for last few days.

    I guess we have figured out the issue due to which the scenario was happening.

    We were going through a post

    https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1049588/cc2642r-q1-timing-parameters---cc2642-s-ssi


    The Main MCU is Kinetis K24. Below is the image related to K24


    From the TI Post we increase the tASC to 220ns in K24 and don`t observe the issue for few mins of runtime (which is good as earlier we were seeing the above issue within 10 secs)

    Are there any documentation for CC2642 for getting similar timing parameters? How can we find correct values for tASC.

    We will have a long run with above changes next week. So will keep you posted.

    Please let me know your thoughts and inputs.

    Thanks in advance.

    Regards,
    Chinmay Lotake

  • 0 in reply to Chinmay Lotake
    TI__Mastermind 36660 points

    Hi Chinmay Lotake,

    I believe that the strategy mentioned in the other thread of finding the max and min values that tASC would be the best bet. Can you try performing some more long term testing using the 220ns figure?

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 20 points

    Hello Jan,

    Thanks for your reply.

    I will surely perform long term test in coming days.

    The same observations I shared with in team. But there is still a concern that what is the relation of tASC and the critical section. There remains some points un-answered as below (Consider the old tASC value of ~90 nSec, the issue is seen within 10 sec of continuous communication)

    1. When we decrease the duration of critical section, the issue is not seen for more than 3000 Sec.

    2. When we disable RF, the issue is not seen for at least  400 Sec.

    Please help me to debug the issue more in details as the above two scenarios makes no relation of tASC values.

    Thanks and Regards,

    Chinmay Lotake

  • 0 in reply to Chinmay Lotake
    TI__Mastermind 36660 points

    Hi Chinmay Lotake,

    Can you share some code snippets of the critical section including the icall APIs that surround these sections?

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 20 points

    Hello Jan,

    Please see the code below

    "prepareMessageExchange()" -> it will populate SPI Transaction structure and do SPI_Transfer()

    "MRDYActiveInterrupt()" - modifies flag as true/false for enable/disable resp and enables/disables PIN Interrupt for MRDYActiveInterrupt

    The above code is part of handling handshake. The critical section seen is what I was referring in my above post

    Thanks and Regards,

    Chinmay Lotake

  • 0 in reply to Chinmay Lotake
    TI__Mastermind 36660 points

    Hi Chinmay,

    Got it. The code looks correct to me. Can you share what is the return value of ICall_enterCriticalSection()?

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 20 points

    Hello Jan,

    Just wanted to know at what instance you need the return value of ICall_enterCriticalSection().

    Is it when the issue occurs, or at normal run.

    The MRDY active interrupt occurs for every transaction (RX or TX). The MRDY line is in active state when Main MCU wants or is ready for data transfer. After sometime, the Master/Main MCU will drive the SPI clock for data transfer to took place. Just curious as to what detail the return value of ICall_enterCriticalSection will give?

    Regards,

    Chinmay Lotake

     

  • 0 in reply to Chinmay Lotake
    TI__Mastermind 36660 points

    Hi Chinmay,

    Can you provide both a normal instance, the good instance right before the fault and the instance when the fault occurs? I would like to see if theres any corruption or unexpected value being returned.

    Best Regards,

    Jan

  • 0 in reply to Chinmay Lotake
    Prodigy 20 points

    Hello Jan,

    Just checking if you have any input for me.

    Regards,

    Chinmay Lotake

  • 0 in reply to Chinmay Lotake
    Prodigy 20 points

    Sorry, I missed your earlier post. Never mind.

    I will get the data in 1-2 days.

    Regards,

    Chinmay

  • 0 in reply to Jan
    Prodigy 20 points

    Hello Jan,

    The return value ICall_enterCriticalSection() is ZERO (0) in both normal instance as well as when the fault occurs.

    Please guide me how to analyze the issue further.

    Regards,

    Chinmay

  • 0 in reply to Chinmay Lotake
    TI__Mastermind 36660 points

    Hi Chimnay,

    Those values seem to be correct. I would like to narrow out a HW cause. Are you able to reproduce the behavior on a LaunchPad?

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 20 points

    Hello Jan,

    We do have a simulator of Main MCU running on CC2652 LaunchXL launch pad. But we have not seen this issue on LaunchXL.

    What kind of HW cause you are thinking about. Please provide us with more inputs.

    Regards,

    Chinmay

  • 0 in reply to Chinmay Lotake
    TI__Mastermind 36660 points

    Hi Chinmay,

    I am not sure off the top of my head what HW component could cause this behavior, but seeing that the issue does not reproduce on the LP means its possible that the issue may lie on the HW side. Have you had your design reviewed at https://www.ti.com/tool/SIMPLELINK-2-4GHZ-DESIGN-REVIEWS?

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 20 points

    Hello Jan,

    I am not sure if design is reviewed. I will ask in team and get back to you on this.

    The handshaking and protocol things are taken straight from NPI protocol from TI.

    The issue does not get reproduced when RF is powered down. 

    What HW component can trigger this behavior.

    Regards,

    Chinmay 

  • 0 in reply to Chinmay Lotake
    TI__Mastermind 36660 points

    Hi Chinmay,

    I am unsure what HW cause there could be for the behavior, but if the behavior occurs reliably on the custom board, but not at all on the launchpad then this indicates that there may be a HW discrepancy between the LP and the custom board that is contributing to the behavior. To  confirm, running the same test on the LP does not yield the behavior at all?

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 20 points

    Hello Jan,

    It will take some effort to run the same code on LP. Anything else that can be done quickly to conclude if its a HW discrepancy.

    Please let me know.

    Regards,

    Chinmay

  • 0 in reply to Chinmay Lotake
    TI__Mastermind 36660 points

    Hi Chinmay,

    I have looped in a HW expert to comment. Have you verified if the design has been reviewed?

    Best Regards,

    Jan