• State TI Thinks Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 4 answers
  • Subscribers 56 subscribers
  • Views 859 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC1352P: Unable to debug easylinktx nortos app with CC1352P-2 in latest IAR ARM8.2.3

Bibin Varghese
Intellectual 815 points
Part Number: CC1352P
Other Parts Discussed in Thread: CC2520

We started using the easylinktx nortos app with CC1352P-2 in  latest IAR ARM8.2.3.

We were able to build the project successfully, but when trying to download & debug, it shows a sequence of operations including flash download and stopping at "Target reset" message.

It is not going to the main.

How can we solve this issue?

  • 0
    TI__Guru 58425 points
    Hi Bibin,

    Which SDK version are you using?
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Intellectual 815 points

    SDK version is 2_40_00-81.

    Is it having any issue?

  • 0 in reply to Bibin Varghese
    Guru 735455 points
    You have to use rev.E chip if you use SDK 2_40_00.81. Do you use rev.E CC1352P chip?
  • 0 in reply to YiKai Chen
    Intellectual 815 points

    RF section is enclosed by the RF shield.So unable to see the CC1352P version no.

    backside of the CC1352P-2  launchexl card, it is written HW rev: A, FW: SDK 2.10, 1825.

    So which SDK we need to use to work? Can i get the download link?

  • 0 in reply to Bibin Varghese
    TI__Guru 58425 points
    Hi Bibin,

    As it is a P device, I would expect it not to be the latest revision yet (you can also just pop the lid of the RF shield and look).
    If not running on a rev. E device, the latest SDK you can use it 2.30:

    www.ti.com/.../SIMPLELINK-CC13X2-SDK
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Intellectual 815 points

    We have installed the SDK2.3 and we are able to debug the code.

    In the SDK examples, we have tried the easylink proprietary tx & rx examples. But we want the easylink IEEE80215.4 Tx & Rx code examples, which we couldn't find in the SDK

    Can we get the same? Or how can we change the proprietary tx & rx  to work in the  IEEE82.15.4 mode?

    .

  • 0 in reply to Bibin Varghese
    TI__Guru 58425 points
    Hi Bibin,

    Both SDKs include Easylink with support for IEEE settings by changing the mode. As for examples that does not exist for older SDKs such as 2.30, we are not able to provide back ports for these. It is recommended to move any new development to a rev. E device to be able to use the newer SDKs.
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Intellectual 815 points

    Will it work  if I import the settings for IEEE802.15.4 operating at 2405MHz from smart RF studio to the  easylink proprietary tx & rx examples?

  • 0 in reply to Bibin Varghese
    Intellectual 815 points

    I have checked the available modes(enum)  in the easylink code and all are prop. modes for 915MHz and 2.4GHz.

    We want IEEE802.15.4b/e zigbee tx/rx modes(similar to CC2520). How can we up the easylink project for that?

    Is there any example project for this(IEEE802.15.4 b/e @ 2.4Ghz) otherwise?

  • 0 in reply to Bibin Varghese
    TI__Guru 58425 points

    Hi Bibin,

    These are the enums I can see in the SDK:

    //! \brief Phy Type passed to EasyLink_init()
