CPU12汇编引导加载器：PCR寻址与Flash编程实战解析-平芜编程栈

1. 项目概述

在嵌入式开发的底层世界里，汇编语言是直接与硬件对话的“母语”。当你需要实现一个在芯片上电后最先运行、负责将新固件烧录到Flash中的引导加载器时，汇编的精确控制能力就变得无可替代。这次，我们深入一个经典的案例：基于Freescale（现NXP）HC12/S12系列CPU12内核的串行Flash引导加载器。这个项目不仅是一个功能实现，更是一个理解CPU12架构精髓的绝佳窗口，尤其是它那独特而巧妙的“程序计数器相对寻址”机制。

对于许多从高级语言转向底层开发的工程师来说，汇编中的寻址方式常常是第一个拦路虎。CPU12的指令集手册里可能找不到一个叫“PCR”的官方寻址模式，但你在代码里却会频繁看到JMP [Reset-$800, pcr]这样的写法。这到底是怎么工作的？它和中断向量表跳转、位置无关代码又有什么关系？这个引导加载器项目给出了教科书级别的答案。它利用汇编器的计算能力，实现了基于程序计数器的动态寻址，从而让一段代码无论被复制到内存的哪个位置（比如从Flash搬到RAM中执行），都能正确地跳转到目标地址。这对于必须在RAM中运行才能对Flash进行擦写的引导加载器来说，是生命线。

本文将带你逐行拆解这份来自官方应用笔记AN1718的经典代码。我们不会停留在简单的代码注释上，而是会深入其设计哲学：为什么中断向量要设计成两级跳转？如何在栈上“无中生有”地管理局部变量？那些看似魔术的org 0和set *伪指令背后，隐藏着怎样的地址计算技巧？我将结合自己多年在8位和16位MCU上“摸爬滚打”的经验，把官方文档里没写的调试坑、时序细节和替代方案都摊开来聊清楚。无论你是正在学习CPU12的新手，还是想重温经典嵌入式设计思想的老兵，这篇文章都能让你对汇编编程和引导加载器设计有更扎实、更透彻的理解。

2. CPU12程序计数器相对寻址深度解析

2.1 寻址模式的本质：CPU视角 vs. 汇编器视角

首先要纠正一个常见的误解：从CPU12硬件的角度看，它确实没有一种独立的、名为“程序计数器相对”（Program Counter Relative）的寻址模式。硬件直接支持的索引寻址模式，其变址寄存器可以是IX、IY、SP或PC。当我们写下,pcr时，这其实是一个给汇编器的“指令”，而不是给CPU的。

CPU能理解的是这样的指令：JMP [offset, PC]。这是一个带16位偏移量的间接索引寻址指令。它的含义是：以当前程序计数器（PC）的值为基址，加上指令中编码的那个16位偏移量，得到一个内存地址，而这个内存地址里存放的，才是最终要跳转的目标地址。关键在于，这个“当前PC值”指的是下一条指令开始处的地址。这是所有相关计算的基准点。

那么，问题来了：当我在源代码里写JMP [Reset-$800, pcr]时，我期望跳转到标号Reset所指向的中断向量。但Reset-$800这个表达式计算出的绝对地址，并不是CPU需要的那个相对于下一条指令的16位偏移量。这个转换工作，就由汇编器默默完成了。汇编器的工作流程可以拆解为三步：

计算目标绝对地址：解析表达式Reset-$800。假设Reset标号的地址是$FFFE（复位向量地址），那么$FFFE - $800 = $F7FE。这是目标向量在“次级中断向量表”中的绝对地址。
计算下一条指令地址：确定当前JMP指令之后，下一条指令开始的地址。假设这条JMP指令本身位于$FC07，并且它占用了3个字节（操作码$05+ 16位偏移量），那么下一条指令地址就是$FC07 + 3 = $FC0A。
计算并填充偏移量：汇编器执行计算：偏移量 = 目标绝对地址 ($F7FE) - 下一条指令地址 ($FC0A) = $FFFFFB F4（32位视角）。取这个结果的低16位，即$FBF4，将其作为机器码的一部分，填入JMP [offset, PC]指令的偏移量字段。

