[参考译文] CC3120：IOS 客户端导致 SL_ERROR_BSD_ESECCLOSED 错误升高

尊敬的 Lorenzo：

几点意见：

• "模块卡住"是什么意思？ 模块未响应 sl_ API 调用？ 您是否通过异步处理程序看到任何错误？
• Service Pack 3.10.0.5已超过4年。 您是否能够使用最新的服务包进行测试？ 您可以在CC32xx SDK (版本3.22.0.1)中找到适用于 CC3120的最新服务包。
• 当从 sl_Recv ()返回错误-452时,您在做什么? 您是否通过 sl_close()关闭了套接字？ 是否针对套接字使用 LINGER 选项(SL_SO_LINGER)？

1月

大家好、Jan、

在我的答案下面：

• 我过于简单地总结了。 模块未卡住。 这是主机处理器中的软件驱动程序、在 sl_Recv 返回-542后、调用 sl_Close、然后退出程序。
• 我已经安装了 SDK。 但是、当我尝试通过 UART 连接通过引导加载程序对 sp_3.22.0.1_2.7.0.0_2.2.0.7.ucf 进行编程时、我得到：

更新 CC3120固件
文件/usr/share/cc3120-fw/cc3120.ucf.new 已打开。 大小：74852字节
开始编程
错误：编程时出错、statusCode：-673378496 = 0xd7dd0f40、read_buffer[0]= 0x00、read_buffer[1]= 0xcc

当发送第一个文件块时。 相同的更新程序适用于主机处理器中软件更新程序下的旧.ucf。

static bool flashProgrammingCmd(const uint8_t* bin, size_t size)
{
   uint8_t read_buffer[READ_BUFFER_SIZE] = {0};
   uint16_t readBytes = 0;

   const uint8_t* addrOffset = bin;

   size_t imageSize = size;
   size_t writtenBytes = 0;

   printf("Start Programming\n");

   while (size > 0)
   {
      size_t toReadBytes =
          MIN(size,
              MAX_CHUNK_SIZE); // Chunk size must be 4096 B except for the last chunk

      uint16_t cmdLen = toReadBytes + PARTIAL_HEADER_CMD_LEN;              // Len field of command
      uint8_t flashProgram_cmd[MAX_CHUNK_SIZE + TOT_HEADER_CMD_LEN] = {0}; // max: 4107

      memcpy((flashProgram_cmd + CMD_CHUNK_START_INDEX), addrOffset, toReadBytes);

      flashProgram_cmd[CMD_LEN_INDEX] = cmdLen >> 8;
      flashProgram_cmd[CMD_LEN_INDEX + 1] = cmdLen;

      flashProgram_cmd[CMD_OPCODE_INDEX] = PROGRAM_CMD_OPCODE;

      flashProgram_cmd[CMD_CHUNK_SIZE_INDEX] = toReadBytes >> 8;
      flashProgram_cmd[CMD_CHUNK_SIZE_INDEX + 1] = toReadBytes;

      uint8_t checkSum = computeCheckSum((flashProgram_cmd + CMD_OPCODE_INDEX), (toReadBytes + 9));
      flashProgram_cmd[CMD_CS_INDEX] = checkSum;

      serialWrite((unsigned char*)flashProgram_cmd, (toReadBytes + TOT_HEADER_CMD_LEN));
      while (readBytes == 0)
      {
         readBytes = serialRead(read_buffer, PROGRAM_CMD_ASW_LEN);
      }
      readBytes = 0;

      int32_t statusCode;
      statusCode =
          read_buffer[2] << 24 | read_buffer[3] << 16 | read_buffer[4] << 8 | read_buffer[5];

      if ((statusCode < 0) || (read_buffer[0] != 0x00) || (read_buffer[1] != 0xCC))
      {
         //fprintf(stderr, "Error: Error occurred while programming\n");
e
         return 1;
      }

      size -= toReadBytes;
      addrOffset += toReadBytes;
      writtenBytes += toReadBytes;

      int progress = (int)(((float)writtenBytes / imageSize) * 100);
      printf("\rProgress: %d %% \t", progress);

#ifdef SERIAL_DEBUG
      printf(" - Written bytes: %d (%02x)\n", statusCode, statusCode);
#endif

      fflush(stdout);
   }

   int32_t statusCode;
   statusCode = read_buffer[2] << 24 | read_buffer[3] << 16 | read_buffer[4] << 8 | read_buffer[5];

   if (statusCode == 0)
   {
      fprintf(stderr, "\nFinished programming\n");
   }
   else
   {
      return 1;
   }

   return 0;
}

