• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 18 subscribers
  • Views 446 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.

CC1352P7: BLE and Proprietary sub-gig not functioning reliably using DMM on LP-CC1352P7-1

Jim Higgins
Prodigy 30 points
Part Number: CC1352P7
Other Parts Discussed in Thread: LAUNCHXL-CC1352R1,

Goal:

A working DMM project using a custom sub-gig application (such as rfEchoRx, where RX is on when idle) and BLE (Simple Peripheral) where the BLE interface can be reliably accessed from a mobile device while the custom sub-gig application (rfEchoRx) runs RX in the background.

Problem:

After following the DMM Integration tutorial we end up with firmware that can reliably receive packets on the sub-gig network, however BLE is starved and advertisements are rarely transmitted and a mobile connection is not possible on the LAUNCHXL-CC1352R1 board.  On the LP-CC1352P7-1 board we do see BLE adverts while the sub-gig receives, but as soon as a BLE connection is attempted it nearly always stops receiving on the prop. stack side and BLE stops transmitting.

Details:

  1. Two different developers have independently followed the DMM Integration tutorial and ended up with projects where the Custom 1 rxExhoRx app starves the BLE stack (R1), or is unstable (P7).
  2. We tried using both a LAUNCHXL-CC1352R1 and LP-CC1352P7-1 dev boards.
  3. We have tried using both the 5_40_00_40 and 6_10_00_29 SDKs.
  4. We have an Ellisys BLE sniffer and only on very rare occasions do we see a BLE advertisement transmitted from the LAUNCHXL-CC1352R1 board. On the LP-CC1352P7-1 board we do see BLE advertisements, but when a connection is attempted using the iOS LightBlue application in nearly all cases the prop stack stops receiving and the BLE stack stop transmitting.
  5. If we prevent the rxEchoRx task from entering RX mode, then the BLE stack operates normally and advertisements and mobile connections work perfectly.
  6. We have tried adjusting the GPT priorities to make BLE higher priority than PROP, but they seemingly have no effect.
  7. We have tried using various Balanced Modes (with the original GPT tutorial values, and other GPT values as well), but they seemingly have no effect.

Ask:

Provide a working project for the LP-CC1352P7-1 board based on the DMM Integration tutorial and latest SDK where the prop. sub-gig RX on when idle and BLE time multiplex correctly.

  • 0
    TI__Guru**** 202106 points

    Hi Jim,

    simple_peripheral_LP_CC1352P7_4_tirtos_ccs.zip

    Attached is the LP-CC1352P7-4 simple peripheral project for which rfEchoRx and DMM have been added using the DMM Integration SLA.  I did not notice any issues while evaluating the firmware, as both the prop RF and BLE peripheral functions could be operated as expected.  Please make sure to copy ble_user_config.c to your local workspace and directly apply the SimplePeripheral_fastStateUpdateCb changes as this could directly affect BLE stack and application state performance.

    Regards,
    Ryan

  • 0
    Prodigy 10 points

    Hello Ryan this project is for the wrong board. Can you please send the correct project for the correct board

  • 0 in reply to Ryan Brown1
    Prodigy 30 points

    Hi Ryan, Thanks for the project.  I was able to convert the project to use the LP-CC1352P7_1 hardware. Some quick testing shows that it is working much better than my project., however I need to do some more careful testing to be certain.

    I started diffing my project with yours and, so far, I have found one important difference that might be the cause of the problem. In your project's rxEchoRx.c you have the following:

    /* =========== Populated parameters =========== */
    scheduleParams.startTime = 0;
    scheduleParams.startType = RF_StartNotSpecified;
    scheduleParams.allowDelay = RF_AllowDelayAny;
    scheduleParams.duration = ~(0); // The CMD_FS will run until done
    scheduleParams.endTime = ~(0); // The CMD_FS will run until done
    scheduleParams.endType = RF_EndNotSpecified;
    scheduleParams.activityInfo = GEN_ACTIVITY_TABLE(RfActivity_Fs, DMM_StackPNormal);
    /* ============================================= */
    RF_ScheduleCmdParams_init(&scheduleParams);

    Whereas the tutorial shows the sequence this way:

    RF_ScheduleCmdParams_init(&scheduleParams);

    /* =========== Populated parameters =========== */
    scheduleParams.startTime = 0;
    scheduleParams.startType = RF_StartNotSpecified;
    scheduleParams.allowDelay = RF_AllowDelayAny;
    scheduleParams.duration = ~(0); // The CMD_FS will run until done
    scheduleParams.endTime = ~(0); // The CMD_FS will run until done
    scheduleParams.endType = RF_EndNotSpecified;
    scheduleParams.activityInfo = GEN_ACTIVITY_TABLE(RfActivity_Fs, DMM_StackPNormal);
    /* ============================================= */

    I assume that calling RF_ScheduleCmdParams_init() after filling out the scheduleParams stack variable is correct in your project and that the tutorial is wrong, what do you think?

    Best Regards,

    Jim

  • 0 in reply to Jim Higgins
    TI__Guru**** 202106 points

    Hello Joseph,

    I only had a LP-CC1352P7-4 to evaluate, however the only difference between this and the LP-CC1352P7-1 hardware is the PA output path which does not matter if neither the 2.4 GHz or Sub-1 GHz components use the internal power amplifier.  Such is the case with my project and thus the firmware can be used for either LaunchPad version.

    Hi Jim,

    My code using RF_ScheduleCmdParams_init after populating the parameters was a mistake on my part, fortunately it does not affect the project's operation since most fields set are default.  The one exception, activityInfo, is immediately set afterwards for the prop RX command and thus the error does not affect device behavior.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 30 points

    Hi Ryan,

    I have not gone back to look at why the LAUNCHXL-CC1352R1 board didn't work for me, but I think the project you created and the one I made for the LP-CC1352P7-1 board are working similarly.

    After closer inspection of the analyzer traces and some experiments using nRF Connect instead of LightBlue. I think that most of the problems I am seeing relate to application layer timeouts in the LightBlue application as it reads all the attributes after making a connection. I modified some of the timing parameters for the BLE connection and it worked better.

    I'm working on implementing the mobile application side, which will give me more control and information to me about the connection dynamics.

    Until then I'm accepting your answer since you provided what I requested.

    Cheers,

    Jim