• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 51 subscribers
  • Views 534 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.

CC2650: Peripheral is not receiving a Write Request from Central

Maximilian Ernesto
Prodigy 80 points

Part Number: CC2650

Hi guys,

I used as base for my project the SimpleBLEPeripheral to connect with a smartphone working as central the central device have months running perfectly and is communicating fine with others peripherals.

The issue I am facing is with the SimpleBLEPeripheral it works the major part of time receiving the write request from my central, but around the 30mins+ the peripheral stops to receive and the connection keep alive. Inside of SimpleBLEPeripheral_processCharValueChangeEvt on the Case SIMPLEPROFILE_CHAR1 it not getting fire some times. using the TI BLE sniffer I am able to see the data that is "not" receiving the peripheral.

it happens randomly and if I kill the connection after the this issue always happen the same, the only solution is a hardware reset, but it is not safe for my application any suggestion?

hardware cc2650

ble_sdk2_02_01_18

pd: I did not made major changes to the example..

Thanks,

Max

###UPDATE### It issue always happens in average when is the 190th connection between the peripheral and central

  • 0
    TI__Guru** 105180 points
    Hello Max,

    Did you add some custom code to the simple_profile? I would check for memory / heap exhaustion and/or task stack issues. These problems can manifest into inconsistent protocol stack behaviour.

    Best wishes
  • 0 in reply to JXS
    Prodigy 80 points

    Hi JXS,

    Yes, I added UART_read() inside SimpleBLEPeripheral_taskFxn in the main loop for (;;) and I added few functions for solve basic equations.

    The equations are simple and I think it does not add an excessive timing to the main loop, My concern is about UART_read() inside the loop, but I am using it in UART_MODE_CALLBACK mode not UART_MODE_BLOCKING that blocks the task execution until all the data in buffer has been read


    Max