[参考译文] 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 设置的

洛伦佐

您好、Lorenzo、

当您关闭套接字裸片并重新打开它以使对等器件可以重新连接时、它是否会再次开始工作？

由于您使用的是归档文件、因此 SP 确实是强制性的。 您通过引导加载程序描述的过程称为嵌入器编程、您需要通过在 UART 上引入中断信号来进入引导加载程序模式。 您是否实施了 swpa230中描述的内容？  您是否可以改用 Uniflash？

什洛米

您好 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

洛伦佐