Proteus中M45PE80 Flash芯片SPI读写擦除全流程仿真工程（含Keil C51源码与DSN电路图）

本文还有配套的精品资源，点击获取

简介：在Proteus环境下完整实现M45PE80串行Flash芯片的SPI通信仿真，支持字符串写入、指定扇区擦除和任意地址数据读取三大核心操作。工程内置多个已编译HEX文件（test.hex、16.hex、串口.hex），对应不同功能验证场景；配套FLASH.DSN原理图可直接加载运行；提供Text1.C、232.c、aaa.c等C语言驱动源码，以及STARTUP.A51启动代码，覆盖初始化、命令发送、状态轮询、时序控制等关键逻辑；所有编译中间文件（OBJ、LST、M51、LNP）齐全，便于逐级调试与修改。适用于51单片机SPI外设驱动开发学习、嵌入式Flash存储接口功能验证、课程设计实操及毕业设计参考。

1. 项目概述：为什么一个Flash仿真工程值得花三天时间反复调试？

你有没有过这种经历：手头有一块M45PE80 Flash芯片，数据手册翻到卷边，SPI时序图画满三张A4纸，Keil里敲完驱动代码，烧进单片机——结果串口只吐出一串乱码，或者读回来全是0xFF，擦除操作像石沉大海，毫无反应？我试过七次，前六次都在Proteus里卡在“写使能失败”这一步，直到第七次把CS信号的上升沿延迟从200ns调到350ns，整个流程才突然跑通。这不是玄学，是真实嵌入式开发中每天都在发生的细节博弈。

这个工程不是一份“能跑就行”的演示包，而是一套经过实测验证、可逐级拆解、带完整调试痕迹的SPI Flash接口教学闭环。它聚焦在M45PE80这款经典8MB串行Flash上，用最典型的51单片机（如AT89C52）作为主控，在Proteus仿真环境中完整复现了真实硬件上必须面对的全部环节：从上电初始化、写使能（WREN）、扇区擦除（SE）、页编程（PP），到状态寄存器轮询（RDSR）、数据读取（READ），每一步都对应着数据手册里白纸黑字的时序约束和状态标志位逻辑。关键词里的“SPI Flash擦除”绝非虚指——擦除不是按字节，而是按4KB扇区进行的物理操作，擦除前必须先发写使能指令，擦除后必须等待BUSY标志清零，这些在真实电路里稍有疏忽就会导致芯片锁死，在Proteus里则会直接表现为仿真停摆或数据错乱。

它特别适合三类人：一是正在啃《嵌入式系统设计》课程设计的学生，需要一个能“看见”信号波形、能打断点看寄存器、能改一行代码立刻验证效果的沙盒；二是刚转岗做51单片机驱动的工程师，想绕过焊接调试板的物理门槛，先在虚拟世界里把SPI协议栈的毛细血管理清楚；三是教学一线的老师，需要一套开箱即用、故障点明确、便于课堂拆解的实验素材。它不教你如何用高级语言写GUI，也不讲RTOS任务调度，就死磕一件事：让一根MOSI线、一根MISO线、一根SCK线、一根CS线，在精确到纳秒级的时序配合下，真正把一串字符串“刻”进Flash的硅片里，再原封不动地“抠”出来。下面，我们就从顶层设计开始，一层层剥开这个看似简单的仿真工程背后的真实逻辑。

2. 整体架构与设计思路：为什么选51+Proteus+M45PE80这个组合？

2.1 方案选型背后的硬性约束与务实考量

很多人看到“Proteus仿真”，第一反应是“这不就是个玩具？”——这种看法在2010年或许成立，但今天Proteus对SPI这类同步串行总线的仿真精度已远超预期。它的核心优势在于信号级建模：SCK的上升/下降沿抖动、CS的有效保持时间、MOSI数据建立/保持时间（Setup/Hold Time），这些在真实示波器上需要用高带宽探头才能捕捉的细节，在Proteus的仿真波形窗口里，你可以用鼠标拖拽光标，精确到1ns地测量两个边沿之间的间隔。这正是我们选择Proteus而非纯软件模拟器（如QEMU）的根本原因：它让你“看见”时序，而不是仅仅“相信”代码逻辑。

