zoukankan      html  css  js  c++  java
  • 痞子衡嵌入式:借助Serial Plot软件测量i.MXRT系列FlexSPI驱动Flash页编程执行时间分布


      大家好,我是痞子衡,是正经搞技术的痞子。今天痞子衡给大家介绍的是i.MXRT系列FlexSPI驱动Flash页编程执行时间

      痞子衡之前写过一篇文章 《串行NOR Flash的页编程模式对于量产效率的影响》,简要分析了 NOR Flash 的 Page Program 命令不同模式对于整体量产时间的影响,文章仅从理论计算角度做了分析,假定了 Flash 中所有 Page 擦写表现都是一致的,但是每个 Page 的表现真的是完全一致吗?今天我们从一个客户问题出发来探讨下这个话题:

    一、引入客户问题

      最近有一个 i.MXRT1170 客户反馈,他们的应用程序里 IAP 功能代码对于 Flash 擦写表现不稳定。他们的 IAP 代码就是移植的 SDK_2.10.0_MIMXRT1170-EVKoardsevkmimxrt1170driver_examplesflexspi orpolling_transfer 例程,Flash 选用得跟官方 EVK 上一样的型号 IS25WP128-JBLE,测试代码会把整个 Flash 的 16MB 循环擦除写入,反复进行测试,在测试过程中发现的部分区域表现速度较慢,这个慢的定义是在部分 256 字节(一个 Page)写入时,写入 API 返回时间较长(因为是轮询模式),但是返回状态是正确的。

      由于客户并没有进一步给出 Page 写入快慢时间分别是多少,痞子衡只能先盲猜。既然写入 API 返回状态是正确的,那说明 FlexSPI 驱动是能正常工作的,先排除板级硬件设计问题。那么只剩下两种可能:一、FlexSPI 软件驱动执行稳定性问题;二、Flash 本身 Page 表现一致性问题。这两个问题都可以通过观察统计全部 Page 的写入时间来进一步确认。对于第二个可能性,从 Flash 手册里我们可以得知 Page 写入命令的等待时间典型值是 0.2ms,最大值是 0.8ms,但这个表述并没有明确这是针对不同 Flash 芯片而言,还是针对同一 Flash 内不同 Page 而言。

    二、确定测量方案

      带着上述疑问,痞子衡决定在官方 MIMXRT1170-EVK 上实测一下,我们仅需简单改造一下 SDK_2.10.0_MIMXRT1170-EVKoardsevkmimxrt1170driver_examplesflexspi orpolling_transfer 例程,在 flexspi_nor_polling_transfer.c 源文件中 main() 函数里加入计时代码统计 flexspi_nor_flash_page_program() 函数执行时间即可,其中计时实现可用 https://github.com/JayHeng/microseconds 项目,具体用法参考 《通用微秒(microseconds)计时函数框架设计与实现》 一文。

    // 保存 65536 个 Page 的写入 API 执行时间
    uint16_t timeRes[65536];
    
    int main(void)
    {
        // 省略原 Flash 初始化、擦除代码
    
        microseconds_init();
    
    #if !(defined(XIP_EXTERNAL_FLASH))
        uint32_t startAddr = 0;
    #else
        uint32_t startAddr = 0x8000;
    #endif
        uint32_t endAddr = 0x1000000;
        while (startAddr < endAddr)
        {
            // 计时开始
            uint64_t startTicks = microseconds_get_ticks();
            uint64_t endTicks = startTicks;
            uint64_t deltaTicks = 0;
            status_t status = flexspi_nor_flash_page_program(FLEXSPI1, startAddr, (void *)s_nor_program_buffer);
            if (status == kStatus_Success)
            {
                // 计时结束
                endTicks = microseconds_get_ticks();
                deltaTicks = endTicks - startTicks;
                uint16_t costMicroseconds = microseconds_convert_to_microseconds(deltaTicks);
                timeRes[startAddr / 256] = costMicroseconds;
            }
            startAddr += 256;
        }
    
        for (uint32_t i = 0; i < sizeof(timeRes) /sizeof(uint16_t); i++)
        {
            PRINTF("%d
    ", timeRes[i]);
        }
        
        while (1)
        {
        }
    }
    

    三、选一款串口波形显示软件

      上一节代码中,我们把所有 Page 的写入时间都通过串口打印了出来,现在需要一款串口波形显示软件,来直观地看这 65536 个时间结果的差异。痞子衡试用了好几款软件:Serial Plot v0.12.0、Serial Chart V034、Serial Hunter V31,发现做得最完善的是 Serial Plot 软件,推荐给大家:

      Serial Plot 软件做得最好的地方是对串口接收数据格式的完善支持,既可以是 Binary(单通道字节长度可设),也可以是 ASCII 码(通道间隔符可设),还可以是自定义数据帧(帧头、帧格式可设),通道数也可以任意设,基本上可以满足大部分串口波形显示需求了。

    四、测试结果分析

      准备就绪,给板卡通上电,将测试程序下载进去跑起来,打开 Serial Plot 设置好串口接收参数后观测结果,我们发现波形显示是一条直线,即 65536 个 Page 写入时间是稳定的,都是 271us(测试工程选择的是 debug build),这个结果推翻了我们之前的两个猜测,写入 API 执行时间是稳定的,Flash 的各 Page 表现也是一致的。后来跟客户进一步沟通,客户反馈他们是在 ThreadX 的 LevelX 中发现的,所以看起来客户问题和 ThreadX 系统调度有关,那就是另外一个话题了,以后再展开。

      至此,i.MXRT系列FlexSPI驱动Flash页编程执行时间痞子衡便介绍完毕了,掌声在哪里~~~

    欢迎订阅

    文章会同时发布到我的 博客园主页CSDN主页知乎主页微信公众号 平台上。

    微信搜索"痞子衡嵌入式"或者扫描下面二维码,就可以在手机上第一时间看了哦。

      最后欢迎关注痞子衡个人微信公众号【痞子衡嵌入式】,一个专注嵌入式技术的公众号,跟着痞子衡一起玩转嵌入式。

    痞子衡嵌入式-微信二维码 痞子衡嵌入式-微信收款二维码 痞子衡嵌入式-支付宝收款二维码

      衡杰(痞子衡),目前就职于恩智浦MCU系统部门,担任嵌入式系统应用工程师。

      专栏内所有文章的转载请注明出处:http://www.cnblogs.com/henjay724/

      与痞子衡进一步交流或咨询业务合作请发邮件至 hengjie1989@foxmail.com

      可以关注痞子衡的Github主页 https://github.com/JayHeng,有很多好玩的嵌入式项目。

      关于专栏文章有任何疑问请直接在博客下面留言,痞子衡会及时回复免费(划重点)答疑。

      痞子衡邮箱已被私信挤爆,技术问题不推荐私信,坚持私信请先扫码付款(5元起步)再发。


  • 相关阅读:
    Linux内核链表——看这一篇文章就够了
    2的幂和按位与&——效率
    fgets注意事项
    GDB TUI
    GDB TUI
    linux shell命令行选项与参数用法详解
    What are the differences between Perl, Python, AWK and sed
    What is the difference between sed and awk
    /proc/sysrq-trigger
    C++ Sqlite3的基本使用
  • 原文地址:https://www.cnblogs.com/henjay724/p/15496673.html
Copyright © 2011-2022 走看看