当CPU执行到这条指令时，它会进行反向操作：读取指令中的偏移量$FBF4（这是一个有符号的16位数，在这里是负数），将其与当前PC（即$FC0A）相加：$FC0A + $FBF4 = $F7FE（忽略进位），这正是我们想要的目标地址。这个过程完美地实现了地址无关的跳转，因为无论这段包含JMP指令的代码被链接到内存的哪个位置，汇编器都会为它重新计算正确的偏移量。

2.2 工程实践：中断向量重定向机制详解

理解了原理，我们来看这个引导加载器里最精妙的应用：中断向量重定向。在CPU12架构中，中断向量表通常固定在内存高地址区（如$FFD0-$FFFF）。但引导加载器自身可能需要占用这块区域，或者我们希望将中断服务例程（ISR）动态地重定向到RAM中运行更快的代码上。这时，两级跳转表的设计就派上用场了。

查看代码清单的$FC24开始部分，你会发现一系列如JBDLC: jmp [BDLC-$800, pcr]的指令。这构成了第一级跳转表，通常放在Flash中一个固定的、已知的位置。而BDLC-$800指向的是$FFD0 - $800 = $F7D0这个地址。在$F7D0附近的内存区域，我们需要放置第二级中断向量表，里面直接存放用户应用程序中各个ISR的入口地址。

这种设计的优势非常明显：

灵活性：用户程序可以自由地修改第二级向量表（前提是它所在的内存可写，比如RAM或者可擦写Flash），从而动态改变中断服务例程，而无需触碰固化在引导加载器中的第一级跳转表。
位置无关性：第一级跳转表使用PCR寻址，因此引导加载器代码可以被复制到RAM中执行，这些跳转指令依然能正确找到第二级向量表的位置。
空间效率：相比于每个中断向量都直接使用一个JMP指令（占3字节），这种间接跳转方式在向量数量多时，第一级表可以更紧凑。不过在本例中，每个JMP [offset, pcr]也占3字节，其优势更多体现在设计的清晰度和重定向能力上。

实操心得：调试PCR相关代码的坑早年用仿真器调试这类代码时，最容易晕头转向的就是地址计算。仿真器单步执行时，看到的PC值、指令码里的偏移量，常常对不上脑子里算的绝对地址。我的经验是：永远从汇编器的视角来验证。写一个小测试段，用汇编器生成列表文件（.lst），仔细核对标号地址、指令地址和生成的偏移量机器码。一旦理解了“下一条指令地址”这个基准点，所有问题都会迎刃而解。另一个坑是，有些简单的汇编器可能不支持,pcr语法。这时你就需要像应用笔记里提到的后备方案那样，手动计算偏移量表达式：[(<向量名> - $800) - (* + 4), pc]，其中*代表当前地址，+4是因为JMP [offset, pc]指令本身占4个字节（操作码$05+ 扩展字节$F3？这里需要查具体指令编码，笔记中$05是页前缀，实际CPU12的JMP [offset, PC]指令格式为$05 $F3 <16位偏移量>，共4字节）。手动计算时务必小心。

2.3 汇编器伪指令的魔法：ORG与SET的协同

为了在栈上定义局部变量，代码中使用了一段非常经典的汇编器技巧：

CurrentPC set * ; 保存当前PC值 org 0 ; 将汇编位置计数器临时设为0 ProgPulses: ds 1 ; 局部变量1 PMarginFlag: ds 1 ; 局部变量2 org CurrentPC ; 恢复原始PC值

这段代码的目的不是真的在地址0处分配变量，而是为了利用汇编器的地址计算功能，为栈帧内的局部变量定义偏移量。set *将当前地址（*）赋值给标号CurrentPC。org 0将汇编位置计数器重置为0，紧接着用ds（定义存储空间）指令“分配”空间。此时，标号ProgPulses的值为0，PMarginFlag的值为1。它们代表了从栈帧基址（通常是SP或Y寄存器指向的位置）开始的偏移量。最后org CurrentPC将位置计数器恢复，后续代码继续从原来的地址汇编。

在函数ProgFBlock中，通过ProgPulses, sp来访问这个变量。这里的sp是栈指针，ProgPulses就是相对于SP的偏移量。这种方法避免了手动计算偏移量的繁琐和容易出错，极大地提高了代码的可读性和可维护性。

