最新的CC2652R Zstack 1.6 debug模式下阻塞在ICall_createRemoteTasks是什么原因？

您是否打开了FEATURE_MAC_SECURITY这个预编译？我又试了一下没有问题。

我刚才试了一个zed_switch没有出现，您的板子是否为CC2652R的launchpad，是否可以排查一下硬件，或者您对demo做了哪些更改。

我这边没有用官方的板子，是第三方的板子，更换的CC2652R芯片，可以正常使用，读取IEEE地址，都正常，说明板子没有问题。

debug也能debug，能进入main入口，不是说一点都运行不了，问题就是运行到ICall_createRemoteTasks就卡住了，详细调试之后发现具体是卡在了Task_restore这个函数的位置，没有源代码，不知道什么问题造成的。

帮忙debug一下，看看keytask变量在Task_disable函数调用之后的返回值是多少，是不是0，因为后面卡在Task_restore，我怀疑是这一块代码实现有问题。

/* See header file for comments */
void ICall_createRemoteTasks(void)
{
  size_t i;
  UInt keytask;

  /* Cheap locking mechanism to lock tasks
   * which may attempt to access the service call dispatcher
   * till all services are registered.
   */
  keytask = Task_disable();

  for (i = 0; i < ICALL_REMOTE_THREAD_COUNT; i++)
  {
    Task_Params params;
    Task_Handle task;
    ICall_CSState key;

    Task_Params_init(&params);
    params.priority = ICall_threadPriorities[i];
    params.stackSize = ICall_threadStackSizes[i];
    params.arg0 = (UArg) icall_threadEntries[i];
    params.arg1 = (UArg) ICall_getInitParams(i);

    task = Task_create(ICall_taskEntry, &params, NULL);
    if (task == NULL)
    {
      /* abort */
      ICALL_HOOK_ABORT_FUNC();
    }
    key = ICall_enterCSImpl();
    if (ICall_newTask(task) == NULL)
    {
      /* abort */
      ICALL_HOOK_ABORT_FUNC();
    }
    ICall_leaveCSImpl(key);
  }

  Task_restore(keytask);
}

另外，点击以下小锤子编译，没有一分钟都编译不完，有这么慢吗，又不是全部编译

如果不去debug直接烧录可以正常运行？

keytask = Task_disable();这个返回是0 ，因为之前没有Task的建立，最后Task_restore去恢复的标号也是0。

这应该不是程序问题，因为我一直在玩这个板子很长时间没有遇见过这种问题。

至于编译时间确实有点长的，主要不是那个编译时间长，是link出二进制的文件link工具执行占用时间较长。

我这边debug下来，keytask变量也是0，但是仍然卡在了最后一步Task_restore，换了两台电脑，都是如此，点击了CCS7.4关于里面的update，升级到最新的编译器等，重新导入工程，测试仍然是这个问题。

下面是我的一些截图，不知道编译器版本，CCS有没有问题，都是默认安装在C:\ti目录下，win7，win10两台电脑都测试了，都是这个问题

我尝试在里面点亮一颗LED，直接烧录hex文件也无法启动，我不认为是硬件问题，既然IEEE地址都可以读取，并且uniflash load image都没问题，说明硬件是可以正常的，不然别的地方都不卡住，就卡在这个地方，而且最主要的是还没有源代码，不清楚这里面到底干了什么事情。

见过那种硬件有问题的，JTEG都连不上。

如果硬件有问题，比如晶振无法启震，芯片引脚短路等等，JTEG都会连不上，更别说erase flash，读取IEEE地址，读取MEMORY都正常。

关键是debug时候还能进入main入口，并且一步一步运行到ICall_createRemoteTasks并卡死，中途查看其他变量，看起来初始化都还算正常。

以前的OSAL也会在启动的时候卡住在Mac_Init初始化的位置，后来跟踪进去发现是使用了外部32.768Khz晶振，没有起震，导致卡住，现在这个TI-RTOS不一样，中间多了一层叫做Icall的middleware中间件，很多都密封进库里面，也看不到，也无法调试，更是无从知道问题出在哪里了。

我很怀疑编译出来的firmware有问题，附件我上传了一个默认的条件编译出来的zed_switch_cc26x2lp.hex和zed_switch_cc26x2lp.out，以及stack映射文件zed_switch_cc26x2lp.map。

另外你那边能否帮忙编译个.hex，点亮RED(当前默认是GIO6引脚)这颗LED，我过来烧写进去看看能否点亮？

/*******************************************************************************
 * @fn          zclSampleSw_initialization
 *
 * @brief       Initialize the application
 *
 * @param       none
 *
 * @return      none
 */
static void zclSampleSw_initialization(void)
{

    /* Initialize user clocks */
    zclSampleSw_initializeClocks();

    /* Initialize keys */
    Board_Key_initialize(zclSampleSw_changeKeyCallback);

    /* Initialize the LEDS */
    Board_Led_initialize();

    // Register the current thread as an ICall dispatcher application
    // so that the application can send and receive messages.
    ICall_registerApp(&zclSampleSw_Entity, &sem);


    //Initialize stack
    zclSampleSw_Init();
	
Board_Led_control(board_led_type_LED1,board_led_state_ON);
}

zed_switch_cc26x2lp default build output.rar

我烧写你那个hex文件 led不亮的。

我自己加了那段代码：