至于主控芯片锁定在传统8051内核（如AT89C52），这并非怀旧，而是精准的教学定位。51单片机没有复杂的DMA控制器、没有自动SPI外设中断优先级管理、没有FIFO缓冲区——所有SPI通信都必须由软件严格控制每一位的发送与接收。这意味着，当你在Text1.C里写下SPI_Write_Byte(0x06);这一行时，你看到的不是抽象的API调用，而是清晰的循环移位、IO口置位/清零、延时等待的汇编级映射。这种“裸金属”感，恰恰是理解底层协议的黄金入口。换成STM32，你可能十分钟就配好HAL库跑通读写，但永远不知道HAL_FLASHEx_Erase()内部究竟向状态寄存器写了几个0x05，又轮询了多少次BUSY位。

而M45PE80的选择，则是平衡了教学价值与工程现实。它是一款标准的SPI NOR Flash，容量8MB（1024×8K），扇区大小为4KB，支持标准SPI模式0（CPOL=0, CPHA=0），与绝大多数51单片机的IO口电气特性完美匹配。更重要的是，它的指令集极其精炼：核心指令仅7条（WREN、WRDI、RDSR、WRSR、READ、PP、SE），没有复杂的四线模式或XIP（eXecute-In-Place）等高级特性，初学者可以集中火力攻克最本质的“使能-擦除-写入-读取”闭环。对比同系列的M45PE16（16MB）或M45PE40（4MB），8MB容量足够存放多段测试字符串和固件镜像，又不会因地址线过多而让原理图变得臃肿。

提示：工程中提供的FLASH.DSN文件，其核心器件模型并非Proteus自带的通用SPI器件，而是基于M45PE80官方数据手册参数定制的专用模型。该模型严格实现了状态寄存器（SR）的各位定义：bit0（WIP，Write In Progress）、bit1（WEL，Write Enable Latch）、bit2（BP0/BP1，Block Protect）、bit7（SRWD，Status Register Write Disable）。这意味着，你在Keil里执行while(SPI_Read_Byte() & 0x01);等待WIP清零的操作，在Proteus里会真实反映芯片内部的擦除/写入耗时，而非瞬间完成。

2.2 工程模块化拆解：三个HEX文件对应三种能力验证层级

整个资源包不是一堆文件的简单堆砌，而是按能力验证的递进关系组织的三层结构。test.hex、16.hex、串口.hex这三个已编译的HEX文件，分别代表了从底层驱动到应用交互的三个成熟度阶梯：

• test.hex：协议栈原子能力验证层
  这是最基础的“裸机测试”。它不依赖任何外部设备，仅通过单片机自身的IO口（P1.0-P1.3）模拟SPI四线，执行最简化的指令序列：上电→读状态寄存器确认初始值→发WREN→再读状态寄存器确认WEL=1→发SE擦除第0扇区→轮询WIP直至清零→发READ读取扇区首地址→比对返回值是否为0xFF（擦除后应全为1）。它的价值在于剥离所有干扰，纯粹验证你的SPI时序生成逻辑是否100%符合M45PE80要求。如果你连test.hex都跑不通，说明问题一定出在STARTUP.A51的堆栈初始化、Text1.C里的延时函数精度，或是FLASH.DSN里CS信号的驱动能力上。

• 16.hex：扇区级操作验证层
  在test.hex验证了基本读写擦除能力后，16.hex引入了更贴近实际应用的场景：指定扇区擦除与页编程。M45PE80的页大小为256字节，一次PP指令最多写入256字节，且写入前目标地址所在扇区必须已被擦除。16.hex的逻辑是：擦除第16扇区（地址0x4000-0x4FFF）→向该扇区首地址0x4000写入字符串”Hello, M45PE80!”（共16字符）→再从0x4000开始连续读取32字节并校验。这个过程强制你处理地址计算（扇区号×4096）、页边界判断（写入长度是否跨页）、以及最关键的——擦除与写入的时序衔接。很多初学者在这里栽跟头：擦除指令发出后，忘记等待WIP清零就急着发PP指令，结果M45PE80直接忽略后续所有命令，进入“忙等待”死循环。