注意事项：栈指针对齐与帧指针CPU12的栈指针（SP）在访问时，通常需要是偶数地址（16位对齐）以获得最佳性能。在使用上述方法定义局部变量时，要留意ds分配的总字节数，必要时使用align伪指令确保SP调整后仍是偶数。在一些更复杂的函数中，我习惯在入口处用pshy或tfr s, y将SP保存到Y寄存器作为帧指针（FP），然后通过ProgPulses, y来访问局部变量。这样即使在函数中SP因为压栈/出栈而变动，通过帧指针访问的局部变量偏移量依然是固定的，逻辑更清晰。

3. Flash引导加载器设计与实现精要

3.1 引导流程与运行环境切换

一个可靠的引导加载器，其首要任务是决定启动路径。我们分析的这段代码入口点在BootStart($FC00)。

硬件初始化与路径选择：
```
BootStart: lds #StackTop ; 初始化栈指针 brclr PORTDLC,$40,BootCopy ; 检查某个端口状态（如Boot引脚） jmp [Reset-$800,pcr] ; 条件不满足，跳转到用户程序
```
代码首先初始化栈指针，确保子程序调用和局部变量有空间。然后检查一个硬件状态（这里是通过PORTDLC的某一位），这个状态通常由一个外部引脚或内部标志位决定。如果条件满足（引脚为低），则执行引导加载器；否则，直接通过PCR跳转，跳转到用户应用程序的复位向量（次级向量表）所指向的地址，实现用户程序的直接启动。这是一种非常典型的“Boot Pin”启动选择机制。
代码搬移与位置无关执行：
```
BootCopy: clr COPCTL ; 关闭看门狗 ldx #BootLoad ; 源地址：Flash中的引导加载器代码起始 ldy #RAMStart ; 目标地址：RAM起始地址 ldd #BootLoadEnd ; 计算代码大小 subd #BootLoad MoveMore: movb 1,x+,1,y+ ; 逐字节复制 dbne d,MoveMore ; 循环直到复制完成 jmp RAMStart ; 跳转到RAM中执行
```
这是引导加载器的核心准备步骤。为什么一定要复制到RAM？因为接下来要对Flash进行擦写操作，而绝大多数微控制器都不允许在Flash的某个扇区执行代码的同时，对这个扇区或同一块Flash进行编程。这被称为“闪存编程约束”。将代码复制到RAM中运行，就规避了这个问题。jmp RAMStart这条绝对跳转指令，完成了从Flash到RAM的执行环境切换。而之前提到的所有PCR寻址指令，确保了这段被复制的代码在RAM中依然能正确跳转。

3.2 串行通信与S-Record协议解析

引导加载器通过串口（SCI）与上位机通信，接收要烧录的固件文件。这里采用的是经典的Motorola S-Record格式。这是一种十六进制文本格式，易于阅读和生成，在嵌入式领域历史悠久。

S-Record格式回顾：
- S0: 头部记录，包含描述信息，引导加载器通常忽略。
- S1: 数据记录，包含地址、数据和校验和，是固件主体。
- S9: 结束记录，表示文件结束。每条记录以字符S开头，接着是记录类型（0/1/9），然后是字节计数、地址、数据、校验和，所有数据均为ASCII编码的十六进制数。
协议处理实现：函数GetSRecord是协议解析的核心。它循环等待字符S，然后读取记录类型。对于S1记录，它解析出数据长度、加载地址，并将数据字节读入缓冲区SRecData。校验和计算是所有字节（包括长度、地址、数据）的累加和，取反加一后应为0（实际代码中通过inc CheckSum,sp后判断是否为零来验证）。
避坑指南：串口通信的鲁棒性这份示例代码的通信逻辑非常简洁，假设了理想环境。在实际产品中，必须增强其鲁棒性：
- 超时机制：在getchar循环等待RDRF的地方，应加入定时器超时判断。否则，如果上位机没有发送数据，程序将永远死等。
- 错误恢复：校验和错误后，不应只是简单返回错误。应该向上位机发送一个错误响应（如NAK），并请求重发当前记录。
- 流量控制：代码中使用了“步调字符”（*），在发送*后才接收下一条记录。这是一种简单的软件流控。对于高速通信或大数据量，建议实现硬件RTS/CTS流控或更完善的XON/XOFF协议。
- 转义字符：如果传输的数据可能包含与帧头S相同的字符，需要考虑转义机制，但这在S-Record格式中不常见。

