
问题描述: 使用如题的结构,STM32将数据存储在EMMC上,电脑通过GL3227E(下文都简称3227)读取EMMC中的数据。使用STM32对EMMC进行格式化(一个主分区,exFAT)后,连接电脑后,发现并不能识别文件系统,必须用电脑重新格式化后才能使用;且电脑格式化之后,STM32再往EMMC里写数据,能确定已经写到了里面,但是连接电脑,却看不到任何STM32写进去的文件。 ![]() 测试代码,电脑格式化后,STM32能写能读,但是电脑读不到写进去的文件 解决过程: 用了很多方法去尝试解决这个问题,就不一一赘述了,直接讲最终解决办法的实现过程 根据经验,怀疑问题是出在分区表上(关于分区表我之前有写过点击查看),于是先使用STM32对EMMC进行格式化,对0扇区进行查看,如下图 ![]() 可以发现分区从扇区0x3F(63)开始,于是继续查看63扇区,如下图 ![]() 发现开头为0xEB 0x76 0x90 “EXFAT”,满足exFAT的卷格式,说明分区表没啥问题 我们继续,使用电脑通过3227对EMMC进行分区(2048对齐),并格式化,使用winhex对磁盘进行查看,首先是0扇区,如下图 ![]() 由于电脑分区时使用了2048字节对齐,我们可以看到分区表上,分区也的确是从0x0800(扇区2048)开始,我继续使用STM32对EMMC的扇区0进行查看(这一次没有使用STM32进行格式化操作),发现数据还是和之前一样 ![]() 是不是发现端倪了?电脑通过3227对EMMC的分区表进行修改后(也能看到的确修改成功了),STM32却并未查看到分区表被修改。这两种查看分区表的方式都是查看的“各自所认为的扇区0”,STM32看到的是“实际的EMMC的扇区0”,而电脑是通过3227看到的他“所谓的扇区0”,因此电脑“通过3227看到的扇区0”可能不是“实际的扇区0”。 这款芯片并没有什么加密,我猜测可能是3227读取的扇区有一定的偏移。于是我在STM32中添加了一段代码,在EMMC中去寻找“电脑通过3227看到的扇区0”。果不其然,在扇区256看到了相同的数据。这可是个好消息,于是我在winhex上又找了几个扇区的数据,使用STM32在偏移256扇区的地方均找到了相同的数据。结合之前“电脑通过3227修改分区表并没有修改EMMC实际扇区0上的分区表”这一现象,我认为3227在操作EMMC时偏移256扇区应该是个有效的猜测。 解决方案: 修改了STM32上user_diskio.c文件,使之访问EMMC时,和3227保持一致,均偏移256个扇区,代码如下 ![]() ![]() 重复文章开头问题描述中的流程,问题消失,成功解决。 ———————————————— 版权声明:balibala |
STM32 GUI LTDC 最大像素时钟评估方法
【2025·STM32峰会】GUI解决方案实训分享1-对LVGL咖啡机例程的牛刀小试以及问题排查
OpenBLT移植到STM32F405开发板
为什么要先开启STM32外设时钟?
【STM32MP157】从ST官方例程中分析RPMsg-TTY/SDB核间通信的使用方法
【经验分享】STM32实例-RTC实时时钟实验④-获取RTC时间函数与中断服务函数
STM32 以太网 MAC Loopback 的实现
STM32功能安全设计包,助力产品功能安全认证
基于STM32启动过程startup_xxxx.s文件经验分享
HRTIM 指南