the CC2564 bluetooth stack run die ?

Hi,

Please advise on the service pack version that you're using.

Regards,
Gigi Joseph.

the BTPS Version : 4.0.2.1

the service pack is 1.2

Hi,

Please use the latest service pack (v 1.4). It's available at: processors.wiki.ti.com/.../CC256x_Downloads

Regards,
Gigi Joseph.

Hi,
Now our product use service pack V1.2 , but I don't want to updata to V1.4 , and why the service pack V1.2 don't run well ?
is it ok when I updata to service pack V1.4 ? Other person user the V1.2 has same this problem ? and what can I do it at V1.2 ?
thanks !

Hi,

There were a number of fixes between 1.2 & 1.4 (please see the above page).
It's likely that whatever you're seeing has already been fixed.

Regards,
Gigi Joseph.

Hi ,
I test the service pack V1.4 , but it also run die , the last CC2564 LOG is :

what's the meaning of LOG "ERROR: Data Abort !!!, Link Register: 0x1000104" ?

the complete LOG is (it include five files):

CC2564_LOG_20160526.zip

thanks !

Hi,

Data abort means that the chip became unresponsive and the only way to recover is to enable it again.

I could see that you're working with sniff attempt of 1 and interval of 0.5 seconds. This results in disconnection (link supervision timeout) right before the data abort.

As a quick workaround, please increase the sniff attempts to 4 and repeat the test. Let me know if the issue persists. I would recommend always working with number of attempts equal to 4.

In parallel, we'll look further to understand better what might be causing this issue.

Regards,

Tomer

Hi ,

I change sniff attempts to 4 and repeat the test , but it also run die , the CC2564B last LOG is :

the complete CC2564B LOG is (it include 6 files):

CC2564_20160527.zip

what's  the "ERROR....." ?

How can I do it ?

Hi ,
I change sniff attempts to 4 , then test it , it also run die , now how can I do it ?
(due to project is more urgent , thank you reply soon !)

Tomer, Joseph,
This is Andy who is FAE for this customer, my thinking to verify the Sniff attempt, I have asked customer extend the sniff attempt from 4 to 8, then test it and update with you.

Meanwhile, will you need more info of this issue?
For example, this issue would occur when test in VIVO smart phone with Android v5.0.
But when test it in Apple IOS and Samsung Android smart phone, so far have not found this issue.

So maybe related with Android phone difference? Any more suggestion?

Thanks.

Regards.
Andy

Thanks.

Trying to isolate the problem, could you please run the following command after initscript is loaded?

Send_HCI_Write_AFH_Channel_Assessment_Mode 0x00
Wait_HCI_Command_Complete_Write_AFH_Channel_Assessment_Mode_Event 5000, any, HCI_Write_AFH_Channel_Assessment_Mode, 0x00

This will disable the internal channel classification. If the issue is still reproduced, please send again FW logs.

Thanks,

Tomer

btw, I don't think that it's related to the sniff attempts. I could see that there are many disconnections caused by link supervision timeout. Is it by intention? meaning, did the device get out of range, or remote was shut down?

Hi ,
The sdk code don't find "Send_HCI_Write_AFH_Channel_Assessment_Mode " and "Wait_HCI_Command_Complete_Write_AFH_Channel_Assessment_Mode_Event " command ,
I only find "HCI_Write_AFH_Channel_Assessment_Mode" command , and I add this command after "BSC_Initialize" function , it can return 0.
is it right I do it ?

I make the device get out of range !

It should be right to use "HCI_Write_AFH_Channel_Assessment_Mode".

Everything should work normally even when you issue this command. Please share the FW logs, and I'll see if it was issued correctly to the controller.

btw, is the problem reproducible also with TI Evaluation Board? What platform are you using?

Hi ,
    I don't test at TI Evaluation Board STM3240G , now I test it at efm32 board , the bluestack is base on CC256XSTBTBLESW-v4.0.2.1-Setup ,
and I add the "HCI_Write_AFH_Channel_Assessment_Mode" command test it , and it run well , the CC2564 LOG is :

CC2564_20160603.zip 

would you please check LOG is correct ? please to  reply me !

Hi,

The log is correct. I suggest you use this command to overcome the issue. This doesn't mean that no AFH will be used, it just means that the device (TI's controller) will not do channel classification internally.
Also, since in the logs that you shared, TI's controller is the slave, so AFH map is being dictated by the master (peer device).

Regards.
Tomer

Tomer,

I visited and customer has not found this issue again based on your comment suggestion, we will continue test it and keep you update. 

thanks for support.

Regards,

Andy.