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.

Disconnection after 800 bytes of NV memory written

Other Parts Discussed in Thread: CC2540

Hi, I have a problem Hi,

I have a problem with TI BLESTACK 1.40
After about 10 times that I pair and unpair the CC2540 with the app on iPhone, it stop the connection with the iPhone and when I try to reconnect again, it try to do but always the operation fail.
A MCU reset not solve the problema. It depend of how many NV memory is wrote during the 10 times of pair-unpaid.
Each time that pair the CC2540 with the iPhone a buffer of about 50 bytes is wrote in NV, probably are the data of bonding like key long term key, ecc..
Only if the firmware will re-fleshed on the CC2540 the situation return to normal and the pair work, but again after abbot 10 operation on NV the problem is represented.
I have the iPhone 5S but is the same with iPad 4 and I use “LightBlue” by PunchThroughDesign. Both with iOS 7.1.1
In another BLE project I implemented a series of write data to the NV with SNV API form TI BLESTACK, and so after that i filled about of 300h of NV flash memory with some kind of data, the problem is out coming again with same effects:
  • disconnection from CC2540
  • trying to connect again, seems that do something, but after about 1-2 seconds disconnection again
Again only the re-flash of the fw reset this situation.
Anybody never see something like that ?
  • Hello,

    I am having the same problem.

    Have you fixed this issue?

    If yes, could you let me know what was the cause of the problem?

    Thanks.

    YS

  • Yes, I solved it.

    First of all I understood the cause of the problem, that is a too long task execution in my application. In my case I was a correlation of time duration of a particular my application task, with the pointer where the OSAL was arrived to write in the NV flash segment.

    But in general consider this use case:

    1) the BLE device with TI CC2540/41 is a BLE peripheral device

    2) you are connected with a central and you have an application task over than 50-60ms

    then

    3) the device do a disconnection from the central itself, because cannot guarantee the packet connection timing

    So, if this is also the cause of the issue in your case, the solution is to manually divide the operations in the long application task in sub-task (i.e. using a software periodic timer) with execution time under 50ms, but I suggest more more less then 50ms (in my case now the application sub-task is not over then 5ms).

    I hope that my personal experience will be useful for you and for community.

    Good work

    Gabriele Merlonghi

  • Dear Gabriele,

    Thank you very much for sharing valuable information.

    I'll try to implement what you taught.

    Thanks again.

    Best regards,

    YS

  • I suggest to use a digital output pin to put high when you enter in the application task and low when exit.

    So you can monitor the digital signal with oscilloscope to measure the time consuming of your application task.

    This is the best reliable way to go in the right direction and solve the problem.

    Instead to use an oscilloscope, I very suggest this logic analyzer: https://www.saleae.com low cost and with a fantastic user interface for free.

    Regards,

    Gabriele Merlonghi