3.3 Flash擦除与编程的底层时序控制

这是引导加载器最“硬核”的部分，直接与Flash存储器的物理特性打交道。

Flash编程原理简述： Flash存储器通过向浮栅注入或释放电荷来改变晶体管的阈值电压，从而表示0或1。这个过程需要特定的高压（Vfp，编程电压）和精确的脉冲宽度。擦除是将一个扇区（或整个阵列）的所有位设置为1（释放电荷），而编程是将特定的位从1变为0（注入电荷）。编程只能将1变0，不能将0变1，因此编程前必须先擦除。
擦除流程（FErase子程序）：
- 准备：设置定时器预分频为/32，以获得较长的定时周期（用于100ms和1ms延时）。设置Flash控制寄存器FEECTL的LAT（锁存）和ERAS（擦除）位。
- 擦除脉冲：向Flash任意地址写入任意数据（std FlashStart）启动擦除序列。然后循环施加Vfp高压脉冲。每个脉冲周期为：施加Vfp 100ms (mS100)，移除Vfp 1ms (mS1)。最多重复MaxErasePulses（5）次。
- 验证与边际脉冲：每次擦除脉冲后，检查整个Flash区域（引导块除外）是否全为$FFFF（已擦除状态）。如果验证成功，则再施加与成功擦除脉冲次数相同数量的“边际脉冲”（Margin Pulses），以巩固擦除效果，提高数据保持力。如果达到最大脉冲数仍未擦除成功，则标记失败。
编程流程（ProgFBlock子程序）：
- 准备：设置定时器预分频为/1，以获得更精细的定时（用于22μs和11μs延时）。针对S-Record中的每一个数据字节进行操作。
- 编程脉冲：打开地址/数据锁存 (LAT)，将数据字节写入目标地址（movb 0,y,0,x）。然后循环施加编程脉冲。每个脉冲周期为：施加Vfp 22μs (us22)，移除Vfp 11μs (uS11)。
- 验证与边际脉冲：每次脉冲后，立即读取Flash中的数据与原始数据比较。如果匹配，则编程成功，随后施加与成功编程脉冲次数相同数量的边际脉冲。如果达到MaxProgPulses（50）仍未成功，则标记失败。
核心细节：定时器延时实现代码中没有使用低效的软件循环延时，而是利用CPU12的定时器输出比较功能实现精确延时。以22μs延时为例：
```
ldd #us22 ; us22 = ((EClock/10000)*22)/100 addd TCNT ; 当前计数器值 + 延时周期数 std TC0 ; 写入输出比较寄存器 bset TSCR,TEN ; 启动定时器 brclr TFLG1,$01,* ; 等待比较标志置位
```
关键计算：EClock是总线频率（8MHz）。定时器计数器TCNT在每个总线周期递增。当预分频为1时，一个计数周期是125ns。22μs需要的计数次数 = 22000ns / 125ns = 176 =$B0。这就是us22常数的由来。addd TCNT计算出了未来触发比较的时间点。这种方法不占用CPU，精度极高。
边际编程的重要性：这是保证Flash长期可靠性的关键工艺步骤，但很多自制Bootloader会忽略。在成功编程或擦除后，额外施加一系列相同宽度（或略短）的脉冲，可以让浮栅电荷分布更稳定，抵抗数据随时间流失（Data Retention Loss）和读操作干扰（Read Disturb）的能力更强。具体脉冲次数需要参考Flash存储器的数据手册。

4. 关键子程序与代码技巧剖析

4.1 栈帧管理与局部变量访问

前面提到了用org/set技巧定义局部变量偏移量。在函数中如何使用呢？以ProgFBlock为例：

ProgFBlock: equ * pshd ; 压入D寄存器，顺便在栈上分配2字节空间（为局部变量？这里有点疑问） ... ; 后续代码 clr ProgPulses,sp ; 访问局部变量 ProgPulses clr PMarginFlag,sp ; 访问局部变量 PMarginFlag

这里pshd主要目的是保存D寄存器，但同时也将栈指针SP减少了2字节。在这2字节的空间上方（更低地址处），就是之前通过ds定义的局部变量区域。通过ProgPulses, sp这样的索引寻址方式，可以精确访问。函数返回前，会用puld恢复D寄存器并回收栈空间。

