• State
  • Replies 9 replies
  • Subscribers 54 subscribers
  • Views 165 views
  • Users 0 members are here
Support feedback
Options
Options
Related

LP-EM-CC1354P10: DMM 15.4 Collector + BLE Remote Display: Unable to set Remote Display PHY

Andrew Featherstone
Prodigy 10 points
Part Number: LP-EM-CC1354P10
Other Parts Discussed in Thread: CC1354P10, BLE-STACK, ENERGYTRACE, CC1352P, CC1352P7

Tool/software:

I am Using the latest release of the SimpleLink SDK installed to the default location on disk with the LP-EM-CC1354P10 and following the example from "C:\ti\simplelink_cc13xx_cc26xx_sdk_8_31_00_11\examples\rtos\LP_EM_CC1354P10_1\dmm\dmm_154collector_remote_display_app".

From the README.html:

"To demonstrate the use of the CUI, let us change the BLE PHY. First, use the arrow keys to select the TI Remote Display menu. Pressing the ENTER key will take us to the TI Remote Display menu. Next, we see the option to CONFIGURE or go BACK to the previous menu. Make sure CONFIGURE is selected and hit the ENTER key to enter the CONFIGURE menu. Here, we have the option to SET PHY. After pressing ENTER once more, we can select a PHY. Chose the 2M PHY. You should see confirmation of this on the UART display, as shown below."

Expected Behaviour:

When I work these steps, I should get a matching output to the CUI as in the README.html, i.e.

BLE PHY STATUS: PHY Updated to 2M

Observed Behaviour

When I do this, I always get an error message:

BLE PHY STATUS: PHY Update Status Event: 0x12

Scanning for device using a smartphone suggests that it is not advertising.

This same error occurs with other "DMM" demos, e.g. "DMM Zigbee Coordinator + BLE Remote Display", but I'm particularly interested in the combination of the TI 15.4 Stack and BLE.

  • 0
    TI__Guru* 82271 points

    Hi Andrew,

    Is your CC1354P10 device in a BLE connection when you do this test? I think it's only available while in a connection (you can see the screen shot lists Num Conns: 1). 

    Status 0x12 corresponds to bleIncorrectMode (defined in bcomdef.h). 

    Cheers,

    Marie H

  • 0 in reply to Marie H
    Prodigy 10 points
    Marie H said:
    Is your CC1354P10 device in a BLE connection when you do this test?

    No, the device is not advertising on the BLE interface, therefore it cannot be 'connected' to.

    Marie H said:
    I think it's only available while in a connection

    Please can you expand on the rationale here: what makes you think that, other than looking at the screenshot?

    Please can someone at TI try to reproduce the issue locally using matching hardware and software and provide their feedback?

  • 0 in reply to Andrew Featherstone
    TI__Guru* 82271 points

    Hi Andrew,

    You can read about the different ways PHYs are selected in the BLE-Stack in this SimpleLink Academy lab.

    https://dev.ti.com/tirex/explore/node?node=A__ASq6PWFlfjfwUQmy2BPt1w__com.ti.SIMPLELINK_ACADEMY_CC13XX_CC26XX_SDK__AfkT0vQ__LATEST&placeholder=true

    In the application logic, it doesn't make sense to request to change to LE 2M PHY if you're not in a connection, hence the bleIncorrectMode error.

    Can you check that your device is able to advertise before this happens? If you want an easy way to check, you can use EnergyTrace and look for the characteristic BLE advertisement pattern (wake-up, transmit-recieve-transmit-receive-transmit-receive).

    https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_8_31_00_11/docs/dmm/dmm_user_guide/html/energy-trace/energy-trace.html 

    Cheers,
    Marie H

  • 0 in reply to Marie H
    Prodigy 10 points
    Marie H said:
    Can you check that your device is able to advertise before this happens?

    Using EnergyTrace, there's no obvious sign that the device is transmitting (no clear increase in current consumption).

    I am using the LightBlue v2.7.0 app on a Google Pixel 6A, which is able to see advertising packets from other nearby BLE apps.

    Are you able to try and reproduce the issue using your own hardware and software?

  • 0 in reply to Andrew Featherstone
    TI__Guru* 82271 points

    Hi Andrew,

    This just looks like noise. (It might help to unplug and replug the usb cable after opening EnergyTrace.) In any case you should see it quite clearly when the radio is active.

    Did you make any code changes to the example?

    Cheers,

    Marie H

  • 0 in reply to Marie H
    Prodigy 10 points

    Marie H, are you able to try and reproduce the issue using your own hardware and software? Have you tried this locally, and what happens when you try?

    Marie H said:
    (It might help to unplug and replug the usb cable after opening EnergyTrace.

    This has not had any affect.

    Marie H said:
    Did you make any code changes to the example?

    No, it is unchanged.

    Please can you try and reproduce this issue locally?

    Edit:

    An example that does work is the project `dmm_154collector_remote_display_app_LP_EM_CC1354P10_1_tirtos7_ticlang` in version 7.41.00.17 of the SDK. The screenshot shown below is TI's SimpleLink Connect version 2.1.0. The phone and LaunchPad on the same desk, so I think we can be confident that the RF path can work, and I'd like to verify that the DMM examples do work.

  • 0 in reply to Andrew Featherstone
    TI__Guru* 82271 points

    Hi Andrew,

    I am able to reproduce what you're seeing: The example is not advertising over BLE.

    Since the energy trace measurement corresponds to RX power consumption, I'm wondering whether the device might be only listening on Sub-1 and not allowing any BLE advertisements.

    However based on the readme, the Collector should not start RX before you manually open the TI 15.4-Stack network.

    Unfortunately I don't have resources to investigate this further.

    Cheers,

    Marie H

  • 0 in reply to Marie H
    Prodigy 10 points
    Marie H said:
    I am able to reproduce what you're seeing: The example is not advertising over BLE.

    It is excellent that you can reproduce the issue at TI using your own software and hardware.

    Marie H said:
    However based on the readme, the Collector should not start RX before you manually open the TI 15.4-Stack network.

    OK, but the Sub-GHz Rx path is not the problem here, it's the lack of BLE advertising. The counterpart to this example is the 'sensor', which is meant to be provisioned over BLE with information about the Sub-GHz network.

    The purpose of the DMM is that the chips should/can support two protocol stacks concurrently. If I understand your message, you've acknowledged that there's an issue with TI's software running on TI's hardware, and not user error on my part.

    Marie H said:
    Unfortunately I don't have resources to investigate this further.

    I don't understand your statement here. 

    What is TI's next step to fix this?

    Are you going to try and reproduce the issue on LaunchPads with other chips, e.g. the CC1352?

  • 0 in reply to Andrew Featherstone
    TI__Guru* 82271 points

    Hi Andrew,

    I will try to get back to you on Monday with a plan.

    In the mean while: If you can test CC1352P or CC1352P7 it would be helpful. We have seen some other issues with DMM on CC1354P10 where CC1352 is not affected.

    Cheers,

    Marie H