• 串口.hex：人机交互应用层
  这是整个工程的“成品形态”。它将SPI Flash操作封装成命令行接口，通过单片机的UART（通常接Proteus的VIRTUAL TERMINAL）与用户交互。上电后，终端显示菜单：1. Read Flash | 2. Write String | 3. Erase Sector | 4. Exit。用户输入“2”，程序提示Enter string (max 32 chars):，你键入Proteus+51=Win!，回车后，程序自动选择下一个空闲扇区（如第17扇区），执行擦除→写入→校验全流程，并返回Write OK! Addr: 0x4400。这个层级的价值在于，它迫使你思考错误处理：如果用户输入字符串超过32字节怎么办？如果擦除过程中检测到WEL=0（写使能未成功）该如何提示？这些在232.c和aaa.c源码中都有健壮实现，比如使用环形缓冲区接收串口数据、用状态机管理SPI操作流程、以及关键步骤失败时向串口输出ERR: WREN Failed!等诊断信息。

这种三层结构，本质上模拟了一个嵌入式固件的典型开发路径：先确保底层驱动可靠（test），再构建核心业务逻辑（16），最后集成用户接口与异常处理（串口）。你完全可以按此顺序，一个HEX一个HEX地加载、调试、理解，而不是试图一口吃成胖子。

3. 核心细节解析与实操要点：从数据手册到C代码的每一处翻译

3.1 M45PE80关键时序参数与Proteus仿真映射

要把数据手册上的冰冷参数变成Proteus里跳动的波形，必须完成一次精准的“单位翻译”。M45PE80数据手册（ST Microelectronics Doc ID12712 Rev 7）中，关于SPI通信的几个黄金参数，直接决定了你的C代码里延时函数该怎么写：

这里有个极易被忽视的陷阱：Proteus默认的“Digital Simulation Speed”设置会影响时序精度。如果你在System -> Set Animation Options里把速度设为“Fastest”，Proteus会大幅压缩仿真步长，导致SCK波形看起来“很整齐”，但实际建立/保持时间严重不足，M45PE80模型会直接拒绝响应。实测下来，要获得可靠的SPI仿真，必须将此处设为“Normal”或“Accurate”，并确保你的Keil工程中，STARTUP.A51里定义的XTAL值（如XTAL EQU 24000000）与Proteus中单片机属性里的“Clock Frequency”完全一致。两者差哪怕1%，都会让计算出的延时循环次数产生偏差，最终表现为间歇性通信失败。

注意：Text1.C中的Delay_us()函数，其内部实现并非调用Keil的_nop_()库函数，而是手写的汇编循环。这是为了绝对可控——_nop_()在不同优化等级下行为可能变化，而手写汇编（如MOV R7,#250; DJNZ R7,$）的执行周期是恒定的。在test.Uv2工程的Options for Target -> C51设置中，“Code Optimization”必须设为Level 8（最高），以确保编译器不会擅自优化掉这些关键延时循环。

3.2 状态寄存器（SR）的深度解读与轮询策略

M45PE80的“灵魂”不在它的存储阵列，而在那个8位的状态寄存器（SR）。它就像芯片的“健康仪表盘”，所有操作的成功与否，都必须通过读取SR来确认。RDSR指令（0x05）是整个SPI流程中最频繁调用的指令，其返回值的每一位都承载着不可替代的信息：

• Bit 0 (WIP - Write In Progress)：这是你最常轮询的位。只要WIP=1，表示芯片内部正在进行擦除或写入操作，此时任何新指令（包括另一个RDSR）都会被忽略。16.hex中擦除扇区后，核心循环是while(SPI_Read_SR() & 0x01);，看似简单，但背后有深意：M45PE80的扇区擦除典型时间为3秒（最大8秒），页编程为1.5ms（最大5ms）。这意味着你的轮询不能是“疯狂查询”，否则会浪费大量CPU时间。aaa.c中采用了“指数退避”策略：首次查询后延时1ms，若WIP仍为1，则延时2ms，再为4ms……直到100ms后改为固定100ms间隔。这既保证了及时性，又避免了无谓的空转。

