• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 422 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.

LAUNCHXL-CC1352P: DMM Integration: rfEchoRx -> 'abrupt command termination'

Turo
Prodigy 92 points
Part Number: LAUNCHXL-CC1352P
Other Parts Discussed in Thread: SYSCONFIG

I have followed the SimpleLink Academy - 5.40.00.00 DMM Integration -lab to build simple_peripheral and rfEchoRx -DMM application.

Code Composer Studio 11.1.0.00011, win10 and two LAUNCHXL_CC1352P1.

Initial example programs:

simple_peripheral_CC1352P1_LAUNCHXL_tirtos_ccs

rfEchoTx_CC1352P1_LAUNCHXL_tirtos7_ccs

rfEchoRx_CC1352P1_LAUNCHXL_tirtos7_ccs

The rxEchoRx - Tx and simple_peripheral examples work initially.

I've tried to triple check the modification steps of the lab in my code.

I can read the characteristics with my phone from simple_peripheral, so i guess the BLE is working correctly on this DMM-application example i have build.

Problem is that in rfEchoRx.c -file:

RF_EventMask terminationReason = RF_runScheduleCmd(rfHandle,
                                 (RF_Op*)&RF_cmdPropRx,
                                 &scheduleParams,
                                 echoCallback,
                                 (RF_EventRxEntryDone | RF_EventLastCmdDone));

returns 'RF_EventCmdAborted' and

uint32_t cmdStatus = ((volatile RF_Op*)&RF_cmdPropRx)->status;

returns 'PROP_DONE_ABORT'

This is almost immediate (running debugger) and it doesn't matter if the rfEchoTx-board is running or not.

I tried to change the command above to 'RF_scheduleCmd()', but it returns 0x3. I also tried to increase DMM-stack priority for prop rx-tx.

Also in

syscfg / RF STACKS / BLE / Broadcaster Configuration / Number of Advertisement Sets = 1

theres a warning "The example app code handles 2 advertisement sets. Please make sure to update the example app code according to the configured number of sets", even though i have followed the lab tutorial.

I hope you can help getting this working.

  • 0
    Prodigy 92 points

    I wonder that in the tutorial, there was no added Application states for the PROP, like for example DMMPOLICY_PROP_TX_RX?

  • 0
    TI__Guru* 81911 points

    Hi Turo,

    I will try to reproduce the issue you are seeing and get back to you.

    Cheers,

    Marie H

  • 0 in reply to Marie H
    Prodigy 92 points

    Thank you.

    I have been debugging a lot now. Checking every return in the main and in the rfEchoRx.c. Trying with different optimization options, GPT-values and DMM Policy settings in syscfg.

    Could it be that i don't have these project in the beginning (i don't have these in the sdk):

    rfEchoRx, found under <SDK>/examples/rtos/<BOARD>/drivers/
    rfEchoTx, found under <SDK>/examples/rtos/<BOARD>/drivers/

    but these:

    C:\ti\simplelink_cc13xx_cc26xx_sdk_5_40_00_40\examples\rtos\CC1352P1_LAUNCHXL\prop_rf\rfEchoRx\tirtos7\ccs
    C:\ti\simplelink_cc13xx_cc26xx_sdk_5_40_00_40\examples\rtos\CC1352P1_LAUNCHXL\prop_rf\rfEchoTx\tirtos7\ccs

    ?

    could the tirtos7 cause problems?

  • 0
    Prodigy 92 points

    I implemented DMM scheduler preemption callback function to rfEchoRx.c and registered it in main with:

    // main.c
DMMSch_registerPreemptionCb(DMM_scheduler_preemption_CB);

// rfEchoRx.c
void DMM_scheduler_preemption_CB(DMMPolicy_StackRole stackRolePreempted) {
    if (stackRolePreempted == DMMPolicy_StackRole_custom1) {
        preeemted_counter++;
    }
}

    This gets called right after a call to this:

    // rfEchoRx.c
RF_EventMask terminationReason =
            RF_runScheduleCmd(rfHandle,
                              (RF_Op*)&RF_cmdPropRx,
                              &scheduleParams,
                              echoCallback,
                              (RF_EventRxEntryDone | RF_EventLastCmdDone));

    I have a feeling that for some reason the DMM cancels the Sub-GHz rf-commands right away it gets them?

  • +1 in reply to Marie H
    Prodigy 92 points

    Any news regarding the issue? Cheers

  • 0 in reply to Turo
    TI__Guru* 81911 points

    Hi Turo,

    You're correct that the RF commands are aborted. (terminationReason = RF_EventCmdAborted.)

    I'm looking into why the DMM scheduler is preempting the commands, hopefully I will have an snswer for you next week.

    Cheers,

    Marie H

  • 0 in reply to Turo
    TI__Guru* 81911 points

    Hi Turo,

    Can you set a breakpoint in the code below and see if you're receiving packets ok?

    The aborts/preemptions are intentional: 

    PROP_DONE_ABORT comes into this DMM example because of the BLE priority.  When the BLE stack requires the radio resource, the DMM weighs the application states and stack activity of each stack, and when it determines that BLE needs to have the radio then it will abort the RF_cmdPropRx command so that the BLE can accomplish what it needs to.  So the receive command currently running (it’s originally intended as an “always on/listening” design) does appear aborted, but once the BLE command is finished the proprietary radio can resume listening for a message from the rfEchoTx device.  The DMM application weighs the stack activity and application states fairly well given that the transmitting device rarely (if ever) misses a confirmation from the receiving device so far as I have observed.

    Cheers,

    Marie H

  • +1 in reply to Turo
    TI__Guru* 81911 points

    Hi Turo,

    I found my issue. I have been using CC1352P7-1. Please check if this is the same issue on CC1352P-1.

    When I add a new Custom RF Stack in Sysconfig, the frequency was set to 915 MHz by default. However, in the rfEchoTx project, the default frequency is 868 MHz. Thus I was sending and transmitting on two different frequencies, no wonder I didn’t get any packets. 

    When I change the DMM enabled project to use 868 MHz the packets are echoed as expected.

    Cheers,

    Marie H

  • 0 in reply to Marie H
    Prodigy 92 points

    Have this been updated into the tutorial?

    Cheers

  • 0 in reply to Turo
    TI__Guru* 81911 points

    Hi Turo,

    Since this is device dependent I will add a note reminding the user to compare the frequency used in rfPacketTx and the DMM enabled example. I'm not sure when this update will be published.

    Cheers,

    Marie H