工具与软件：
我发现长时间运行 CC2340可能会导致崩溃。 我打开 Debug 模式来观察并发现系统堆栈溢出、但 CC2340仍正常运行。 如果出现系统堆栈溢出、CC2340不会立即进入函数(例如 faultISR)、这是否正常？ 或者、如何使 CC2340在发生系统堆栈溢出时进入 faultISR？ 我尝试将系统堆栈大小调整为1200、默认值为800、然后使用 ROV 观察同样的大小。 我发现、当我尝试连接时、堆栈峰值约为804、而当我使用 Notify 时、堆栈峰值达到936。
尊敬的 Cl é ment：
感谢您的答复。 我已经将系统堆栈增加到2048、但经过几天的测试、我发现 CC2340仍然崩溃。 我在10天内测试了50个 CC2340s、3个 CC2340s 崩溃。
1.我想问一下 CC2340是否可以调用蓝牙功能来断开连接。 或者、在连接 CC2340并发出通知时、如果连接突然断开或发生其他中断、是否会导致崩溃？
我想知道是否不建议在蓝牙框架中直接调用该函数、即使它可以在示例项目中的 app_peripheral.c 的 BLEAPPUTIL_ADV_START 情况下成功运行、如所附图片中所示、仍需要 BLEAppUtil_invokeFunctionNoData。 
尊敬的 Cl é ment：
感谢您的回答、我将进行更详细的测试。
我还有一个问题。 在测试过程中、我发现、如果在使用蓝牙通知的情况下使用 UART2_WRITE 传输数据、CC2340将在两小时内崩溃。 如随附的图片所示、当我从情况更改为非阻塞时、UART2_writemode 似乎得到了改善。 我想问为什么？ 
尊敬的 Cl é ment：
我似乎已经发现了它卡在循环中的原因。 在今天的测试之后,我写了很多数据,并在蓝牙连接后启用了 Notify,然后突然失去了连接,这导致 SimpleGattProfile_SetParameter() App_Process 中的 GATT387CFG返回0x16。 即、该引脚当前处于挂起状态、然后进入循环。
1.我测试的 SDK 版本7.40和8.40都有这个问题。 但我检查了你提供的修复记录。 在 EXT_EP-11778和 EXT_EP-11752中、是否存在与我当前的情况类似的任何问题？ 情况与这两个主题不同？
2.最初的 SDK 增加了 while (1)、我想这是为了方便用户调试、所以如果移除它会影响蓝牙任务吗？ 或者、如果未使用 while (1)、是否有更好的解决方案？ 例如、如果响应不成功、请 App_Process 再次执行 GATT307Cfg。 