• 我调用 sl_Close。 是的、tcpServerSocket 是用 SL_SO_LINGER 设置的

洛伦佐

您好 Shlomi：

最后、我能够刷写新的服务包。 问题是因为我使用旧的 Uniflash 版本(6.4而不是最新的8.3)制作.ucf 文件。

现在版本是：

NWP 3.2.0.1
Mac 2.7.0.0
PHY 2.2.0.7

总之、行为是相同的。

sl_Recv

_i16 sl_Recv(_i16 sd, void *pBuf, _i16 Len, _i16 flags)
{
    _SlRecvMsg_u   Msg;
    _SlCmdExt_t    CmdExt;
    _SlReturnVal_t status;

    /* verify that this api is allowed. if not allowed then
    ignore the API execution and return immediately with an error */
    VERIFY_API_ALLOWED(SL_OPCODE_SILO_SOCKET);

    _SlDrvResetCmdExt(&CmdExt);
    CmdExt.RxPayloadLen = Len;
    CmdExt.pRxPayload = (_u8 *)pBuf;

    Msg.Cmd.Sd = (_u8)sd;
    Msg.Cmd.StatusOrLen = (_u16)Len;

    /*  no size truncation in recv path */
    CmdExt.RxPayloadLen = (_i16)Msg.Cmd.StatusOrLen;

    Msg.Cmd.FamilyAndFlags = (_u8)(flags & 0x0F);

    status = _SlDrvDataReadOp((_SlSd_t)sd, (_SlCmdCtrl_t *)&_SlRecvCmdCtrl, &Msg, &CmdExt);
    if( status != SL_OS_RET_CODE_OK )
    {
        return status;
    }
     
    /*  if the Device side sends less than expected it is not the Driver's role */
    /*  the returned value could be smaller than the requested size */
    syslog(LOG_INFO, "[INFO] -  sl_Recv, line:%d, Msg.Rsp.StatusOrLen:%d,\n", __LINE__, Msg.Rsp.StatusOrLen);
    return (_i16)Msg.Rsp.StatusOrLen;
}

返回-452。

WIFI_BRIDGE_LOG[5815]：[INFOC]- sl_Recv、line：912、Msg.Rsp.StatusOrLen：-452、

这是在与 iOS 设备进行了几分钟的数据交换后发生的;可能也会发生一次从 Windows PC。
我可以获取哪些资源来帮助调查吗？

谢谢。

Lorenzo。

您好！

接下来的步骤是尝试从 NWP 获取一些日志、但在此步骤之前、您可以评论"当您关闭套接字芯片以出错并重新打开它、以便对等器件可以重新连接时、它是否会再次开始工作？"

什洛米

尊敬的 Shlomi：

我花了几天时间做一些测试和研究当前代码。

似乎避免在 sl_Recv 失败时关闭套接字可以防止出现以下问题：客户端保持连接并且数据交换继续。 您是否知道 sl_Recv 何时返回-452 (SL_ERROR_BSD_ESECCLOSED)？

Br

洛伦佐

尊敬的 Lorenzo：

这是很好的听到,不关闭插槽,你能够恢复,但这是有点奇怪.

SL_ERROR_BSD_ESECCLOSED 表示另一侧关闭 SSL/TLS 连接、但不关闭套接字本身。 您在这里要介绍的是它会继续交换数据、因此数据交换是在非安全套接字上进行的、或者 TLS 握手在 NWP 中触发 、因此您看不到。

此致、

什洛米

尊敬的 Shlomi：

我想我可能已经弄清楚发生了什么。

客户端似乎有时试图建立6个以上的连接。 像往常一样、当发生这种情况时 、客户端会发起 TLS 握手、而此握手确实以  客户端发送的过早加密警报结束。 当 SL_RECEIVE 返回 SL_ERROR_BSD_ESECCLOSED  (-452L)时就会出现这种情况。

我现已修改主机处理器代码、以关闭返回 SL_ERROR_BSD_ESECCLOSED 的客户端 套接字；主服务器套接字从未关闭、因为服务器一直希望能够接受新连接。

客户端通常关闭其他客户端套接字后、 模块上的其他安全套接字将再次可用、并且正确接受新的客户端套接字。

通常的行为似乎是可以的、并且没有使用不安全的套接字。

您是否 认为分析正确、或者还需要调查其他问题？

提前感谢。

Br

洛伦佐