• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 57 subscribers
  • Views 808 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

LP-CC1352P7: Basic project to transmit and receive an IEEE 802.15.4 frame

LP-CC1352P7: RF transmit fails: timestamp is 0

Karthik S
Prodigy 190 points

Part Number: LP-CC1352P7

Hi,

Trying to transmit packets over 802.15.4 channel.

In some scenarios(custom application),the RF transmit doesn't work ( SmartRF receiver shows nothing). While it works in some other scenarios.

On further debug/comparison,noticed that the 'timeStamp' variable doesn't update when the system doesn't work( stuck at zero).

Generally, how does that variablet get updated ? Under what conditions it gets stuck like this?

Please see the attached snapshot indicating the variable.Kindly help resolve this  issue.

Thanks

Karthik

  • 0
    TI__Mastermind 27457 points

    Hi again Karthik,

    According to chapter 25.5.4.4 of the devices's technical reference manual, the timeStamp value is only updated when the transmission has occured.

    It seems to corroborate the fact that the status of the command is set to zero in your capture, which means the transmit operation has not started yet.

    Are you certain that the startTrigger of your command is correctly defined?

    Regards,

    Arthur

  • 0 in reply to Arthur R☑️
    Prodigy 190 points

    Hi Arthur,
    Please see the attached. This snapshot is after a successful transmission.

    Not sure if I understand it properly, the startTrigger looks the same ( set to 0 always).

    This is how it is defined: RF_cmdIeeeTx_ieee154_0.startTrigger.triggerType = TRIG_NOW;

    What else can I check?

    Thanks

    Karthik

  • 0 in reply to Karthik S
    TI__Guru* 87251 points

    What Arthur meant is that in the case where the timestamp is 0, the status of the command is also 0 (status = 0x0000 = IDLE = "Operation not started"). 

    In the case where the timestamp is non-zero, the status is 9216 (0x2400) = EEE_DONE_OK = "Operation ended normally"

    In other words, your TX command has not even started.

    Why this is the case is not possible to say without more info on your code.

    To be able to help you further you need to provide a simple example that can be run on the LP that illustrate the problem. 

    Have you verified that your code is actually calling RF_postcmd/RF_runCmd in the case where it does not send?

    Siri

  • 0 in reply to Siri
    Prodigy 190 points

    Hi Siri,

    The RF_postCmd is called. Also, control switches to its corresponding callback function.

    I had put counters to verify it.

    About the timestamp observation: it looks stuck even though post command is executed several times ( while the command status is 0x2400 -> could be status out of successful transmit previously?).

    What else should I check?

    Thanks

    Karthik

  • 0 in reply to Karthik S
    TI__Mastermind 27457 points

    Hi Karthik,

    Is your counter incrementing as soon as the callback function is entered, or are you incrementing it after checking the event mask?

    What I mean is that you should try incrementing the counter only when the event mask returns a RF_EventTxDone, as seen in the rfPacketRx example:

    Regards,

    Arthur