更清晰的栈帧管理范例在FErase中：

FErase: equ * leas -3,sp ; 明确为3个局部变量分配栈空间 ... ; 使用 NumPulses,sp 等访问 leas 3,sp ; 函数返回前回收栈空间 rts

leas -3,sp直接将栈指针向下移动3字节，开辟出空间。这种方法比通过寄存器压栈来“顺便”分配空间更直观，意图更明确，是更推荐的实践。

4.2 十六进制字符转换与校验和计算

GetHexByte和CvtHex子程序负责将从串口接收的ASCII十六进制字符对（如"A" "F"）转换为一个字节的二进制值（$AF）。

转换逻辑(CvtHex)：
```
CvtHex: subb #'0' ; 减去'0'的ASCII码 cmpb #$09 ; 结果 <= 9? bls CvtHexRtn ; 是，则是数字'0'-'9'，转换完成 subb #$07 ; 否，则是字母'A'-'F'，再减7 CvtHexRtn: rts
```
原理：'0'到'9'的ASCII码是$30到$39，减去$30后得到$00到$09。'A'到'F'的ASCII码是$41到$46，减去$30得到$11到$16，再减去$07就得到$0A到$0F。这个算法简洁高效。
校验和验证：在GetSRecord中，校验和的计算是累加所有接收到的字节（包括长度、地址、数据）。S-Record格式的校验和是这些字节和的二进制补码（即0x100 - (sum & 0xFF)）。代码中的验证方法很巧妙：
```
inc CheckSum,sp ; 如果校验和正确，累加和+补码 = 0xFF，再加1就会溢出为0 ; ... 后续通过判断Z标志位来确认校验和是否正确
```
它没有显式计算补码并比较，而是利用了补码的特性：有效校验和字节与之前所有字节的和相加，结果应为0xFF。因此，inc操作后，结果应为0，零标志（Z）置位。

4.3 字符串输出与用户交互

OutStr子程序是一个经典的以空字符结尾的字符串输出函数。它通过PCR寻址获取字符串地址，循环发送每个字符直到遇到0。

OutStr: equ * ldab 1,x+ ; 取字符并递增指针 beq OutStrDone ; 遇到0则结束 jsr putchar,pcr ; 发送字符 bra OutStr ; 循环 OutStrDone: rts

引导加载器通过发送提示字符串"(E)rase or (P)rogram:"与用户进行简单的交互，根据接收到的字符决定执行擦除还是编程操作。这种交互虽然简单，但在调试和现场维护时非常有用。

5. 工程实践：从理解到实现

5.1 移植到其他CPU12衍生型号

这份代码是针对特定型号（如MC9S12系列）编写的，移植到其他CPU12内核芯片时，需要检查并修改以下几点：

存储器映射：FlashStart、RAMStart、RAMSize、StackTop这些常量必须根据目标芯片的数据手册重新定义。中断向量表的地址（$FFD0-$FFFF）和次级向量表的偏移量（-$800）也可能不同。
外设寄存器地址：串口（SCI）、定时器、Flash控制寄存器（FEECTL,FEELCK等）的地址需要更新。代码中用的是绝对地址（如PORTDLC: equ $00fe），必须一一核对。
时钟频率：EClock常量（8MHz）决定了所有定时器延时常数（mS100,us22等）。必须根据目标系统的实际总线频率重新计算这些常数。
Flash编程算法：不同厂商、不同系列的Flash模块，其编程/擦除的时序、命令序列、控制位定义可能有差异。必须严格参照目标芯片的Flash编程手册。脉冲宽度（22μs, 11μs, 100ms）和最大脉冲次数（50, 5）是典型值，但并非绝对，务必以数据手册为准。

5.2 调试与测试策略

开发此类底层引导加载器，调试往往比编写更耗时。

