[参考译文] CC2650：器件在运行几天后进入挂起状态、并需要硬复位才能继续

尊敬的  Dnyaneshvar Salve：

当您尝试连接调试器时、是否也连接了 GND？
可以将所有 JTAG 信号以及 RST 和3V3/GND (由外部电源而不是电池供电)连接在一起。

此外、您可以检查电池的状态吗？

器件运行与以下各项之间有何差异：

1. 出厂测试
2. 现场测试

您能否在工厂中模拟现场条件？

"不工作"是什么意思？ 是否有任何 LED 指示灯？

谢谢！
Toby

感谢您的参与。

我认为主要的区别可能是实际的显示图像本身--在现场它将是一个与工厂不同的图像。
您是否可以尝试在退回的设备上运行测试、在那里加载现场使用的实际图像？

由于器件在复位后可以正常工作、您可以向其添加看门狗吗？

尊敬的 Toby Pan：

感谢您回复、

显示图像不能是原因。

图像被转换为字节数组、字节数组通过通信 le 发送。 假设 image 为 any、Android 会将映像转换为字节数组。

假设系统中有7.5英寸的电子纸显示屏。

重新放大800 X 480 (高度 X 宽度)。 我得到(800*480*2)/8 (字节)= 96000字节(在 CC2650一侧翻转)。

字节数组的大小始终与任何图像不匹配。 我们将在过去两年中对此进行测试。

我测试的器件没有被客户使用。 因此没有图像被推送到器件。

我已经在器件中实现了看门狗、每次进行测试时它都会工作。

我已在 CCS 中打开运行时对象视图。

后来知道、任务 SimpleBLEPeripheral_taskFxn 使用的堆栈峰值数为620、堆栈大小为640。 (附加了图像)

这是可能的原因吗？

问题对我们的产品来说是个大问题。 我们已接受客户的订单。

我们愿意为这一问题的专门支持支付费用。

请告知我们是否提供任何此类服务。

谢谢！

Dnyaneshvar Salve

是的、如果堆栈峰值非常接近堆栈大小、则是一个问题。 可能存在未定义的行为、这将通过重置来解决、因此这与原始症状匹配。

是否剩余足够的 RAM 将堆栈大小增加到1000？

这是一个 BLE 基本示例、因此我将邀请 BLE 专家进行讲解。

尊敬的 Toby Pan：

是的、足够的 RAM 可用。 我已将任务堆栈大小设置为1024。

但我已经在 code.it 中实现了看门狗、只要经过测试就能正常运行。

 whatchdog 不会重置 MCU 的原因是什么、即使在12天的长时间后有堆栈溢出。

谢谢！

Dnyaneshvar Salve

您好 、Dnyaneshvar、

可能是电路板问题导致了该行为。 您是否在 SIMPLELINK-2-4GHz-design-reviews 中审查过您的设计？ 您能指定受影响设备的百分比吗？ 已部署了多少台设备、报告了多少台设备出现此问题？

此致、

1月

您好 Jan：

感谢您回复、

我们的 PCB 设计人员已采用所需的预防措施并遵循 PCB 设计指南。

但在 SIMPLELINK-2-4GHz-design-reviews 中未审查这些设计。

部署的器件数量为150个

受影响的器件数量- 16个

受影响的器件百分比- 24%

谢谢！

Dnyaneshvar Salve

您好！

明白了。 感谢您的讲解。 我强烈建议提交设计审查申请。 我们的硬件团队会尽快研究一下、看看他们是否对设计有任何担忧。 关于可能的原因、如果不能轻松地重现这种情况、则说起来有点困难。 您能否描述发生行为的环境和测试器件的环境？ 它们的温度和湿度范围是否相似？

此致、

1月

您好 Jan：

我们的硬件团队将很快提交设计。

我们的设备部署在受控的环境中、位置是购物中心内的商店、以及向客户提供产品演示的高级空调办公室。

是的、它们具有相似的温度和湿度范围。

谢谢！

Dnyaneshvar Salve

尊敬的 Dnyaneshvar：

我懂了。 感谢您提供的详细信息请确保在设计审查的过程中提供此 E2E 主题、以便硬件团队在其硬件分析期间考虑该问题、以防发现潜在的硬件原因。

数据传输逻辑是否可能存在问题？ 如果该行为发生在客户站点(使用许多 BLE 器件)、则可能会发生无线数据包冲突、导致发送的数据不完整。 您的数据传输/接收逻辑是否说明数据不完整？

此致、

1月

您好 Jan：

是的、我们的硬件团队 Tejash Kumar 将提到这个 e2e 文章链接。

数据接收逻辑负责处理不完整的数据。

我们在代码中实现了数据完整性检查功能。

当器件接收到数据包(1个数据包= 200字节)时、会使用5秒的周期时钟来检查数据包是否可靠、完整。

如果存在部分数据、我们的代码会丢弃该数据。

