痞子衡嵌入式：借助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-EVK\boards\evkmimxrt1170\driver_examples\flexspi\nor\polling_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-EVK\boards\evkmimxrt1170\driver_examples\flexspi\nor\polling_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\r\n", timeRes[i]);
    }
    
    while (1)
    {
    }
}

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

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

Serial Plot 软件源码：https://github.com/hyOzd/serialplot

Serial Plot 软件安装包：https://serialplot.ozderya.net/downloads/serialplot-0.12.0-win32-setup.exe

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

四、测试结果分析

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