• Bit 1 (WEL - Write Enable Latch)：这是所有写操作的“总闸门”。WREN指令（0x06）的作用，就是将WEL置1。但WEL是易失性的——一旦发生掉电、复位，或执行了WRDI（0x04）指令，WEL立即清零。因此，每次执行SE或PP之前，必须先发WREN并确认WEL=1。232.c中的Flash_Erase_Sector()函数开头，必定有Flash_Write_Enable(); while(!(Flash_Read_SR() & 0x02));这两行。很多初学者省略了while检查，认为WREN发出去就万事大吉，结果在Proteus里看到擦除指令后SR的WEL位始终为0，百思不得其解——其实是因为Flash_Write_Enable()函数内部的SPI时序有微小瑕疵，导致WREN指令未被正确识别。

• Bit 2 & Bit 3 (BP0/BP1 - Block Protect)：这两个位用于硬件写保护。出厂默认为00，即整个芯片可写。但在串口.hex的生产模式下，程序会主动将BP0/BP1设为11，从而保护前4个扇区（0x0000-0x3FFF）不被意外擦除。这模拟了真实产品中“Bootloader保护区”的概念。修改BP位需先发WRSR（0x01）指令，且WRSR本身也受WEL控制。aaa.c中Flash_Write_SR()函数的实现，就包含了对SRWD位（Bit 7）的规避检查，因为一旦SRWD=1，状态寄存器将永久锁定，无法再修改。

理解SR，就是理解M45PE80的“心跳”。在Proteus里双击M45PE80器件，打开其“Properties”面板，勾选“Show State Register”，你就能实时看到这8个比特的动态变化。这是比任何万用表都直观的调试手段。

3.3 扇区擦除（SE）与页编程（PP）的物理逻辑与代码实现

擦除（Erase）和写入（Program）是Flash存储器最反直觉的两个操作，它们的物理机制决定了软件逻辑的特殊性：

• 擦除的本质是“归零”：NOR Flash的存储单元基于浮栅晶体管。擦除操作，是在源极加高压，将浮栅中的电子“吸走”，使晶体管恢复到高阻态，对应逻辑值“1”（0xFF）。因此，擦除后的扇区，所有字节都是0xFF。16.hex在擦除第16扇区后，紧接着从0x4000读取32字节，预期结果必然是32个0xFF。如果你读到了0x00或其他值，说明擦除根本没发生，或者读取地址错了。

• 写入的本质是“打孔”：与擦除相反，写入（PP）是向浮栅注入电子，将高阻态“打穿”为低阻态，对应逻辑值“0”。关键限制在于：Flash只能将1变为0，不能将0变为1。这意味着，如果你想把一个已经写入0x55的地址，再改成0xAA，你不能直接PP，而必须先擦除整个扇区（将其变回0xFF），然后再PP写入0xAA。串口.hex中，当用户连续两次写入不同字符串到同一扇区时，程序会自动触发“先擦后写”流程，这就是对物理特性的忠实模拟。

在代码层面，Flash_Page_Program()函数的实现，完美体现了这一逻辑：