我们已进行了多次测试、在发送数据的同时发送部分数据并关闭 Android 设备上的蓝牙。

谢谢！

Dnyaneshvar Salve

尊敬的 Dnyaneshvar：

明白了。 感谢您的确认。 在这种情况下、另一种可能的原因可能是运行时栈溢出或堆用尽。 我知道您曾提到您已经增加了堆栈大小、但我认为如果一个器件可以刷写新映像并放置在导致另一个器件出现此问题的确切条件下、可能是值得的。 我知道这可能很难做到、但这是否可以做到？

此致、

1月

您好 Jan：

我们的代码中没有使用动态内存分配。 (malloc、calloc、realloc、free)。

因此、除非 SDK 示例代码中存在错误、否则一定不会出现堆存储器耗尽的情况。 (如果有的话、请告知我)

我们在 UART 终端上打印了剩余的堆内存、大约为500字节。 因此、我认为堆内存不是问题。

是的、堆栈使用量接近分配的堆栈大小、有可能发生堆栈溢出、但看门狗是否不会复位 MCU？

我用看门狗模拟了很多可能的用例、它每次都可以正常工作。

谢谢！

Dnyaneshvar Salve  

/*System Reset Feature Function*/
void check_ble_packet_integity_and_EPD_sleep() {
    //check for ble rx error only when device is receiving image
    //if (image_receiving_status == 1) {
    	if ((conn_status == 1) ||(image_receiving_status == 1)){//this will do system reset if device ble is connected for more than 25 sec or if there is only partial image data is received
        current_image_packet_cnt = round_number;
        if (prev_image_packet_cnt == current_image_packet_cnt) { //if prev and current data packet count is same means no new data is being received then prepare for system reset
            skip_system_reset_cnt += 1; 						 //LET SYSTEM WAIT FOR BLE CONNECTION RECOVERY BY ALLOWING IT SOME TIME BY SKIPPING RESET
            //print_uart_str("\nskip_system_reset_cnt -> ");
            //print_uart_variable(skip_system_reset_cnt);
            if (skip_system_reset_cnt >= SYSTEM_RESET_SKIP_COUNT) {	//SYSTEM_RESET_SKIP_COUNT is 5 and periodic clock is 5 seconds, so 5*5 = 25 seconds
                system_reset = 1;
                //print_uart_str("\nsystem_reset_success");
                HAL_SYSTEM_RESET();
            }
        } else {
            prev_image_packet_cnt = current_image_packet_cnt;	//if there is new ble data packet, copy current_image_packet_cnt into prev_image_packet_cnt
            skip_system_reset_cnt = 0;
//          Device_Uptime_Status_Cnt = 0;
        }
    }
    //check if image is receiving and char2 is read by BLE central to read battery voltage and epd status
    //this is required if device status is called but no image byte array is sent
    //so calling epd_sleep is important
    else if ((image_receiving_status == 0) && (Char2_Read_Status == 1)) {
        EPD_Sleep(EPD_BUSY_PIN, EPD_DC_PIN, EPD_SCK_PIN,
        EPD_MOSI_PIN, EPD_CS_PIN);
        EPD_Sleep(EPD_BUSY_PIN_2, EPD_DC_PIN, EPD_SCK_PIN,
        EPD_MOSI_PIN, EPD_CS_PIN_2);
        //print_uart_str("\nEPD Sleep Done\n");
        Char2_Read_Status = 0;    //reset the flag
    }
}

如果连接 ble 的时间超过25秒并且也没有接收到进一步传入的 ble 数据包或部分 ble 数据包、则此函数用于重置 MCU。

我们有一个 HAL_SYSTEM_RESET()函数。

我已经验证  HAL_SYSTEM_RESET()是硬复位、因此也没有问题。

此外、在初始化代码中 、我们注意将热复位转换为引脚复位、

//将 WARM_RESET 转换为 PIN_Reset (System_Reset)
HWREG (PRCM_BASE + PRCM_O_WARMRESET)= 4；

(技术参考手册 首选  6.8.2.4.37)

我知道这可能很难做到、但这是否可以做到？ 是的、当然可以。

但我们必须找出根本原因,否则这个问题将更难通过从 upcomng 批处理大量的设备来回击我们。

谢谢！

Dnyaneshvar Salve

您好！

是的、堆栈峰值使用量接近分配的堆栈大小、并且有可能出现堆栈溢出、但是看门狗是否不会复位 MCU？

如果看门狗由于这一原因无法恢复、我会感到非常惊讶、但由于我们无法轻松地重现问题、我认为我们应该尝试考虑任何可能的原因、以增加我们能够在向现场产品发送新固件时解决问题的机会。

但是我们必须找出根本原因、否则这个问题将通过 upcomng 批处理中的大量设备更难解决。

同意。 我认为、在确认行为发生的位置重新测试可能会给我们带来一些提示。

此致、

1月