This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] CC3235MODSF:sl_FS 行为问题

Guru**** 657500 points
Other Parts Discussed in Thread: UNIFLASH, SYSCONFIG
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1243428/cc3235modsf-sl_fs-behavior-question

器件型号:CC3235MODSF
主题中讨论的其他器件:UNIFLASHSysConfig

您好!

我们正在最终完成基于 CC3235的产品的配置。 我在将安全证书写入 NWP 闪存时看到一些异常行为。 先介绍一些背景信息。 共有七个证书文件、大小从1554字节到2090字节不等。 每个文件都以块的形式从 STM32主处理器发送到 CC3235。 我们的应用程序代码会重新汇编每个文件、在每个文件完成后、会将其创建并写入 NWP 闪存。 基本来说、STM32 -> CC3235 app -> CC3235 NWP。 STM32在两个文件之间等待3秒、以便为 CC3235提供处理文件的时间。 足够简单。  

但是、当我在传输文件后检查这些文件时、每个文件的长度正好是2048字节。 超过2048的时间将被截断。 这些较短的数据是完整的,但来自先前较长的文件的数据将填充--- 结束证书----- 写入偏移量2048。 我知道额外的数据不是来自应用、因为文件建立的缓冲区在每次使用前都会被清除。

现在、真正奇怪的是、如果我在每个文件关闭后设置一个断点、文件将被正确写入! 最初我认为这可能是因为每次命中断点后检查数据所引起的延迟。 但是、我在每次文件传输和写入之间添加了1分钟的延迟、问题仍然存在。 我将在下面添加文件编写应用程序代码、代码相当简单。 sl_fs 中的一个文件几乎覆盖了另一个文件、然后又使其写入闪存、就好像有一个缓冲区已损坏。

感谢您的任何帮助!

此致、

约翰

/**
 * \details	This routine manages the FS Security Write
 * \note None
 * \param[in]	typ denotes the security file type
 * \param[out]	None
 * \return ret_val returns 0 on failure and non zero on success
 */
