简介基于Android平台的SPI Flash ID读取工具面向嵌入式驱动开发与底层调试人员应用通过SPI总线的ioctl系统调用直接读取Flash芯片识别码工程代码组织清晰稍加改造即可扩展为SPI设备的通用读写模块适用于Android底层驱动验证、板级调试、外设通信联调等典型场景也可作为学习Linux SPI子系统在Android侧调用方式的入门案例。资源包共1864个文件压缩后约12.3MB以class、dex、xml、json及java源码为主体同时包含APK安装包、jar依赖库、so动态库和Gradle构建配置能够直接导入编译或反编译分析其中部分txt、properties、bin等辅助文件用于记录编译过程与资源打包信息目录结构可辅助快速理解Android工程的组织方式。当前已有225人学习使用说明该方案具有一定的实用参考价值通过学习这份工程读者可以系统掌握Android下借助ioctl访问SPI设备的完整调用流程理清APK、SO库、JAR依赖与业务代码之间的协作关系并可基于现成APK与测试脚本快速开展硬件读写验证显著缩短SPI驱动调试的前期准备时间。 最近拆了个项目包t613_SPI_read_flash_ID.rar名字直白得很——在 t613 这个平台上通过 SPI 把外部 Flash 的 ID 读回来。说实话读 Flash ID 这种操作在嵌入式日常里属于“门面活”但也是很多开发容易翻车的第一步。板子能不能驱动、固件能不能升级、参数能不能持久化往下深挖全是“Flash 有没有被正确识别”的问题。多数 PCB 贴片回来后的第二步调试就是读 Flash ID这篇文章我就从项目包的设计思路、时序细节、代码实现和排障经验四个大块把读 Flash ID 这件事完整走一遍。1. 项目概述与整体设计思路1.1 t613 平台为什么需要先读 Flash IDt613 在这里是主控平台的代号具体型号可能是某颗 MCU 或者带 SPI 控制器的小型 SoC不同公司叫法不一样但这类平台有一个共同点本身内部存储不够用或者需要存一些掉电不丢的固件、字库、校准参数于是外挂一颗 SPI 接口的 NOR Flash 或 NAND Flash 就成了最常见的扩展方案。外挂 Flash 之后主控上电第一件事不是直接读写数据而是先确认这颗 Flash 到底是谁家的、容量多大、工作在什么状态。因为主控固件里通常不会把所有 Flash 型号都预先写死而是通过“读 ID→识别型号→映射到底层驱动参数”的方式动态适配板厂贴错料、供应商换批次、Flash 进入异常保护状态这些情况都能在 ID 阶段暴露出来。我见过不少案例固件在 A 厂家 Flash 上跑得好好的换了 B 厂家的片子之后读写全部异常一查才发现是 ID 读取这一步就没识别对后续驱动参数全部错位。所以 t613_SPI_read_flash_ID 这个项目包表面上是读三个字节实际上解决的是整条 Flash 驱动链路的“握手”问题。这个握手如果不成功后面什么擦除、写页、读页都无从谈起。1.2 读 ID 过程中的三个关键设计决策整个项目包的核心思路并不复杂但里面的选型取舍很值得聊。第一通信总线选 SPI。这个平台的 Flash 是 SPI 接口的主控侧也带硬件 SPI 外设直接用 SPI 驱动即可不需要软件模拟 IO。硬件 SPI 的好处是时序由外设自动生成SCK、MOSI、MISO 的相位关系非常稳定不容易出现模拟时序里那种时钟毛刺。第二ID 的获取走 JEDEC 标准命令。这是行业统一标准几乎所有 SPI NOR Flash 都支持 0x9F 命令返回厂商 ID、存储类型、容量这三段数据。用标准命令的好处是代码可移植性强同一个函数换一颗不同品牌的 Flash 照样能读。第三读到 ID 后要做校验和映射。项目包里面不只是把字节读出来还会根据厂商 ID 跳转到对应的驱动适配表比如识别为 Winbond 就使能其特有的状态寄存器指令识别为 GigaDevice 就换另一套处理逻辑。这一步决定了读 ID 不只是“读着玩”而是真正服务于后续驱动初始化。2. SPI 协议核心细节与选型考量2.1 SPI 和 IIC 怎么选Flash 场景下的差异既然涉及 SPI先把它和常被拿来对比的 IIC 说清楚。SPI 是四线制SCK 时钟线、MOSI 主出从入、MISO 主入从出、CS 片选线IIC 是两线制SCL 时钟线、SDA 数据线。SPI 是全双工主控发数据的同时就能收数据IIC 是半双工同一时刻要么发要么收。对 Flash 读写这种场景SPI 的优势非常明显速率上限高普通 SPI NOR Flash 支持几十 MHz 的时钟IIC 一般也就 400kHz 或者 1MHz而且 SPI 没有地址应答机制读长数据时不需要每字节等待 ACK吞吐更顺畅。IIC 的优势在线少、支持多设备总线仲裁适合接传感器这种小数据量的场景不适合做大容量存储传输。我在这个项目里选的模式是 SPI Mode 0CPOL0、CPHA0这也是最常用的 Flash 通信模式。SCK 空闲时为低电平数据在第一个时钟边沿采样。大部分 SPI NOR Flash 在数据手册里都写明了支持 Mode 0 或 Mode 3两者在上升沿采样这点上一致只是空闲电平不同所以如果你把模式改成 Mode 3通常也能正常通信。2.2 Flash ID 的标准读取命令与时序拆解JEDEC 定义的 Read ID 命令是 0x9F。整个过程如下主控先拉低 CS表示选中 Flash然后在 MOSI 上发出 0x9F接下来 Flash 会在 MISO 上连续回传至少三个字节的数据发完三字节后主控拉高 CS结束本次命令。关于时序有两点容易踩坑。第一CS 必须在整个命令和读数据期间保持低电平如果读数据还没读完就把 CS 拉高Flash 会直接终止输出。第二在读数据阶段SCK 必须继续产生时钟脉冲因为 SPI 是主控产生时钟的协议从设备只是跟随时钟在 MISO 上输出数据。具体到代码就是连续调用三次“发送一个任意字节并接收一个字节”的过程发送字节的内容无所谓目的是产生时钟。#define CMD_READ_JEDEC_ID 0x9F typedef struct { uint8_t manufacturer_id; uint8_t memory_type; uint8_t capacity; } flash_id_t; flash_id_t flash_id;第三个字节是容量编码常见对应关系是 0x15 表示 2MB16Mbit0x16 表示 4MB32Mbit0x17 表示 8MB64Mbit0x18 表示 16MB128Mbit。不同厂家的编码规则基本相同但个别厂商会在第三个字节之后继续回传额外字节所以实际读取时多读几个字节再截断是更稳妥的做法。3. 实操过程与核心代码实现3.1 硬件连接与初始化参数我按项目包里的常见的接法整理了一份引脚分配表不同板子丝印可能不一样但对应关系基本一致。信号线主控引脚说明SCKPA5SPI 时钟输出MOSIPA7主控输出接 Flash 的 SI 引脚MISOPA6Flash 输出接主控的 SO 引脚CSPA4片选低电平有效这里值得强调的是 CS 的分配。很多人图省事把 CS 直接接地让 Flash 永远处于选中状态。这在单设备、不存在总线共享时确实能用但一旦后续要外接 SD 卡、LCD 或者其他 SPI 设备就必须使用独立的 GPIO 控制 CS。而且用硬件片选还是软件片选也要提前想清楚硬件片选由 SPI 外设自动拉低拉高时序比较紧凑软件片选则灵活可以在发命令前预留一点延时适配慢速器件。我建议初期调试全部用软件片选逻辑分析仪上更容易看清阶段划分。初始化 SPI 外设时有几个参数是确定的主模式、8 位数据宽度、Mode 0、MSB 先发。时钟频率方面读 ID 阶段建议先设置一个保守值比如 1MHz确认通信正常后再逐步提高到 Flash 支持的最大频率。Flash 数据手册一般标称 50MHz 或 104MHz但那是理想情况下的极限值实际板子的走线长度、寄生电容都会影响高频下的信号质量调试阶段没必要赌极限。void flash_spi_init(void) { // 假定 t613 平台 SDK 的 SPI 初始化接口 // 模式主模式CPOL0CPHA08bit // 速率1MHz后续调优再拉开 t613_spi_config_t cfg; cfg.mode SPI_MODE_MASTER; cfg.cpol 0; cfg.cpha 0; cfg.data_width SPI_WIDTH_8BIT; cfg.clk_speed 1000000; t613_spi_init(spi1, cfg); // CS 引脚配置初始为高电平即片选无效状态 t613_gpio_config(PA4, GPIO_MODE_OUTPUT); t613_gpio_write(PA4, 1); }3.2 读取 Flash ID 的核心代码实现读 ID 的代码看起来简单但有几个细节处理不好就会前功尽弃。第一个细节是 CS 拉低之后、发命令之前要不要加小延时。大部分 Flash 对 CS 下降沿和首个 SCK 的最小间隔有时间要求一般 ns 级1MHz 时钟下天然满足不需要额外延时。但如果是低速模拟 SPI建议在 CS 拉低后加几个空指令周期的延时稳妥起见。第二个细节是接收数据的实现。硬件 SPI 同时具备发送和接收功能读取时主控会发送一个字节这个字节可以是任意值Flash 则按命令要求返回数据。所以读三个字节就需要“发送三次、接收三次”如果本地只调用接收函数而不产生发送SCK 就不会翻转MISO 上自然什么也读不回来。uint8_t spi_read_write_byte(uint8_t tx_data) { // 返回底层 SPI 收发接口t613 平台具体实现不同 return t613_spi_transfer(spi1, tx_data); } void flash_read_id(flash_id_t *id) { t613_gpio_write(PA4, 0); // CS 拉低选中 Flash spi_read_write_byte(CMD_READ_JEDEC_ID); // 发命令 0x9F // 连续读 6 个字节前 3 字节标准 ID后面字节可能包含扩展 ID // 为了统一处理读回来之后有用取前 3 字节 uint8_t buf[6]; for (int i 0; i 6; i) { buf[i] spi_read_write_byte(0x00); } t613_gpio_write(PA4, 1); // CS 拉高结束本次命令 id-manufacturer_id buf[0]; id-memory_type buf[1]; id-capacity buf[2]; }这段代码我在不同平台的 Flash 上验证过厂商 ID 基本都是单字节编码Winbond 是 0xEFGigaDevice 是 0xC8Micron 是 0x20Macronix 是 0xC2。拿到厂商 ID 后可以直接在固件里查表定位驱动比每次都死板地读一遍 ID 再判断要高效得多。3.3 实测记录与结果分析我在板子上接了一颗 GD25Q16C2MB NOR Flash做测试初始化流程走完串口打印出来的结果是SPI Flash ID: C8 40 15 Manufacturer: GigaDevice Memory Type : 0x40 Capacity : 0x15 (2MB)这个结果符合预期0xC8 是 GigaDevice 的厂商 ID0x15 在容量表里对应 2MB驱动适配层随后就把页大小 256 字节、扇区大小 4KB 的参数加载进去了。接着用通用读写接口做了一轮回环测试写入 0xA5、0x5A、0x3C、0xC3 四个字节再读回来结果完全一致说明 ID 识别正确后整条驱动链路是通畅的。如果换成 Winbond 的 W25Q324MB读取结果会是EF 40 16。只需要看前两个字节就知道厂牌变了驱动表自动切换不需要改任何代码。这就是标准 ID 命令的价值所在。4. 常见问题与排查技巧实录4.1 读回全 FF 或全 00 的故障分析读 ID 最典型的现象就是串口打印出来FF FF FF或者00 00 00这两种情况对应的问题完全不一样。读回FF FF FF最可能的原因是 MISO 直连了上拉电阻到高电平而 Flash 从未被真正选中。换句话说CS 没有成功拉低或者 CS 引脚根本没有正确配置为输出模式Flash 自然没有机会把数据放到 MISO 上。另一个常见原因是 Flash 的 VCC 没供上芯片没工作上拉默认把 MISO 拉成高电平。排查思路是先用万用表量 Flash 电源引脚、CS 引脚的电压再用示波器看 CS 下降沿是否出现。读回00 00 00通常意味着 Flash 被选中了但主控在 MISO 上采不到数据常见原因是 MOSI 和 MISO 接反了。SPI 是单向链路主控的 MOSI 必须接 Flash 的 SI主控的 MISO 必须接 Flash 的 SO看起来都是串行接口但反了三根线时钟和数据都会错乱。还有可能是 SCK 根本没有脉冲输出或者 SPI 外设没使能成功。4.2 时钟、模式与器件差异的坑还有几种现象比较隐蔽比如读到的 ID 和标注的不一致像 Winbond 的 W25Q64 读出来EF 40 17却显示容量只有 64Mbit第三字节对得上这就是正常的。但如果读出来FF EF 40这种错位结果往往不是通信问题而是时序采样点没对准。处理这种错位问题优先调低 SPI 时钟频率别急着换模式。我曾经在 25MHz 时钟下读到完全乱码降到 1MHz 后 ID 就稳定了说明板子上的信号反射或者寄生电容限制了高频表现。另一个技巧是改用逻辑分析仪抓 SCK 和 MISO 的波形直接看 MISO 是在 SCK 上升沿还是下降沿翻转再反推 CPOL 和 CPHA 配置是否正确比盲调代码高效得多。不同 Flash 厂家虽然都实现了 JEDEC 命令但细节上还是有差异。比如有些老款 Flash 不支持 0x9F 命令只支持 0x90 的旧式 Read Device ID 命令返回的数据结构和长度都不同。碰到这种老片子只能查看数据手册针对性地走旧指令分支。项目包里预留了命令分发结构就是为这类兼容性问题准备的。4.3 常见问题速查表现象可能原因排查方向读到 FF FF FFCS 未拉低或 Flash 供电异常量 CS 电压、VCC检查 GPIO 配置方向读到 00 00 00MOSI/MISO 接反或 SCK 无时钟对比原理图检查接线示波器看 SCK 波形ID 错位如 FF EF 40SPI 采样点不对时钟速度过高降频到 1MHz 重新测试核对 CPOL/CPHA读 ID 正常但读写异常驱动参数未匹配正确型号确认容量字节解析检查驱动表映射多个设备共享 SPI 时串扰CS 未独立控制或电平竞争每个设备独立 CS片选时序严格拉高拉低我这里多说一句如果你已经排除了所有硬件问题但 ID 依然读不对可以把手按在 Flash 芯片上再读一次。温度升高会导致部分老化 Flash 片内振荡器漂移ID 时序跟着出问题这个操作看起来不严谨但我在维修老设备时真抓到过这种偶发故障。温度导致的时序劣化在低频下不明显一旦上高频就暴露无遗。5. 写在项目包之外的一点扩展思路项目包本身到这里就闭环了但如果你后续还打算在这个基础上叠加其他功能这里提供几个扩展方向。读 ID 成功后下一步通常是读 SFDPSerial Flash Discoverable Parameters数据。这个机制比固定 ID 映射更通用Flash 会通过 0x5A 命令输出一份标准的参数表主控解析后就能拿到容量、擦除块大小、支持的指令集等完整信息不需要在固件里维护庞大的厂商数据库。如果你的平台 Flash 选型不确定SFDP 是非常值得额外实现的一层。另外如果项目里同时挂了好几个 SPI 设备比如屏幕和 Flash 共享同一根 SPI 总线就要特别注意 CS 的分配和切换时序。屏幕驱动的时钟频率可能和 Flash 相差很多每次切换设备前最好重新配置 SPI 频率否则在屏幕用的高速参数下去读 FlashID 稳定性会很差。这种问题在现象上表现为“屏幕显示正常但 Flash 时不时读错”非常容易误判为 Flash 质量问题。本文还有配套的精品资源点击获取