[参考译文] CC2564C：mSBC over HCI 问题。

下面是我们在此主题上提出的问题的链接。

cc2564c-msbc-over-hci-packets-getting-corrupted.

谢谢！

为什么您使用的是基于 HCI 的 msbc、而不是辅助 WBS？

尊敬的 Kobi：

这不是一种选择。 因为我们需要 BLE 与 HFP & A2DP 配置文件共存。

此致！

尊敬的 Kobi：

您可以访问以下链接以了解我们的问题和项目的背景。

cc2564c-msbc-over-hci-packets-getting-corrupted.

我们也在这一特定产品上与 TI 进行了密切合作。 我会以区经理的身份分享详情。  

需要注意的关键点：我们目前不能选择辅助模式、因为我们需要 BLE 共存。

我们希望获得解答的要点：为什么在某些特定电话上发现了此问题？ 是否存在影响 cc2564C 进入此状态的对 SCO 参数的依赖性？

此致！

再看一下(我不是 HFP 专家)、缓冲区似乎可以碎片化(因此一个 mSBC 帧可以从一个 HCI 帧开始、然后在下一个帧继续)。 我认为您应该将其复制到某个临时缓冲区、并在从0xAD 同步字开始有完整帧可用时进行调用。  

我将在本周稍后时间阅读并提供更多详细信息。  

尊敬的 Kobi：

是的、作为一个补丁、我们正在执行指针更新过程。

但问题是、 如果位填充或偏移超过4或6字节、则音频质量会随着颗粒等而变差 由于 mSBC 数据为60字节、 我们将偏移指针、因此为了确保最后一个字节 mSBC 解码将是垃圾邮件(如果偏移4个字节、则可用数据仅为56个字节、其余4个字节将会从该数据包中发出)。  

在第二种方法中、将数据存储到缓冲区中并执行偏移、这似乎也没有吸引力。 正如我们对随时间变化的数据进行的分析一样、数据似乎没有被 HCI_Packet 分成。

此致、

Vishnu

尊敬的 Kobi：

我们要获取的另一个数据。

在以下 e2e 线程 cc2564c-corrupted-msbc-data-seared-with-voice-over-hci 中 ，

Vihang Parmar 在最后一条评论中提到了通过电子邮件沟通的内容。

您能得到详细信息吗？  如果 TI 已经有了一些这方面的发现 、那么最好看一看。

谢谢！

感谢您的参考。 我将尝试从 Vihang 获取信息。

尊敬的 Kobi：

是否有关于此问题的任何更新？

谢谢！

无更新。 我仍在等待 Vihang 的响应。

他记得几个与通过 HCI 的语音问题、但需要检查细节。

我将对他执行 Ping 操作、让您了解调查结果。

好的。 请执行。

该产品已经推向市场。

我们需要尽快解决此问题。  

我们收到了很多关于这个问题的投诉。  

谢谢！

我们将尽快寻找答案。

尊敬的 Kobi：

有更新吗？

我知道、您仍在等待维也纳响应。  

同时、我们是否可以尝试使用任何参数、以便不会发生问题或降低问题率？

此致、

我们仍在研究 这一问题，但所花的时间比我们想象的要长。

我会在 遇到任何情况时立即更新。

尊敬的 Kobi：

感谢您的努力。  

它正在等待响应。

(仅供参考、如果您尝试重现此问题。 为此 、我可以帮助您。)

此致

尊敬的 Kobi：

有更新吗？

您能否至少分享您在此方面了解的最起码的细节？

这将有助于我们向前迈进。  

至少让我知道问题是否有解决办法。  

是硬件还是堆栈中？

我们对这个问题非常锁定。 请提供帮助。

此致、

是否有更新？

感谢您提供的信息。

这种限制是否 源于硬件或堆栈相关？  

此致、

它是否与任何 SCO 参数有关？ 为什么我们只在某些特定电话上观察到该问题？

在某些手机中、故障率太低。

一些手机如三星, iPhone 7 显示的问题非常高。