int32_t FS_SecurityWrite(fs_security_type_t typ)
{
  const char *filename              = FS_securityGetFileName(typ);
  fs_security_info_t * p_sec_info   = FS_SecurityGetBuffer(typ);
  int32_t offset                    = 0;
  int32_t f_hndl                    = 0;
  int32_t ret_val                   = 0;

  //Note: Make sure to initialize config file with MAX_SECURITY_INFO_SIZE zeroes, even if
  //      only using 20 bytes.
  //      Otherwise, attempting to read MAX_SECURITY_INFO_SIZE bytes from the file would
  //      fail.
  
  f_hndl = sl_FsOpen((const unsigned char *)filename,
                     (SL_FS_CREATE | SL_FS_OVERWRITE | SL_FS_CREATE_FAILSAFE | 
                      SL_FS_CREATE_MAX_SIZE(MAX_SECURITY_INFO_SIZE)),
                     0);
  
  WSIS_SendDebugPrint("Fs Write f_hndl: %d  size: %d  typ: %d  name: %s", f_hndl, MAX_SECURITY_INFO_SIZE, typ, filename);

  //Check if open was successful
  if(f_hndl < 0)
  {
    ret_val = f_hndl;
  }
  
  if(ret_val >= 0)
  {    
    ret_val = sl_FsWrite(f_hndl,offset, (uint8_t *)p_sec_info->cert, p_sec_info->size);
    WSIS_SendDebugPrint("Fs Write ret_val: %d", ret_val);
    if(ret_val > 0)
    {
      offset += ret_val;
    }
  }
  
  if(f_hndl >= 0)
  {
    // Make sure to close it if sl_FsOpen was successful
    sl_FsClose(f_hndl, NULL, NULL, 0);
  }
 
  return ret_val; //<----- Works correctly if I set a breakpoint here
}

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    如何  定义 MAX_SECURITY_INFO_SIZE?

    是否可以将其设置为 p_sec_info->size (或者如果该文件被覆盖,则添加一些空间)?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Kobi:

    以下是安全信息结构的相关定义和结构:

    #define MAX_SECURITY_CERT_SIZE          4096-sizeof(uint16_t) 
    
    typedef struct 
    {
      uint16_t      size;
      uint8_t       cert[MAX_SECURITY_CERT_SIZE];
    } fs_security_info_t;
    
    #define MAX_SECURITY_INFO_SIZE  MIN_BLOCK_SIZE(sizeof(fs_security_info_t), 1024)
    

     p_sec_info->大小因文件而异,始终小于4096。 我认为允许的最小文件大小是1 4096字节块。

    我不知道为什么它的原始写入器将 MAX_SECURITY_CERT_SIZE 设置为4096 - sizeof (uint16_t)。 我们不希望在这个文件中增加大小、只希望增加认证本身。

    约翰

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Kobi:

    还有另一个细节。 如果使用的是断点位置、则文件 write 始终返回证书中的字节数、如果是2090、我们得到了2090。 与其他文件大小相同。 当该操作失败时、我们始终从写入操作中恢复2048个字节。 此外、如果出现故障、证书数据前面会加上该证书结构中证书的大小。 我发现这非常有趣,无法知道它是如何发生的。

    约翰

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    什么是 MIN_BLOCK_SIZE (用于 MAX_SECURITY_INFO_SIZE )? -它是否返回以下之间的最小值 1024 和安全的尺寸?

    很难相信、如此 简单地使用 sl_FS API 会引发问题。 这是我们的客户多次执行的、因此我真的认为您应该检查应用程序(并 确保您使用的是更新的 SP)。

    您也可以改用以下函数(可以在 SDK 6.10的 MQTT_CLIENT 示例的 utils_if.c 中找到它)。

    nt FILE_write(char *pFilename, uint16_t length, uint8_t* pValue, uint32_t *pToken, uint32_t flags)
    {
        int32_t  lFileHandle;
        int   rc;
        uint32_t ulToken = 0;
        int32_t  OpenFlags = 0;
    
    
        /* Open the file as bundle !!!*/
        OpenFlags = (SL_FS_CREATE | SL_FS_OVERWRITE);
        OpenFlags |= (SL_FS_CREATE_SECURE | SL_FS_CREATE_NOSIGNATURE);
        OpenFlags |= flags;
    
        if(!pToken)
        {
            pToken = &ulToken;
            OpenFlags |= (SL_FS_CREATE_PUBLIC_WRITE | SL_FS_CREATE_PUBLIC_READ);
        }
    
        lFileHandle = sl_FsOpen((uint8_t *)pFilename,  OpenFlags| SL_FS_CREATE_MAX_SIZE( length ), (unsigned long *)pToken);
        if(lFileHandle < 0)
        {
            LOG_TRACE("FILE_write: Error sl_FsOpen %s, Status=%d", pFilename, lFileHandle);
            return (int16_t)lFileHandle;
        }
    
        rc = (int16_t)sl_FsWrite(lFileHandle , 0, (uint8_t *)pValue,length);
        if(rc < 0)
        {
            LOG_TRACE("FILE_write: Error sl_FsWrite, Status=%d", rc);
            return rc;
        }
    
        rc = sl_FsClose(lFileHandle, NULL, NULL, 0);
        if(rc < 0)
        {
            LOG_TRACE("FILE_write: Error sl_FsClose, Status=%d", rc);
            return rc;
        }
    
        return rc;
    }
    
           

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Kobi:

    很抱歉响应出现延迟。 我们很幸运能有周五、周一和周二的假期。 我还发现、很难相信我的简单用例会有问题。 我来看看您建议的示例。 同时回答您的问题:"MIN_BLOCK_SIZE  (用于 MAX_SECURITY_INFO_SIZE )是什么? -它是否返回以下之间的最小值  1024  大小是多少?" 答案如下。


    #define MAX_SECURITY_CERT_SIZE 4096-sizeof (uint16_t)

    typedef 结构
    {
    uint16_t 大小;
    uint8_t cert[MAX_SECURITY_CERT_SIZE];
    } FS_SECURITY_INFO_t;

    #define min_block_size (x、y)        (((x)+(y)-1)/(y))*(y))

    MIN_BLOCK_SIZE (sizeof (FS_SECURITY_INFO_t)、1024)

    因此、x 的大小应为4096、y 已硬编码为1024。 如果我正确地完成了数学运算、这将使用整数数学并截断余数、得到值4096。 不是很清楚为什么他们进行了所有的努力,但它是什么。

    此致、

    约翰

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    另一个问题是:是否可以查看我正在运行的 Service Pack 是什么?是否最好再次对其进行编程?

    谢谢。

    约翰

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    您可以忽略我关于获取服务包信息的问题。 我找到了 sl_DeviceGet API。 当我运行它时、结果是:

    这肯定是过时的。 我将尝试使用 Uniflash 对最新的6.10 SP 进行编程。

    此致、

    约翰

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

     min_block_size 的逻辑似乎正确、但请尝试在 sl_FsOpen 之前放置一个断点、以验证值是否符合预期。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    我确实设置了一个断点并检查了 mode/flags/size 的值。 他们显示的值为0x28020010、在对其进行分解后看起来是正确的。 应为 FS_OVERWRITE、FS_create 和 FS_failsafe、加上大小4096 (0x10 * 0x100)。

    约翰

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    反汇编操作会确认我在断点中看到的值:

    //  651   //Note: Make sure to initialize config file with MAX_SECURITY_INFO_SIZE zeroes, even if
    //  652   //      only using 20 bytes.
    //  653   //      Otherwise, attempting to read MAX_SECURITY_INFO_SIZE bytes from the file would
    //  654   //      fail.
    //  655   
    //  656   f_hndl = sl_FsOpen((const unsigned char *)filename,
    //  657                      (SL_FS_CREATE | SL_FS_OVERWRITE | SL_FS_CREATE_FAILSAFE | 
    //  658                       SL_FS_CREATE_MAX_SIZE(MAX_SECURITY_INFO_SIZE)),
    //  659                       NULL);
            MOVS     R2,#+0
            LDR.N    R1,??DataTable10_13  ;; 0x28020010
            MOV      R0,R10
            BL       sl_FsOpen
            MOV      R8,R0

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我尝试验证是否有最新的服务包。 我想我的确这么做了,但很难说。 原因是、在器件上、版本数据是上面的屏幕截图所示的。 SysConfig 在选择服务包时输出此信息:

    CommandNum = 2
    CommandWriteServicePack:
    服务包版本、NWP =(4、17、0、0) MAC =(3、1、0、5) PHY =(3、1、0、25)
    最大服务包文件大小= 131072
    文件定位= c:\ti/simplelink_cc32xx_sdk_6_10_00_05\source\ti\drivers\net\imagecreator\bin\..\ sp_4.13.0.2_3.7.0.1_3.1.0.26.bin
    FileSystemName =/sys/servicepack.ucf
    文件最大大小为131072字节、实际大小为81916字节
    运行解压后、器件将需要66个块

    因此、器件中的版本信息与 SysConfig 认为它捕获的版本信息不匹配、也与文件名中嵌入的版本信息不匹配。 我当然可以把.sli 重新烧坏了。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    请忽略  ImageCreator 日志中的服务包版本:NWP =(4、17、0、0) MAC =(3、1、0、5) PHY =(3、1、0、25)。

     此日志有一些问题(但实际写入的内容没有问题)。

     sl_DeviceGet 中的版本应正确。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    已了解、我在 sl_DeviceGet 响应中看到的版本是否是6.10版的最新版本?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    它从6.10开始-不是最新的(因为有7.10 ) ,但它应该是足够好的。

    您是否与我提供的代码进行了比较?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我一直在看着你发送的代码,我将在周末做更多的事情,因为我是在今天下午的截止时间去做其他的事情。 我将在星期一跟进。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    确定

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Kobi:

    很抱歉响应延迟、我的优先级发生了变化。 我几乎回到了我可以深入研究这个问题的地方。 我将您从示例中发送的代码与我们的代码进行了比较。 我注意到的最大区别是 sl_FsOpen 调用上设置的标志的增量。 尤其是我们将使用的失效防护标志。 希望很快我重新参与讨论时、我将围绕这进行一些实验、看看会发生什么情况。 此外、无论如何、我都需要为这些文件添加安全性、我们不想以确保安全的方式发货。

    约翰

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我认为您的问题仅与尺寸/长度有关。 安全性和失效防护是另一回事。

    因此、请尝试检查示例代码。 如果有效、则 将参数与代码进行比较。  

    安全和其他标志。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    只需触摸此按钮即可使其保持打开状态。 我们仍然无法返回到这里。 希望很快。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    好的。