This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/CC1350: Communication lost for short time

Part Number: CC1350
Other Parts Discussed in Thread: SIMPLELINK-CC13X0-SDK

Tool/software: Code Composer Studio

This is the customer request, I would be happy if you can help,

"

We are using Texas Instruments CC1350f128 and using Code composer studio. Which based ti_rtos and for communication easylink library.

We have one transmitter and one receiver, the question is ;

During the communication b/w transmitter and receiver I stop to send data after 9min 27 sec when i send data again there is no communication until 10min 33sec later its connecting.

But during (9:27-10:33) there is no communication except that there is a communication. This always happens at same time where connection is lost. I realized that transmitter sends the data but receiver doesn’t receive What might be the reason for this ?

I investigated easylink lib. During the communication the status when received the packet it is easylink_status_success but during when it doesn’t receive it is easylink_status_busy_error.

Is that might be the reason?

 The code is has simply two tasks one rx(receiver) and tx(transmitter). When processor awake first waits in receiver mode and when receives packet changes to transmitter mode and sends a packet than again receiver mode, until it doesn’t receive packet it waits in receiver mode.

"

I would like to share the codes from the customer which is NDA information, please email me privately since i can not share with public. 

Thanks in advance

  • - Which SDK are you using?\

    This sounds like Advisory 8 in 

    This should not happen if the CMD_FS.fractFreq used is the same as calculated by SmartRF Studio 

    Could you by debugging see which CMD_FS.fractFreq  that is actually used in your code and check if this is a value that is equal to what SmartRF Stuio calculate? 

  • I am using "simplelink_cc13x0_sdk_1_50_00_08".

    I realised that you declared 'the problem has been fixed in SIMPLELINK-CC13X0-SDK_2.20.00.38' in document.

    I will try this sdk then .ı will provide you a feedback about it.

    thanks a lot.

  • I have tried with 'simplelink_cc13x0_sdk_3_20_00_23' . But there is an error that is" xdc.module: no module named 'Config' in the package ti.drivers". How can i solve this problem? I have tried different xdctools version. It gives same error.

  • Not clear how you have tested with 'simplelink_cc13x0_sdk_3_20_00_23'.  Did you test with one of the examples in the SDK? 

  • I have tested one of the example in the SDK. There was no error. It gives error in the software that i am trying to rewrite. Previously, the software was written in tirtos_cc13xx_cc26xx_setupwin32_2_20_00_06, I converted to 'simplelink_cc13x0_sdk_3_20_00_23' sdk because
    I thought the error was related to advisory 8. I included the library by using this sdk. Firstly, it gave the error "can't locate the package 'ti.mw' along the path". Then i also included  'tirtos_cc13xx_cc26xx_setupwin32_2_20_00_06'. 'ti.mw' package was in there. After all of this, there is only one error left. The error is " xdc.module: no module named 'Config' in the package ti.drivers". I controlled that 'ti.drivers.Config' file is in the package. But the software can't find it. Should i include  'tirtos_cc13xx_cc26xx_setupwin32_2_20_00_06' ?. If i don't include the tirtos file, how to fix  "can't locate the package 'ti.mw' along the path" problem?

  • If I read the issue correctly this is related to how you have ported to a new SDK. 

    One way to start using a new SDK is to import the empty example from the new SDK and copy your application files into this new project and then remove the empty.c from build. This way you get all the project setup correct. 

    You may need to change some includes.

  • I imported the rf example, then copied my application files into it. The problem is gone. There is not interreuption in communication.

    Thanks for helps.