有些 iPhone 没有显示问题、有些 Redmi 也没有观察到问题。 有没有理由这样做？  

谢谢！

尊敬的 Kobi：

感谢您的 真诚响应。  

我知道该问题是硬件和堆栈的一部分。  

最好在数据表中清楚地提及这一点。  

此外、我知道 TI 不会进一步支持这种芯片组。

考虑到所有这些要点、  

TI 是否可以 将堆栈作为源代码提供、以便我们可以尝试进行工作和调优以使其进入某个更好的状态。 正如我已经提到的，我们对这一问题将处于非常糟糕的状况。 设备已送达客户手中。 HFP 调用是我们的主要功能之一。  

 是否可以在不中断 SCO 连接的情况下定期复位内部 SCO 缓冲区？  

谢谢！  

您好！

由于法律问题、我们无法提供堆栈源。

我将尝试检查缓冲器的定期复位。

Br、

Kobi.

尊敬的 Kobi：

是的、请检查缓冲器复位选项、并告诉我有关该选项的信息。 表上登记、

另一方面、我们计划执行一些测试、正如您在我们的测试设置中建议的那样。

完成这项测试设置

STM32F4 MCU 用作 I2S 主器件。

CC564C 作为 I2S 从器件。  

当出现窄带 HFP 连接时、我们将切换到 PCM 模式。

在其他情况下 ( A2DP / mSBC ),我们将继续 通过 HCI 本身使用音频。

您认为这种方法存在任何潜在问题吗？

谢谢、此致

Vishnu.

尊敬的 Kobi：  

有任何关于这一点的更新吗?

是否可以复位缓冲器？

谢谢！

似乎没有一种在不重置整个连接的情况下重置缓冲区的简单方法。

感谢您提供信息。

尊敬的 Kobi：

感谢您的帮助。

我想知道一些与此相关的东西。

当 SCO 处于活动状态且某些 ACL 流量并行出现时，我们观察到系统正在进入 Hangstate，我们发现 在 RXThread()中执行特定行时总是发生挂起(此函数在 hcitrans.c 中)。   

具体行如下：

 有任何有关此行为的信息吗？

就在该问题被触发之前、我们观察到 SCO 数据包的模式为 GBGBGBGBGBGBGBGBGB。 有时、GBGBGBGBGBBGBGBGBGBG...、(其中 G 表示 Goodpacket、B 表示 SCO 在 HCI 中的 BadPacket)。

有任何有关此行为的信息吗？

谢谢！

因此、您仍在尝试通过 HCI 与 SCO 合作、对吧？

正如我之前告诉过的、这个界面以前有几个问题-尽管我不熟悉您提到的具体问题。

因此、您仍在尝试通过 HCI 与 SCO 合作、对吧？

由于该产品已有1000多名客户、  我们必须做得对吗？  

在未来几个月内、它将达到4000多位用户。

之前在我提出问题时、TI 没有明确告知问题在于硬件、因此没有任何修复方法。

仅供参考、我们甚至已针对这些特殊问题向 TI 发送了我们的电路板。  

如果 TI 已确认问题并在数据表中清楚地提及、则我们不会在这种情况下结束。

是的、在下一个硬件版本中、我们正在考虑移除 Voice-over HCI 部分。

但这并不能解决现有用户的问题。

如果告诉用户硬件存在问题、那么情况将非常糟糕？

我们试图通过使用 FW 进行检测并测试 SCO 来掩盖此行为、以便用户无需受到这些问题的影响。

我理解 你身边的无助感,  

但我还必须探索任何可以改善用户体验的可能方法。

谢谢！

这种"休眠状态"的本质是什么？ 您看到任何中止或异常吗？  

它可能与线程的堆栈大小有关-可以尝试增加 RxThread 堆栈(RX_THREAD_STACK_SIZE)吗？

还要尝试增加 项目的堆大小以消除其他存储器问题。

这种"休眠状态"的本质是什么？ 您看到任何中止或异常吗？

