• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 720 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.

CC2652P: CC2652P

Roberto Nucera
Intellectual 265 points
Part Number: CC2652P
Other Parts Discussed in Thread: CC1352P

Tool/software:

Dear Ryan,

We are currently working on the dmm_zed_switch_remote_display_app_CC1352P_2_LAUNCHXL_tirtos7_ticlang project and would like to clarify a few points regarding the Zigbee and BLE stacks:

  1. The Zigbee stack appears to be functioning correctly.

  2. The BLE stack seems to be partially working — we can detect the device using the LightBlue application — but we have a few questions:

    a. Establishing a connection with LightBlue takes approximately 10 seconds, despite our device advertising with a period of around 100 ms. Is this delay expected, or is there a configuration we should review?

    b. We are currently able to send data from LightBlue to the device (both single characters and strings), and we handle it using the function RemoteDisplay_processAppMsg(pMsg). Can you confirm this is the correct approach?

    c. What function or API should we use to send data (e.g., a character or string) from the device back to the LightBlue application?

Thank you in advance for your support.

  • 0
    TI__Expert 5260 points

    Hello,

    Thank you for reaching out!

    Roberto Nucera said:
    Establishing a connection with LightBlue takes approximately 10 seconds, despite our device advertising with a period of around 100 ms. Is this delay expected, or is there a configuration we should review?

    This could be for a number of reasons, and the issue could be on either the central or peripheral side, or it could be due to encryption. A packet sniffer log may clarify the reason for this delay.

    Roberto Nucera said:
    We are currently able to send data from LightBlue to the device (both single characters and strings), and we handle it using the function RemoteDisplay_processAppMsg(pMsg). Can you confirm this is the correct approach?

    That is one way of doing it. You could also access the values you are writing to the service's characteristics by going to the LightProfile_GetParameter() function inside of: software_stacks -> ble_stack -> profiles -> light_gatt_profile.c

    Roberto Nucera said:
    What function or API should we use to send data (e.g., a character or string) from the device back to the LightBlue application?

    By sending data, do you mean handling read requests? If so, using LightProfile_SetParameter() should be a good place to start!

    I hope this answers your questions! If you have any more questions, or need some clarification, don't hesitate to reach out.

    Best Regards,

    Tarek

  • 0 in reply to Tarek D
    Intellectual 265 points

    Hello Tarek,

    Thank you very much for your prompt and clear response!

    We'll follow your suggestions — especially checking with a packet sniffer to better understand the connection delay, and exploring the LightProfile_GetParameter() and LightProfile_SetParameter() functions for handling data communication between the device and LightBlue.

    We'll run some tests and get back to you if we encounter any further issues or need additional clarification.

    Thanks again for your support!

    Best regards,
    Roberto

  • 0 in reply to Roberto Nucera
    Intellectual 265 points

    Dear Tarek,

    Following up on our previous discussion, I’d like to provide you with more technical details about an issue we’re encountering while extending our BLE functionality.

    We’re working on a DMM project based on the dmm_zed_switch_remote_display_app_CC1352P_2_LAUNCHXL_tirtos7_ticlang example. On the Zigbee side, we have implemented control of 8 separate endpoints (e.g., for 8 loads). To mirror this functionality on the BLE side, we defined 8 GATT characteristics — one for each endpoint — to allow control via a mobile app like LightBlue.

    Here is what we’ve observed:

    • With 1 or 2 BLE characteristics, everything works as expected: we can write values from LightBlue, receive them on the device, and trigger the corresponding actions.
    • As we add more characteristics (e.g., for endpoints 3 and up), we encounter critical instability:

      • The WriteAttrCB callback is triggered correctly for higher-indexed characteristics (e.g., endpoint 4), and the action is executed: writing “1” from LightBlue correctly turns the endpoint ON, and writing “0” turns it OFF.

      • However, after a few successful toggles, writing again (e.g., “1” to endpoint 4) has no effect — the endpoint does not react.

      • From that point on, none of the endpoints can be controlled anymore via BLE. Although the WriteAttrCB continues to be triggered in debug, the BLE task no longer runs, and RemoteDisplay_processAppMsg() is no longer called.

      • As a result, BLE events are no longer processed (e.g., disconnection events), and the device stops advertising — it becomes “invisible” until we reset it manually.

      • With only 1 or 2 endpoint characteristics (plus the default ones from the example), this behavior never occurs: everything works reliably, even after repeated toggling.

      This leads us to suspect either a stack overflow, event queue overflow, or a task starvation issue — possibly triggered by exceeding internal limits on attributes, heap, or task resources.

      Would you recommend inspecting the BLE task queue, stack size, or related configuration to identify the bottleneck?

      Are there any heap or memory pool settings that we should tune to support more characteristics?

      Thank you in advance for your support.

    • 0 in reply to Roberto Nucera
      TI__Expert 5260 points

      Hello Roberto,

      Thank you for the info! I will look into this and provide a response by tomorrow.

      Best Regards,

      Tarek

    • 0 in reply to Roberto Nucera
      TI__Expert 5260 points

      Hello Roberto,

      This is certainly strange behavior. For building the Gatt table and using it accordingly, i would recommend taking a look at the basic_ble example, specifically the simple_gatt profile found in common -> Profiles. If you have any questions regarding it please don't hesitate to ask.

      This could also be something related to exhausted resources. Have you checked the memory allocation?

      Best Regards,

      Tarek

    • 0 in reply to Tarek D
      Intellectual 265 points

      Dear Tarek,

      Thank you for your support and the helpful recommendation.

      We were able to identify the root cause of the BLE instability. The issue was not due to the GATT table definition itself, but rather caused by a Zigbee stack call (specifically zclSampleSw_updateCurrentSummationDeliveredAttribute) invoked from the BLE context. This interaction occasionally caused the BLE task to stall (looping between READY, RUNNING, and PREEMPTED states) and halted advertising, especially when writing to characteristics for higher-indexed endpoints.

      We resolved the problem by increasing the BLE task priority from 1 to 2, now the three tasks have the same value. This change allowed proper scheduling and prevented the BLE task from being starved during execution. Since making this change, all characteristics now work reliably across all 8 endpoints.

      Regarding your suggestion to look into the simple_gatt profile in the basic_ble example: yes, we have reviewed it, and it was quite helpful in guiding the implementation and confirmation of best practices when defining and using custom characteristics.

      Thanks again for your assistance.

      Best regards,
      Roberto Nucera