分段测试：
- 首先测试通信：屏蔽Flash操作，让引导加载器只接收S-Record并回显校验和，确保串口通信和协议解析正确。
- 模拟Flash操作：将Flash写操作 (movb 0,y,0,x) 改为向一个RAM缓冲区写入，并验证数据正确性。这样可以安全地测试编程状态机逻辑。
- 使用仿真器：如果有硬件仿真器（如NXP的USBMULTILINK），可以在不实际操作Flash的情况下，单步跟踪整个流程，观察寄存器、内存和I/O状态。
安全机制：
- 代码完整性校验：引导加载器自身在跳转到RAM前，可以计算一个CRC校验和，确保自身代码在复制过程中没有出错。
- 双重确认：在擦除或编程前，除了检查“Boot Pin”，还可以加入更复杂的握手协议（如等待特定字符序列），防止意外进入编程模式。
- 备份与恢复：对于关键系统，可以考虑在Flash中存储两个版本的应用程序，引导加载器能根据某种条件（如第一个镜像的CRC错误）选择启动备份镜像。
上位机软件：你需要一个能发送S-Record格式文件的上位机程序。许多IDE（如CodeWarrior）自带此功能，也可以使用开源的sb（串行Bootloader）工具，或者用Python、C#等语言自己编写一个简单的发送程序。

5.3 性能优化与空间权衡

这份代码追求清晰和通用性，在特定场景下可以优化：

代码大小：引导加载器代码本身需要占用Flash空间（本例中约767字节）。如果芯片Flash空间紧张，可以考虑以下精简：
- 移除交互提示字符串，采用无交互的自动模式。
- 简化错误处理，不输出详细错误信息。
- 使用更紧凑的循环和算法。
编程速度：串口波特率（9600）是主要瓶颈。在支持更高波特率且通信环境可靠的情况下，可以提升波特率。Flash编程脉冲时间（22μs）由硬件决定，无法优化，但可以通过流水线或多字节编程（如果Flash支持）来减少整体编程时间。不过，CPU12的Flash模块通常只支持字节或字编程。
RAM使用：代码复制到RAM执行需要占用RAM空间。要确保目标芯片的RAM足够容纳整个引导加载器代码。如果RAM不足，一个折中方案是：只将包含Flash写操作的临界代码段复制到RAM，其余部分仍在Flash中执行。但这需要精心设计，确保在Flash中执行的代码不会去访问正在被编程的Flash扇区。

6. 常见问题与故障排查实录

在实际实现和调试这个引导加载器的过程中，你几乎一定会遇到下面这些问题。我把它们和解决思路整理出来，希望能帮你节省大量时间。

6.1 程序计数器相对寻址相关

问题现象：代码在Flash中运行正常，但复制到RAM后，所有通过,pcr的跳转都飞到了错误地址。
排查思路：
1. 检查汇编器：确认你使用的汇编器（如ASM12、uASM等）是否支持,pcr语法。生成列表文件(.lst)，查看JMP [Reset-$800, pcr]这类指令生成的机器码。计算生成的偏移量是否正确。公式：偏移量 = (目标地址 - (指令地址 + 指令长度))的低16位。
2. 检查链接器脚本：如果你使用了链接器，确保链接器没有对这段代码进行意外的重定位。引导加载器代码在Flash中的地址（BootLoad）和在RAM中的复制目标地址（RAMStart）必须在链接脚本中明确定义，且保证PCR计算在两种情况下都有效。
3. 手动计算验证：如果怀疑汇编器，可以暂时用笔记中提供的备选语法[(Reset-$800) - (* + 4), pc]替换,pcr，看问题是否解决。这能帮你定位是否是汇编器支持问题。

6.2 Flash编程/擦除失败

问题现象：擦除后读取Flash不是全0xFF，或者编程后验证数据不匹配。
排查清单：
1. 电压与时钟：
  - Vfp电压：这是最关键的！用示波器测量Vfp引脚（如果引出），确保在编程/擦除脉冲期间，电压达到数据手册要求的值（通常是9V或12V）。CheckVfp子程序就是用来检测这个电压是否存在的。
  - 电源稳定性：整个系统的电源（特别是VDD）在高压脉冲期间必须稳定。大的电流毛刺可能导致内部电荷泵工作异常或逻辑复位。
  - 时钟频率：确认EClock常量与实际系统总线频率一致。错误的频率会导致定时器延时常数计算错误，从而使得编程/擦除脉冲宽度不对。