发生这种情况时、我们没有观察到任何中止或异常。

此挂起触发后、(仅供参考、我们使用的是 Bluetopia Stack 的 FreeRTOS 版本、并且我们使用的是最新的服务包。)

*定时器停止工作。

*与 CC2564C 的 UART 通信中断。

*Debug UART 打印工作正常。

*系统中的另一个音频线程仍在运行。

*我们观察到 osMessagePut ()无法对消息进行排队。 (即使它与 Bluetopia 栈无关、也会观察到这种情况)。

*我们还发现 Bluetopia 的堆栈大小正在迅速减小。 但是、当问题发生时、堆栈仍然具有约7KB 的空闲存储器。  如果我们增加 Bluetopia 栈大小、则可以看到7kB 点变为12kB (假设我们增加5kB 的 栈)。 数据并非准确值、而是围绕这些值。 堆栈快速减少发生在3-4 秒内、从触发点到挂起点、此时堆栈减少 3-6 KB。 (我认为这种减小是因为 UART RX 数据通过 BTPS_Malloc ()馈入。) 对于内存使用数据,我们使用了 "BTPS_QueryMemoryUsage()"函数。

我们在这里的另一个主要观察结果是、当器件具有2个主器件时(CC2564C 连接到2个其他器件时的情形)。

例如 CC2564C 充当这两个器件的从器件、在这种情况下、此问题会在10到20个周期内发生。

如果 CC2564C 上的连接类似于1个主设备和1个从设备、则需要3-7分钟左右的时间才能解决此问题。

如果 CC2564C 是两个连接的主器件、则不会观察到问题。  

我不知道我们如何将这与进入巴德州的堆栈联系起来，但这是我们的观察。

它可能与线程的堆栈大小有关-可以尝试增加 RxThread 堆栈(RX_THREAD_STACK_SIZE)吗？

 我无法在 HCITRANS 配置文件中找到"RX_THREAD_STACK_SIZE"。

但我们已经在下面的行中增加了 RXThread STACKSIZE  

/*创建一个将处理接收到的数据的线程。 */
UartContext.ReceiveThreadHandle = BTPS_CreateThread (RxThread、1600、NULL)；  

在这个1600里是我们通常使用的东西。  我试着把它增加到3200但仍然有问题,没有观察到任何变化.

还要尝试增加 项目的堆大小以消除其他存储器问题

是的、我们尝试了更改它们。 但没有观察到变化。 此外、我们还尝试将线程优先级更改为 RealTime、但仍然不能顺利。

我们 为 FreeRTOS 分配了80KB、为 Bluetopia 分配了30KB。 我们采用125DMIPS (100MHz)的 STM32F4处理器。

谢谢！

尊敬的 Kobi：

当设备挂起时、我正在附加 BT 记录器日志。

这是问题发生时的部分。 (它不是这个部分、在这里周围)。

您可以查看线号-  922254.

e2e.ti.com/.../Device_5F00_Hangedin-RXTHread_5F00_Reduced.zip