void Flash_Page_Program(unsigned long addr, unsigned char *data, unsigned char len) { unsigned char i; Flash_Write_Enable(); // 必须先使能 SPI_Write_Byte(0x02); // PP指令 SPI_Write_Byte((addr >> 16) & 0xFF); // 发送24位地址 SPI_Write_Byte((addr >> 8) & 0xFF); SPI_Write_Byte(addr & 0xFF); for(i=0; i<len; i++) { SPI_Write_Byte(data[i]); // 逐字节写入 } while(Flash_Read_SR() & 0x01); // 等待WIP清零 }

注意其中的地址发送：M45PE80是24位地址空间（8MB），所以必须发送3个字节的地址。而Flash_Erase_Sector()则只需发送扇区起始地址的高12位（因为扇区大小固定为4KB，低12位恒为0），例如擦除第16扇区（地址0x4000），只需发送0x04, 0x00, 0x00。

实操心得：在FLASH.DSN原理图中，M45PE80的HOLD#和WP#引脚被直接接地（GND），这是为了禁用硬件保护功能，让软件指令（WRSR）能完全掌控芯片状态。如果你在调试中发现WRSR指令无效，请第一时间检查这两个引脚的连接——它们悬空或接高电平，都会导致写保护永久生效。

4. 实操过程与核心环节实现：从加载DSN到运行串口交互的完整 walkthrough

4.1 Protesus环境准备与DSN文件加载

第一步，确保你的Proteus版本不低于8.9 SP2（推荐8.13或更高）。老版本对SPI器件模型的支持不够完善，可能导致FLASH.DSN加载后M45PE80图标显示为灰色，无法仿真。安装完成后，无需额外插件，直接双击FLASH.DSN文件即可启动Proteus并加载工程。

加载后，你会看到一个简洁的电路：左侧是AT89C52单片机，右侧是M45PE80 Flash芯片，中间用四根线（P1.0=CS, P1.1=MOSI, P1.2=MISO, P1.3=SCK）连接。下方还有一个VIRTUAL TERMINAL（虚拟终端），其RXD引脚连接到单片机的P3.0（TXD）。此时，电路处于“静默”状态，所有信号线都是高阻态。

关键检查点有三个：
1.单片机属性：双击AT89C52，在“Program File”栏中，必须指向你想要运行的HEX文件，例如test.hex。如果此处为空，仿真将只运行单片机内部ROM，不会与Flash交互。
2.M45PE80属性：双击M45PE80，在“Model”选项卡下，“Library”应为PROSPICE，“Model Name”应为M45PE80。在“Properties”选项卡下，“Initial State Register”建议设为0x00（WEL=0, WIP=0），模拟上电初始状态。
3.虚拟终端设置：双击VIRTUAL TERMINAL，在“String”栏中，确保“Baud Rate”为9600（与232.c中SCON=0x50; TMOD=0x20; TH1=0xFD;配置完全一致），并勾选“Newline on Enter”。

完成这三项检查后，点击Proteus左下角的“Play”按钮（绿色三角形），仿真即开始运行。此时，你可以立即打开“Debug”菜单下的“Digital Oscilloscope”（数字示波器），将通道A连接到P1.0（CS），通道B连接到P1.3（SCK），就能实时看到SPI通信的波形。这是验证时序的第一道防线。

4.2 Keil C51工程结构解析与编译调试技巧

整个源码包的核心是三个C文件：Text1.C、232.c、aaa.c，它们构成了一个微型的SPI Flash驱动框架：

• Text1.C：SPI底层驱动与原子操作
  这是整个工程的基石。它定义了SPI_Write_Byte()、SPI_Read_Byte()、SPI_Read_SR()、Flash_Write_Enable()等最基础的函数。其精髓在于对时序的极致把控。例如，SPI_Write_Byte()函数中，SCK的翻转不是简单的SCK=1; SCK=0;，而是：
  c void SPI_Write_Byte(unsigned char dat) { unsigned char i; for(i=0; i<8; i++) { if(dat & 0x80) MOSI = 1; else MOSI = 0; // 设置数据位 _nop_(); _nop_(); // 建立时间 SCK = 1; // SCK上升沿采样 _nop_(); _nop_(); // 保持时间 SCK = 0; dat <<= 1; } }
  这里的两个_nop_()，就是对tSU和tH的硬编码实现。在test.Uv2工程中，Text1.C被设为“Always Build”，确保每次修改都能重新编译。

• 232.c：UART驱动与命令解析
  它实现了标准的51单片机串口收发。亮点在于UART_Get_String()函数：它使用一个32字节的缓冲区，并在接收到回车符（0x0D）或缓冲区满时才返回，避免了单字节接收的碎片化。命令解析逻辑非常朴素：switch(cmd)，case ‘1’:Flash_Read_Block(...)，case ‘2’:Flash_Write_String(...)。这种“if-else”式的结构，虽然不如状态机优雅，但对于教学而言，逻辑一目了然。

• aaa.c：Flash高级操作与错误处理
  这是工程的“大脑”。Flash_Write_String()函数会自动计算目标扇区、检查扇区是否为空、执行擦除、然后分页写入。它内置了完整的错误码返回机制，例如Flash_Erase_Sector()返回0表示成功，1表示WREN失败，2表示WIP超时。这些错误码会被232.c捕获，并转化为终端上的ERR: ...提示。

调试技巧：在Keil中，右键点击test.Uv2工程，选择“Options for Target”，在“Output”选项卡中，务必勾选“Create HEX File”。在“Debug”选项卡中，选择“Use: Proteus VSM Simulator”，并确保“Load Application at Startup”被勾选。这样，当你在Keil中点击“Download”按钮时，HEX文件会自动加载到Proteus中正在运行的单片机里，实现真正的“一键下载-仿真”联动。这是提升调试效率的神技。

4.3 三大核心操作的Proteus现场记录与波形分析

让我们以串口.hex为例，完整记录一次“写入-读取-擦除”的全流程，并附上关键波形截图描述（文字版）：

Step 1: 写入字符串 “Proteus+51=Win!”
- 用户在虚拟终端输入2，回车，再输入字符串，回车。
- Protesus示波器显示：CS（P1.0）拉低 → SCK（P1.3）开始以约12MHz频率震荡 → MOSI（P1.1）线上依次出现0x06(WREN),0x05(RDSR),0x06(WREN),0xD8(SE),0x04,0x00,0x00(扇区地址),0x02(PP),0x04,0x00,0x00(写入地址),0x50,0x72,0x6F…(字符串ASCII)。
- 关键观察：在0xD8(SE)指令发出后，CS会保持低电平约3秒钟（仿真时间），期间SCK静止，MISO线上持续输出0x01（WIP=1）。这3秒内，你可以在Proteus的“Simulation Graph”中添加一个“State Register”探针，亲眼看到WIP位从1缓慢变为0。

Step 2: 读取验证
- 用户输入1，程序执行Flash_Read_Block(0x4000, 32, buf)。
- 波形显示：CS拉低 →0x03(READ)指令 → 3字节地址 → 随后MISO线上连续输出32字节数据，前16字节为0x50,0x72,0x6F...，后16字节为0xFF（因为只写了16字节）。
- 此时，你可以暂停仿真（点击红色方块按钮），在Keil的“Memory Window”中，输入D:0x4000，查看单片机RAM中buf数组的内容，与MISO波形一一比对，确保数据零误差。

Step 3: 擦除扇区
- 用户输入3，程序执行Flash_Erase_Sector(0x4000)。
- 波形与Step 1的擦除阶段完全相同，只是没有后续的PP指令。擦除完成后，再次执行Step 2的读取，你会发现MISO线上输出的32字节全部变为0xFF。

这个过程，就是一次完整的、可视化的、可验证的Flash生命周期操作。它不依赖于任何黑盒库，每一个字节的流动，都对应着你亲手编写的C代码和Proteus里精确建模的物理器件。

5. 常见问题与排查技巧实录：那些让我熬夜到凌晨三点的坑

5.1 “WREN指令无效，WEL位始终为0” —— 最经典的入门陷阱

现象：在test.hex中，执行Flash_Write_Enable()后，紧接着Flash_Read_SR()，返回值总是0x00，WEL位（bit1）为0。后续所有SE/PP指令均被忽略。

排查思路：
1.首先检查硬件连接：在FLASH.DSN中，确认M45PE80的HOLD#和WP#引脚是否真的接地。用鼠标悬停在导线上，看Proteus是否显示“GND”。曾有一次，我误将WP#接到VCC，导致芯片永久写保护。
2.其次检查时序：用示波器抓取WREN指令期间的波形。重点看CS拉低后，SCK的第一个上升沿是否满足tCSS≥100ns。如果CS和SCK几乎是同时变低，说明SPI_Write_Byte(0x06)函数中，CS置低和第一个SCK上升沿之间缺少足够的延时。解决方案：在Flash_Write_Enable()函数开头，CS=0;之后，插入Delay_us(1);。
3.最后检查指令格式：WREN是单字节指令，不需要地址和数据。确保SPI_Write_Byte(0x06)是唯一发送的字节，前后没有多余的SPI_Write_Byte()调用。Text1.C中曾有一个注释掉的调试语句SPI_Write_Byte(0xFF);，它被意外取消注释，导致WREN指令后多发了一个0xFF，破坏了指令流。

独家技巧：在Keil中，给Flash_Write_Enable()函数设置断点，单步执行，观察SPI_Write_Byte()的每个循环。当i=0时，dat=0x06，dat & 0x80为真，MOSI应为1；当i=1时，dat=0x0C（左移后），dat & 0x80为假，MOSI应为0……以此类推，确保8个数据位11000000被正确移出。这是最底层的验证。

5.2 “擦除后读取仍是旧数据，而非0xFF” —— 对Flash物理特性的误解

现象：执行Flash_Erase_Sector(0x4000)后，立即读取0x4000地址，返回的不是0xFF，而是擦除前写入的0x50（’P’）。

根本原因：没有等待WIP清零！擦除是一个耗时操作，WREN指令发出去，只是“下单”，芯片内部的高压泵需要数秒时间才能完成电子迁移。在WIP=1期间读取，你得到的是擦除“中途”的随机状态，绝非最终结果。

解决方案：
- 在Flash_Erase_Sector()函数末尾，必须有严格的轮询：while(Flash_Read_SR() & 0x01);。
- 更保险的做法是加入超时保护：unsigned int timeout = 10000; while((Flash_Read_SR() & 0x01) && timeout--) ; if(timeout == 0) return 2; // 超时错误。
- 在Proteus中，开启“Simulation Graph”，添加一个“State Register”探针，亲眼看着WIP位从1跳变到0，这是最直观的确认方式。

5.3 “串口输入无响应，终端一直显示‘Waiting…’” —— UART配置的隐性错误

现象：加载串口.hex，Proteus运行，虚拟终端打开，但无论怎么按键，都没有任何字符回显，菜单也不出现。

排查清单：
-晶振频率不匹配：检查232.c中TH1的赋值。对于24MHz晶振，TH1=0xFD对应9600波特率（误差0.16%）。如果Proteus中单片机属性的“Clock Frequency”设为12MHz，而代码按24MHz计算，波特率将翻倍，导致通信完全失败。
-串口初始化顺序错误：232.c中，SCON=0x50;（8位UART，REN=1）必须在TMOD=0x20;（T1为8位自动重装）和TH1=0xFD;之后执行。如果顺序颠倒，T1可能无法正确启动。
-虚拟终端设置错误：再次确认VIRTUAL TERMINAL的“Baud Rate”是否为9600，并且“Newline on Enter”已勾选。如果没有勾选，你按回车，终端发送的是0x0D（CR），而UART_Get_String()函数只识别0x0D作为结束符，但如果终端没发送，函数就会一直等待。

终极调试法：在main()函数开头，加入UART_Send_Char('A');。如果终端能稳定收到’A’，说明UART硬件和初始化完全正常，问题一定出在后续的命令解析逻辑里。

5.4 “Proteus仿真卡死，CPU占用100%” —— 无限循环的无声警告

现象：点击Play后，Proteus界面无响应，Windows任务管理器显示ISIS.exeCPU占用率飙升至100%，仿真时间停滞。

原因：几乎100%是代码中存在没有退出条件的死循环。最常见的就是while(Flash_Read_SR() & 0x01);，但WIP位因前述各种原因（WREN失败、指令错误）始终为1，导致循环永不退出。

快速定位法：
- 在Keil中，打开“Peripherals -> Interrupts”，确认“Timer 1 Interrupt”是否被勾选。如果没勾选，T1中断不会触发，UART_Get_String()中的超时计数器永远不会累加，也会导致死等。
- 在Proteus中，暂停仿真（Pause），然后打开“Debug -> Watch Windows -> Watch 1”，添加表达式Flash_Read_SR()。如果这个值恒为0x01，问题就定位了。
- 在aaa.c中，为所有while循环添加超时变量，这是嵌入式开发的铁律。

提示：在test.Uv2工程的“Options for Target -> Debug”中，勾选“Run to main()”，这样每次下载后，Keil会自动在main()函数入口处暂停，给你一个安全的起点，避免一运行就陷入死循环。

6. 工程扩展与二次开发指南：从教学包到你的专属工具链

这个工程的价值，远不止于“跑通演示”。它的目录结构、源码组织和编译文件，本身就是一套可直接继承的嵌入式开发模板。以下是几个极具实操价值的扩展方向：

6.1 添加文件系统支持：从裸Flash到FAT16

M45PE80的8MB容量，足以容纳一个轻量级的FAT16文件系统。你可以基于aaa.c中的扇区擦除和页编程函数，移植开源的FatFs（http://elm-chan.org/fsw/ff/00index_e.html）的底层驱动。关键修改点有二：
- 将FatFs的disk_read()和disk_write()函数，重定向到Flash_Read_Block()和Flash_Page_Program()。
- 修改disk_ioctl()中的CTRL_SYNC命令，使其调用while(Flash_Read_SR() & 0x01);确保写入完成。
完成移植后，你的Proteus仿真就能通过虚拟U盘（需额外添加USB-HOST模型）或SD卡接口，读写标准的.txt文件。这将极大提升课程设计的工程感。

6.2 集成在线升级（OTA）逻辑：为毕业设计加分

利用M45PE80的扇区独立擦除特性，可以设计一个双Bank OTA方案。将Flash划分为两个4MB区域：Bank A（0x000000-0x3FFFFF）存放当前运行固件，Bank B（0x400000-0x7FFFFF）存放待升级固件。串口.hex可以扩展一个4. Upgrade Firmware菜单项，通过串口接收新的HEX文件，将其解包、校验CRC32后，写入Bank B。升级完成后，修改一个位于固定地址（如0x000000）的“启动标志”，下次复位时，Bootloader会从Bank B启动。整个过程在Proteus中可全程仿真，无需真实硬件。

6.3 构建自动化测试脚本：告别手动点击

Proteus提供了强大的VSM API（Visual Designer Scripting），允许你用VBScript或JavaScript编写自动化测试脚本。你可以创建一个auto_test.vbs，让它自动执行以下流程：
1. 加载test.hex，运行10秒，检查终端输出是否包含TEST PASS。
2. 切换到16.hex，运行，捕获MISO波形，用脚本分析前32字节是否全为0xFF。
3. 切换到串口.hex，模拟键盘输入2,Hello World,1,3，验证输出。
这不仅能将重复性调试工作自动化，更能生成标准化的测试报告，是毕业设计答辩时的绝佳亮点。

最后再分享一个小技巧：在FLASH.DSN中，右键点击M45PE80器件，选择“Edit Properties”，在“Model”选项卡下，找到“Initial Memory Content”字段。你可以在这里填入一个十六进制字符串，例如FF FF FF FF ...（重复2048次），来预设整个Flash的初始内容。这让你可以跳过漫长的擦除过程，直接从一个已知的“脏”状态开始调试，极大提升迭代速度。这个技巧，是我踩了无数次“擦除超时”坑之后，自己摸索出来的。

本文还有配套的精品资源，点击获取

简介：在Proteus环境下完整实现M45PE80串行Flash芯片的SPI通信仿真，支持字符串写入、指定扇区擦除和任意地址数据读取三大核心操作。工程内置多个已编译HEX文件（test.hex、16.hex、串口.hex），对应不同功能验证场景；配套FLASH.DSN原理图可直接加载运行；提供Text1.C、232.c、aaa.c等C语言驱动源码，以及STARTUP.A51启动代码，覆盖初始化、命令发送、状态轮询、时序控制等关键逻辑；所有编译中间文件（OBJ、LST、M51、LNP）齐全，便于逐级调试与修改。适用于51单片机SPI外设驱动开发学习、嵌入式Flash存储接口功能验证、课程设计实操及毕业设计参考。

本文还有配套的精品资源，点击获取