static void zclSampleSw_initialization(void)
{

    /* Initialize user clocks */
    zclSampleSw_initializeClocks();

    /* Initialize keys */
    Board_Key_initialize(zclSampleSw_changeKeyCallback);

    /* Initialize the LEDS */
    Board_Led_initialize();

    // Register the current thread as an ICall dispatcher application
    // so that the application can send and receive messages.
    ICall_registerApp(&zclSampleSw_Entity, &sem);
    Board_Led_control(board_led_type_LED1, board_led_state_ON);

    //Initialize stack
    zclSampleSw_Init();
}

你烧写一下我的那个hex文件是可以点亮的。zc_switch_cc26x2lp.7z

你给我的firmware，你那能点亮。

我这里点不亮红色的LED，看来就是硬件问题了，我回头尽快查硬件问题。

另外因为现在CC2652R还没正式量产，还是XCC2652R1F，不知你那边是具体什么版本，会不会是版本差异。

我这边uniflash读取出来版本是1.1

有没有可能是CC2652R本身的硬件版本问题，现在还没release，我的是1.1版本：

重新更换了一个新的CC2652R，你给的固件烧进去，连接在GPIO6上的红色LED终于点亮了。

没有买TI的LaunchPad开发板(开发板上带了一堆没用的东西，还卖的较贵)，其实没必要为SmartEnergy和LaunchPad上带的下载器重复花钱，都有外接下载器，还要每个LaunchPad上自带一个，完全没必要，只能提高成本。

现在世面上任何一家CC2650的模块，只要把芯片换成CC2652R，另外换掉原来的24M晶振，换成48M的，就直接可以点亮了，RGZ封装的引脚都是完全兼容的，目前debug模式下XDS100 V3的确会有问题，会卡在ICall_createRemoteTasks不能往下走，目前手头没有XDS200的下载器，没办法做进一步的测试。

另外不知是CCS7.4，还是TI的编译器，似乎是有bug的，有时候稍微修改几行代码，Build project出来的hex烧进去运行不了，回头重新执行Rebuild project，等了很久，出来的hex固件烧进去反而运行正常。不是很可靠，理论上修改代码不会影响到project的配置，不应该出现这种情况，之前IAR for ARM/8051从来没遇到过类似问题。

然后我这边重新编译新的固件，都能点亮LED，blink也都正常，说明RTOS最起码跑起来了，刚刚测试了一下zed_switch看能不能入网，修改了CC26X2R1_LAUNCHXL.c里面gpioPinConfigs的引脚配置，可以支持当前平台的按键了，

虽然按键已经调用steering，但似乎没办法发出beacon request请求入网。很奇怪，就算network key不对，最起码能发出beacon request才对，但是ubiqua在默认的11信道抓包没有。

            zstack_bdbStartCommissioningReq.commissioning_mode = BDB_COMMISSIONING_MODE_NWK_STEERING/* | BDB_COMMISSIONING_MODE_FINDING_BINDING*/;
            Zstackapi_bdbStartCommissioningReq(zclSampleSw_Entity,&zstack_bdbStartCommissioningReq);

目前simplelink_zigbee_sdk_plugin_1_60_00_14.exe的确默认是11信道，还不清楚是哪里问题。

/* Default channel is Channel 11 - 0x0B               */
// Channels are defined in the following:
//         0      : 868 MHz     0x00000001
//         1 - 10 : 915 MHz     0x000007FE
//        11 - 26 : 2.4 GHz     0x07FFF800
//
//#define MAX_CHANNELS_868MHZ     0x00000001
//#define MAX_CHANNELS_915MHZ     0x000007FE
//#define MAX_CHANNELS_24GHZ      0x07FFF800
//#define DEFAULT_CHANLIST 0x04000000  // 26 - 0x1A
//#define DEFAULT_CHANLIST 0x02000000  // 25 - 0x19
//#define DEFAULT_CHANLIST 0x01000000  // 24 - 0x18
//#define DEFAULT_CHANLIST 0x00800000  // 23 - 0x17
//#define DEFAULT_CHANLIST 0x00400000  // 22 - 0x16
//#define DEFAULT_CHANLIST 0x00200000  // 21 - 0x15
//#define DEFAULT_CHANLIST 0x00100000  // 20 - 0x14
//#define DEFAULT_CHANLIST 0x00080000  // 19 - 0x13
//#define DEFAULT_CHANLIST 0x00040000  // 18 - 0x12
//#define DEFAULT_CHANLIST 0x00020000  // 17 - 0x11
//#define DEFAULT_CHANLIST 0x00010000  // 16 - 0x10
//#define DEFAULT_CHANLIST 0x00008000  // 15 - 0x0F
//#define DEFAULT_CHANLIST 0x00004000  // 14 - 0x0E
//#define DEFAULT_CHANLIST 0x00002000  // 13 - 0x0D
//#define DEFAULT_CHANLIST 0x00001000  // 12 - 0x0C
#define DEFAULT_CHANLIST 0x00000800  // 11 - 0x0B

为了方便您的测试，我把建立网络写在了初始化中。

 zstack_bdbStartCommissioningReq_t zstack_bdbStartCommissioningReq;

    zstack_bdbStartCommissioningReq.commissioning_mode = BDB_COMMISSIONING_MODE_NWK_FORMATION | BDB_COMMISSIONING_MODE_NWK_STEERING;
    Zstackapi_bdbStartCommissioningReq(zclSampleSw_Entity,&zstack_bdbStartCommissioningReq);



  UI_UpdateLcd();

附件中为固件，您下载之前请All Unprotected Sectors。8877.zc_switch_cc26x2lp.7z

这是新版的ubiqua吗？咋破解的？