关于sl_Start 卡死问题的解决方法

最近，要调试一个问题，写了一个简单的demo程序，发现程序启动卡在了sl_Start 上，在论坛一搜，发现许多人有这样的问题，但好像都没解决方案，有工程师说是GZ的芯片有问题，我的芯片是G4,也出现了这个问题，通过分析和排查，最终解决了这个问题。

首先说一下开发环境

开发板 CC3200 LAUNCHPAD 芯片结尾是G4 ，SDK 1.2.0  service pack 是 1.0.1.6-2.7.0.0，用的是free rtos ，大致开发环境就是这样，使用OS这是一个很关键的一个问题点，

如果是OS的话，貌似必须要要先启动 VStartSimpleLinkSpawnTask ，这个操作应该是初始化NWP的， 而且如果你要进行 sl_Start的操作必须要在Task中完成，为什么呢？ 经过打log分析，用osi_TaskCreate 创建的 task 都是在 osi_start 之后才真正开始 执行，之前的 osi_TaskCreate 应该是用来初始化一些环境， 推测VStartSimpleLinkSpawnTask  应该也是 在osi_start 之后才运行的， 而且这个任务的优先级一定要设置的最高。所以如果你在 VStartSimpleLinkSpawnTask 后直接执行sl_Start 应该是没效果的，应该还是会卡住，因为osi_start  没运行，VStartSimpleLinkSpawnTask  这个任务根本没起作用，所以必须要在Task中 完sl_start 的操作。 这个Task的优先级应该比VStartSimpleLinkSpawnTask 低 ，但是要比其他的任务要高。

如果发现设置了后,task 还是起不起来，那我就怀疑是资源不够的问题了， 我的任务是要建立一个wlan_sta, 分配的stack depth是 2048， 运行这个任务时，发现任务体根本就没执行起来，于是加大了运行时内存空间，主要是修改 dynmic memory这一项，我把这个值加到了0x4000, 任务才启动成功，0x1000都启动不了任务，不知道为什么需要这么大的运行空间，（所以这里也得出一个结论，初步推测Task运行的时所需要的资源主要都是heap size上分配的）

所以总结一下 如果出现了sl_start 卡住的问题，如果用到了 os， 首先检查 是否启动了VStartSimpleLinkSpawnTask   优先级是否最高， 使用sl_start的地方是否在task 里面，这个task是否比VStartSimpleLinkSpawnTask   的优先级要低， task分配的stack资源够不够， 系统运行时的heap size 够不够， 基本我就是这么解决的。

另外 还想问问TI的工程师 为什么启动task需要这么多的资源， 给一个task分配资源 至少应该是多少才不会导致任务失败？这个有什么标准或者算法可以计算么？

用RTOS操作的话，不仅仅有底层的问题还要上层任务分配的问题，肯定就比直接的底层那种操作的配置变多了。

这个分配资源具体多少才好，估计只有设计那个系统的人才能知道了。不知道手册里面有没有介绍这些东西。如果没有，或暂时找不到，只能自己慢慢摸索了。