问题行为类似于触发 ConfigASSERT。  (#define configASERT( x ) if ((x)==0){ for (;;;);})  //在尝试启动计时器 ID 为 NULL 的计时器时，我复制了此参数。

行为为 ostimer 行为错误、消息队列不工作等

我尝试将  ConfigASSERT 函数替换为  

#define configASSERT ( x ) if ((x)==0){taskDISABLE_interrupts(); rvUserAssertInformFunction (__file__,__line___); for (;;);}

但是、发生此问题时、configASERT 无法调用。

是否有可能触发堆栈内的循环或 while 循环存在无限循环？

此外、关于您刚才提到的另一点

"这种"休眠状态"的性质是什么？ 您看到任何中止或异常吗？ "

我是否必须注册特定回叫或异常捕获程序才能获得这些异常？

此致、

什么是  osMessagePut ？  

如果您没有得到任何输入、如何知道音频线程仍然正常工作？

您如何知道调试 UART 正在工作？ 正在发送什么消息？

如果 应用 没有崩溃(因为它似乎是),那么它可能与内存损坏无关,而是与线程同步。

如果您填充了邮件队列、请尝试增加队列大小。

什么是  osMessagePut ？  

这是一个用于管理队列的 FreeRTOS 函数。 我们将其用于 Statemachine 处理。

如果您没有得到任何输入、如何知道音频线程仍然正常工作？

音频是由 I2S 事件触发的自由运行线程。 所以它将继续运行。 无论数据是否来了、都没有关系。  

您如何知道调试 UART 正在工作？ 正在发送什么消息？

我们可以看到我们在"音频主题"中添加的"显示"语句。 调试输出如循环运行计数等

请求、

我将需要咨询我们的蓝牙固件专家以获取日志信息。

我会在我们找到任何内容后立即回复。

谢谢、Kobi。

正在等待您的团队的响应。

此处附加了有关我们找到的内容和我们现在用于从挂起状态中恢复的机制的更多信息。

根据我们的测试、这个逻辑似乎起作用、但我们不清楚发生这种情况的原因以及解决方法。

我们使用的逻辑如下

就在该问题被触发之前、我们观察到 SCO 数据包的模式为 GBGBGBGBGBGBGBGBGB。 有时、GBGBGBGBGBBGBGBGBGBG...、(其中 G 表示 Goodpacket、B 表示 SCO 在 HCI 中的 BadPacket)。

但这种模式有时似乎经常触发、即使问题没有发生也是如此。

因此、我们找到了另一个检查点来检测条件。

我们观察到堆栈正在快速减少、因此我们也在考虑进行复位。

下面添加了用于问题检测的伪代码

void PseudoCode_IssueDetection(){
	
	BTPS_MemoryStatistics_t MemoryStatistics;
	BTPS_QueryMemoryUsage(&MemoryStatistics, TRUE);
	
	if(GOODPACKET){
		ContinuousBadPacket =0;
		if(PrevWasGoodPacket == TRUE){
			DetectHangStatePattern = 0;
		}
		PrevWasGoodPacket = TRUE;
		ContinuousGoodPacket++;
		if(DetectBadStateMemoryUsedinitially > (int32_t)MemoryStatistics.CurrentHeapUsed ){
			DetectBadStateMemoryUsedinitially = (int32_t)MemoryStatistics.CurrentHeapUsed;
		}		
	}else{ // BADPACKET
		ContinuousBadPacket++;
		DetectHangStatePattern++;
		if((DetectHangStatePattern - ContinuousBadPacket) > 4){
			if(((int32_t)MemoryStatistics.CurrentHeapUsed - DetectBadStateMemoryUsedinitially ) > 2000){
				 Display(("ISSUE_DETECTED\n"));
				 AudioQualityReconnectionManage();
			}
			DetectHangStatePattern =0;
		}
	} 
}

*** DetectBadStateMemoryUsedinitly 是在 HFP 启动并初始化 mSBC 编码器之后最初使用的 Stack。

就我们的应用而言、当 SCO 处于运行状态时、我们不会从 Bluetopia 堆栈分配任何巨大的资源、因此我们在这里利用了这种优势。

在 AudioQualityReconnectionManage ()函数中，我们 使用 HCI_Disconnect (BluetoothStackID、SCOConnectionHandle、HCI_ERROR_CODE_OTHER_END_ENTERMINED_CONNECTION_USER_ENDED ，0)；

然后我们 使用 HFRE_Setup_Audio_Connection ()重新启动 SCO 连接;

这会给用户带来不良的体验、因为音频会持续约3秒、但仍然优于 Hang。

另一个观察结果是、如果器件是两个器件的主器件、则问题再现性率非常低。

谢谢。

这是很棒的,你找到了某种补丁.

在此处寻求帮助的同时、请注意、不是很多客户(如果有)使用了 SCO、而不是 HCI、我们对此方面的经验很少、因此我们目前主要依靠您的测试。

谢谢 Kobi!