typedef enum
{
    EasyLink_Phy_Custom = EasyLink_PHY_CUSTOM,            //!< Customer Phy specific settings exported from SmartRF Studio
    EasyLink_Phy_50kbps2gfsk = EasyLink_PHY_50KBPS2GFSK,  //!< Phy settings for Sub1G 50kbps data rate, IEEE 802.15.4g GFSK.
    EasyLink_Phy_625bpsLrm = EasyLink_PHY_625BPSLRM,      //!< Phy settings for Sub1G 625bps data rate, Long Range Mode.
    EasyLink_Phy_2_4_200kbps2gfsk = EasyLink_PHY_2_4_200KBPS2GFSK,   //!< Phy settings for 2.4Ghz 200kbps data rate, IEEE 802.15.4g GFSK.
    EasyLink_Phy_5kbpsSlLr = EasyLink_PHY_5KBPSSLLR,      //!< SimpleLink Long Range (5 kbps)
    EasyLink_Phy_2_4_100kbps2gfsk = EasyLink_PHY_2_4_100KBPS2GFSK,   //!< Phy settings for 2.4Ghz 100kbps data rate, IEEE 802.15.4g GFSK.
    EasyLink_Phy_2_4_250kbps2gfsk = EasyLink_PHY_2_4_250KBPS2GFSK,   //!< Phy settings for 2.4Ghz 250kbps data rate, IEEE 802.15.4g GFSK.
    EasyLink_Phy_200kbps2gfsk = EasyLink_PHY_200KBPS2GFSK,   //!< Phy settings for 200kbps data rate, IEEE 802.15.4g GFSK.
    EasyLink_Num_Phy_Settings,
} EasyLink_PhyType;

    There is multiple IEEE phys on this list, is this not the list you are looking at?

    It sounds to me that you would have a easier time doing what you want by exporting your settings and using only the RF Driver (as in the rfPacketTx/Rx examples) instead of Easylink. You would also be in more control of how the commands is configured. 

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Intellectual 815 points

    I have  gone through the rfPacketTx example.this example is as such working for 868Mhz in the prop. mode.

    I have imported the smartRf settings for IEEE802.15.4-2006 settings for 2.425GHz in the corresponding c & h files.

    Also changed the following in the rfPacketTx.c:

    In the void * mainThread(void *arg0)

     replaced the Rf_CmdPropTx struct with Rf_cmdIeeeTx and filled the .pPayload(=packet) and .StartTrigger.triggerType filelds(=0).

     replaced the rf_cmdPropRadioDivSetup argument in RF_Open() with Rf_cmd_RadioSetup.

    replaced &Rf_cmdPropTx argument in Rf_runCmd() with Rf_cmdIeeeTx.

    It is now working for the first packet. i am able to see the packet in the Smart RF Studio.

    After that, it is not coming out from the Rf_runCmd(0 function.

    Anything, i am missing in this modification?

    Pls help.

     

  • 0 in reply to Bibin Varghese
    TI__Guru 58425 points
    Hi Bibin,

    RF_runCmd() does not fully support IEEE commands. I suggest you try using RF_runScheduleCmd() instead.
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Intellectual 815 points

    We have replaced the RF_runCmd() with RF_runScheduleCmd() with appropriate arguments.

    Now it is working but it hanges after two calls!

    How can we solve this issue.We have provided appropriate delays btw the two calls.


    Is there any example project using the RF_runScheduleCmd for IEEE802.15.4 pkts?


  • 0 in reply to Bibin Varghese
    TI__Guru 58425 points

    You would need to provide more information on what is happening, he fact that your example hangs after two calls is not enough for me to help you find a fix.

    Could you for example attach your modified example code to the post and also look into the status of your radio commands? You find the status field by inspecting the radio command structure. 

    There is no "basic" radio examples using the IEEE format available as of today.

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Intellectual 815 points
    It was a mistake from our side. We have given a call back function , but not serviced it properly. Now we have passed Null for the call back function and the IEEE802.15.4 PktTx with RF_secheduleCmd is working.

    Ours is a TDMA system with a timing margin of +-22us. We want to port this project to CC1352p. How can we fix the start of transmission(first bit of preample) to a specific time with RF_SecheduleCmd ? How much is the maximum variation in this case other than the XOC ppm.

    We saw the details of the Rf Driver in Ti web page. Is there any pdf file avlb for the same?
  • 0 in reply to Bibin Varghese
    TI__Guru 58425 points
    Hi Bibin,

    There is no way to "fix" the first bit of preamble in terms of RF command parameters but you are free to specify the start time. From this point there is a setup phase in the radio that can be considered constant for each command. There is no official numbers on these, but you can measure these delays by routing out RF core signals and scoping these:

    dev.ti.com/.../signal-routing.html

    For example, RFC_GPO3 gives you an indication of when the transmission starts end (PA ramping + packet).

    Once you have determined the delay from start time -> on air you can adjust the start time of the command if you find this is needed (I would start by assuming you could do it purely based on start time in the radio command).

    The documentation on the RF driver is found either in dev.ti.com/tirex or inside the SDK documentation, there is no PDF version only doxygen. Information on the actual radio commands etc you can find in the Technical Reference Manual.