2. 时序问题：
  - 脉冲宽度：用示波器或逻辑分析仪抓取ENPE（编程电压使能）信号，测量其高电平时间是否精确为22μs（编程）或100ms（擦除）。检查定时器预分频器（TMSK2）设置和延时常数计算。
  - 等待时间：在ENPE拉低后，代码等待了11μs（编程）或1ms（擦除）才进行验证。这个等待时间也必须保证，让Flash单元状态稳定。
3. Flash保护：
  - 块保护：检查FEELCK（Flash锁存控制）寄存器是否已正确配置，确保要擦写区域没有被保护。代码中ldab #$01stab FEELCK是禁用对2K引导块的擦写，保护引导加载器自身。
  - 全局保护：有些芯片有全局保护位（如FPROT），需要通过特定的解锁序列才能解除。
4. 算法逻辑：
  - 边际脉冲：如果编程/擦除偶尔成功偶尔失败，可能是边际脉冲次数不够或电荷分布不稳定。可以尝试略微增加MaxProgPulses或MaxErasePulses，但不要超过数据手册规定的最大值，否则可能损坏Flash。
  - 验证时机：代码是在每个脉冲后立即验证。有些Flash需要一小段“恢复时间”后才能给出稳定的读取值。如果验证太早，可能读到的是中间状态。可以尝试在关闭ENPE后增加一个微秒级的延迟再读取验证。

6.3 串口通信不稳定

问题现象：上位机发送数据，但引导加载器接收不到，或接收到的数据错乱，校验和经常失败。
排查步骤：
1. 电气连接：检查TX、RX、GND三线连接是否正确、牢固。对于长距离通信，考虑是否需要RS-232电平转换或隔离。
2. 波特率：双方波特率必须严格一致。计算Baud9600常数：8000000/16/9600 = 52.083，取整为52 ($34)。8MHz时钟下，9600波特率会有约0.16%的误差，通常可以接受。如果时钟不是8MHz，必须重新计算。
3. 流控与缓冲：代码中没有硬件流控。如果上位机发送过快，可能导致数据丢失。确保上位机在发送下一条S-Record前，已收到引导加载器发送的步调字符(*)。
4. 中断干扰：引导加载器运行期间，是否有可能被其他中断打断？在关键的通信和Flash操作代码段，可以考虑暂时关闭全局中断（cli），但要注意不能影响必要的定时器中断（如果用了的话）。

6.4 从引导加载器跳转到用户程序失败

问题现象：引导加载器工作正常，编程也成功，但最后无法跳转到用户程序执行，或跳转后程序跑飞。
可能原因与解决：
1. 向量表未正确设置：用户程序的编译/链接配置必须正确。它的中断向量表应该从次级向量表的位置（本例中是$F7D0开始）开始链接，而不是默认的$FFD0。链接器脚本需要相应修改。
2. 用户程序初始化冲突：用户程序的开头可能进行了与引导加载器冲突的硬件初始化（例如，重新配置了看门狗、时钟、端口等）。确保引导加载器已经初始化的硬件，用户程序要么不再重复初始化，要么以兼容的方式重新配置。
3. 栈指针未重置：引导加载器使用了栈。跳转到用户程序前，最稳妥的做法是重新初始化栈指针（lds #用户程序定义的栈顶）。用户程序不应该依赖引导加载器留下的栈状态。
4. 跳转指令：引导加载器最后是通过JMP [Reset-$800, pcr]跳转的。这依赖于次级向量表中Reset位置存放的用户程序入口地址。用仿真器或调试器检查$F7FE（Reset-$800）开始的两个字节，是否确实指向用户程序的_Startup或main函数地址。

最后，分享一个我个人的深刻体会：编写引导加载器，是理解一个微控制器体系结构最深刻的方式之一。它强迫你去关注内存映射、中断机制、最底层的I/O控制和精确的时序。这份二十多年前的代码，其设计思想在今天依然熠熠生辉。当你逐行推敲，让每一段汇编指令都在脑海中转换成具体的硬件动作时，你对这个系统的掌控力会达到一个新的层次。调试过程固然痛苦，但每次解决一个底层问题，那种“直击本质”的成就感，是高层应用开发难以比拟的。建议你在理解这份代码的基础上，亲手在仿真器或开发板上实现一遍，哪怕只是修改提示字符串、改变波特率，这个过程中遇到的挑战和收获，会让你对嵌入式系统的认识更加立体和牢固。