MC68332 CPU32Bug 调试监控程序实战指南：从架构解析到系统调用

1. 项目概述与核心价值

如果你在九十年代或二十一世纪初接触过基于Motorola（后来的Freescale，现在的NXP）MC68332微控制器的嵌入式系统开发，那么CPU32Bug这个名字一定不会陌生。它不是一款独立的软件，而是固化在评估板（如M68332EVK）引导ROM中的调试监控程序，是那个时代工程师与这块32位MCU硬件“对话”的唯一窗口。在集成开发环境（IDE）和JTAG仿真器尚未普及或价格高昂的年代，这样一个通过串口终端操作的命令行调试器，是进行底层硬件验证、驱动调试乃至小型应用开发的基石。它的核心价值在于，将复杂的机器码执行、内存状态、寄存器内容这些“黑盒”信息，以一种相对直观、可交互的方式呈现给开发者。

CPU32Bug的本质是一个常驻在目标系统ROM中的微型操作系统内核。它接管了MCU的部分关键资源（如特定中断向量、片选信号），并提供了一个命令解释器。开发者通过串口终端（通常是9600 8N1）连接到目标板，在CPU32Bug>提示符下输入命令，就能直接读写内存、查看修改寄存器、设置断点、单步执行程序，甚至调用内置的丰富系统服务（如串口输入输出、定时器、字符串处理）。其最精妙的设计之一，是通过TRAP #15这条CPU指令，为用户程序开放了这些监控程序的内核能力，使得用户程序无需自己实现复杂的底层驱动，就能完成基本的I/O和系统功能，极大地提升了开发效率，降低了入门门槛。

本文将深入解析CPU32Bug的操作指南与系统调用机制。我不会仅仅复述用户手册的命令列表，而是结合我当年在工控和汽车电子项目中使用MC68332的实际经验，拆解其设计思想、实操中的关键细节、那些手册里不会写的“坑”，以及如何高效利用系统调用构建稳健的应用程序。无论你是正在维护一个历史遗产系统，还是对早期嵌入式调试技术感兴趣，这篇文章都将提供从原理到实战的完整参考。

2. CPU32Bug架构与资源占用剖析

在开始敲命令之前，必须彻底理解CPU32Bug对MC68332系统资源的占用情况。这是一个监控程序能稳定运行的前提，也直接决定了用户程序能安全使用的边界。盲目开发，很可能导致监控程序崩溃或系统行为异常。

2.1 核心工作模式：调试器与诊断器

CPU32Bug有两种基本操作模式，也称为目录（Directory）：

1. 调试器模式：提示符为CPU32Bug>。这是主要工作模式，提供了程序加载、调试、执行和系统调用的全部功能。
2. 诊断模式：提示符为CPU32BugDiag>。此模式包含一系列对MCU本身及板载内存的硬件自检（Self-Test）程序，用于在生产或维修时验证硬件基础功能。

两种模式通过SD（Switch Directories）命令切换。对于绝大多数软件开发工作，我们只需要停留在调试器模式。诊断模式更像一个独立的、面向硬件的工具集。

2.2 关键硬件资源占用与冲突规避

这是最容易出问题的地方。CPU32Bug并非一个“透明”的调试代理，它需要实实在在地占用一部分系统资源才能工作。

2.2.1 片选（Chip Select）信号占用

MC68332的片选信号用于连接外部存储器或外设。CPU32Bug所在的BCC（单板计算机）和EVK（评估套件）硬件已经使用了一部分片选来连接自身的RAM、EPROM和外围芯片。

核心注意事项：用户程序绝对不能重新配置或使用已被BCC/EVK硬件占用的片选信号。否则，轻则监控程序无法访问自身代码或数据而崩溃，重则导致硬件总线冲突。

手册中通过几个表格详细列出了不同版本BCC的片选分配。例如，对于常见的Rev B板：

• CSBOOT：用于映射CPU32Bug自身的EPROM。
• CS0,CS1,CS2：用于BCC板载RAM的读写使能。
• CS4：被ABORT按钮占用（用于产生中断）。
• CS5：用于可选的数学协处理器MC68881/882。
• CS6,CS7：用于平台板（PFB）上的ROM/EPROM插座。
• CS8,CS9,CS10：用于平台板（PFB）上的RAM插座。

实操心得：

• 规划内存映射的第一步：在编写用户程序链接脚本或设置内存控制器前，务必对照你手头硬件版本的片选分配表，将已占用的地址空间排除在用户可用区域之外。
• “释放”片选的条件：手册提到，如果BCC没有安装在PFB上，或者PFB上的某些插座空置，对应的片选可能可用。但这需要仔细核对电路图和跳线设置，不建议初学者动态修改。
• ABORT按钮的机制：CS4（Rev B）或CS8（Rev A）虽然被ABORT按钮关联，但该引脚实际用于解码中断应答周期，而非直接作为片选。这意味着你不能将该引脚当作普通GPIO或片选来复用。特别要注意，不能向端口F的引脚分配寄存器（PFPAR）的bit7写入0，否则会禁用ABORT开关功能，让你在程序跑飞时失去一个重要的物理恢复手段。

2.2.2 中断与异常向量占用

CPU32Bug接管了若干关键的中断和异常向量，以实现其调试功能：

• 非法指令异常（向量号4，偏移$10）：用于实现软件断点（GO,GN,GT命令）。当你在某个地址设置断点，监控程序实际上会将该地址的指令临时替换为一条非法指令（如ILLEGAL）。当程序执行到此处触发非法指令异常，CPU就会跳转到监控程序的处理程序，从而暂停用户程序并恢复现场。
• 跟踪异常（向量号9，偏移$24）：用于实现单步跟踪（T,TC,TT命令）。当跟踪标志位被设置，每条指令执行后都会触发此异常，使监控程序能够接管控制权，实现单步。
• Level 7中断（向量号31，偏移$7C）：映射到硬件ABORT按钮。这是最高优先级的中断，用于强行夺回CPU控制权。
• TRAP #15异常（向量号47，偏移$BC）：这是系统调用的入口。用户程序通过执行TRAP #15指令，并按照约定设置参数，即可调用监控程序提供的各种服务。
• 用户定义向量（向量号66，偏移$108）：用于特定的定时器相关TRAP #15调用。

避坑指南：

• 绝对不要动这些向量：用户程序严禁修改以上向量地址处的内容。如果你需要安装自己的中断服务程序（ISR），必须避开这些已被占用的向量号。MC68332的向量表有256个条目，有充足的空间。
• 断点失效的元凶：如果你发现设置的断点不起作用，首先检查你的程序是否意外改写了$10（或你所用CPU32Bug版本对应的非法指令向量）地址的内容。同样，单步跟踪失效也可能是$24地址被破坏。

2.2.3 其他关键资源

• 软件看门狗定时器：CPU32Bug在启动时通过一次性写入寄存器（SYPCR）禁用了看门狗。这意味着用户程序无法再启用或使用片内看门狗，除非你修改CPU32Bug的源码并重新烧录EPROM（通过修改SYPCR_OR和SYPCR_AND参数）。对于需要高可靠性的应用，这是一个重要限制，可能需要外接看门狗芯片。
• 模块映射（MM）位：CPU32Bug将MC68332的内部寄存器块固定映射到高地址$FFF000。这也是通过一次性写入MCR寄存器实现的。用户程序无法将其移回低地址$7FF000，除非同样修改监控程序的定制参数。这会影响你对内存空间的规划。
• 系统时钟与SCI波特率：CPU32Bug的串口（SCI）波特率是基于预设的系统时钟频率计算的。如果你在用户程序中改变了MCU的主频（通过修改SYNCR或使用外部时钟），必须同步更新CPU32Bug参数区中的FCRYSTAL或FEXTAL值，否则串口通信将完全乱码，导致你与监控程序失联。修改这些参数同样需要重编监控程序。

3. 核心调试命令实战详解

理解了CPU32Bug的“地盘”后，我们就可以安全地使用它提供的强大工具了。其命令集可以大致分为内存/寄存器操作、断点控制、程序执行控制几大类。

3.1 内存与寄存器操作命令

这些命令是你观察和修改系统状态的“眼睛”和“手”。

• MD (Memory Display)：显示内存内容。最常用的命令之一。

  CPU32Bug>MD 4000 00004000 4E56 0000 48E7 3030 2F3C 0000 000A 4EAD NV..H.00/<....N. 00004010 0000 4E5E 4E75 0000 0000 0000 0000 0000 ..N^Nu..........

  技巧：结合;DI参数可以直接反汇编。

  CPU32Bug>MD 4000;DI 00004000 4E560000 LINK A6,#$0000 00004004 48E73030 MOVEM.L D3/D4/A2/A3,-(A7)

  你可以用.或+指定下一个地址，用-指定上一个地址，快速浏览。

• MM (Memory Modify)：交互式修改内存。输入地址后，它会显示当前值并等待你输入新值。

  CPU32Bug>MM 4000 00004000 4E56? 1234 <CR> 00004002 0000? <CR> (直接回车表示不修改，跳到下一地址)

  重要提示：修改代码区时要格外小心，错误的指令码可能导致程序跑飞。最好在数据区或未使用的RAM区域练习。

• BF (Block Fill)、BM (Block Move)、BS (Block Search)、BV (Block Verify)：这些是批量内存操作命令，在初始化数据区、复制代码或数据、查找特定模式时非常高效。

  CPU32Bug>BF 8000 80FF 00 ; 将地址$8000到$80FF的区域全部填充为0 CPU32Bug>BM 4000 40FF 9000 ; 将$4000-$40FF的内容移动到$9000开始的位置 CPU32Bug>BS 8000 80FF 55AA ; 在$8000-$80FF中搜索数据模式$55AA

• RD (Register Display)和RM (Register Modify)：查看和修改CPU内部寄存器。

  CPU32Bug>RD PC =00004000 SR=2700=TR:OFF_S_7_..... VBR=00000000 D0=00000000 D1=00000000 ... A7=0000FF00 CPU32Bug>RM D0 D0=00000000? 12345678 <CR>

  实操心得：在单步调试（T命令）或遇到断点后，第一时间用RD查看寄存器状态，尤其是程序计数器PC、状态寄存器SR和栈指针A7，是分析程序流和异常的关键。

3.2 断点与程序执行控制

断点是调试的核心。CPU32Bug支持硬件断点（通过非法指令异常实现）。

• BR (Breakpoint Set)/NOBR (Breakpoint Clear)：

  CPU32Bug>BR 4050 ; 在地址$4050设置断点 BREAKPOINTS 00004050 CPU32Bug>NOBR 4050 ; 清除该断点 CPU32Bug>NOBR ALL ; 清除所有断点

  限制与原理：CPU32Bug的断点数量有限（具体数量取决于版本，通常几个）。它通过临时用ILLEGAL指令替换目标地址的原指令来实现。因此，断点不能设置在ROM或受保护的存储区。当命中断点后，监控程序会恢复原指令。

• GO：从指定地址开始执行程序。

  CPU32Bug>G 4000

  如果4000处设置了断点，执行到那里会暂停。如果没有断点，程序将一直运行，直到发生异常、执行到包含TRAP #15调用.RETURN的代码，或者你按下ABORT按钮。

• GN (Go to Next)和GT (Go to Temporary)：这两个是“运行到下一指令”和“运行到当前指令”的临时断点命令，在跳过循环或复杂调用时比单步更高效。

  CPU32Bug>GN ; 从当前PC执行，在下一条指令处暂停 CPU32Bug>GT ; 在当前PC处设置临时断点并执行，立即暂停（相当于单步一次）

• T (Trace)：单步执行一条指令。这是最精细的调试手段。

  CPU32Bug>T 1 ; 执行一条指令 CPU32Bug>T 10 ; 执行十条指令

  注意事项：单步跟踪依赖于跟踪异常。确保你的程序没有破坏该异常向量（$24）。对于跳转（JMP, BRA）或子程序调用（JSR, BSR）指令，T命令会跟踪进入目标地址。

• TT (Trace to Temporary)：结合了跟踪和临时断点，一直单步执行直到到达指定地址。

  CPU32Bug>TT 4080 ; 从当前地址开始单步，直到PC等于$4080

3.3 诊断命令浅析

在CPU32BugDiag>目录下，你可以运行一系列硬件自检。虽然软件开发中不常用，但在排查硬件问题时是救命稻草。

• ST (Self Test)：执行全套或指定的自检。例如，ST CPU测试CPU核心，ST MEM测试内存。
• LE/SE (Loop-on-Error / Stop-on-Error)：设置测试出错时的行为是循环还是停止。
• DE/ZE (Display/Zero Error counters)：查看或清零错误计数器。

使用场景：当你新焊了一块板子，或者系统出现完全无法解释的崩溃时，运行内存测试（ST MEM）和总线错误测试（ST BERR）可以快速定位是内存芯片损坏、虚焊还是总线时序问题。

4. TRAP #15系统调用深度解析与应用

这是CPU32Bug最强大的功能之一。它允许你的用户程序直接调用监控程序已经实现好的底层服务，省去了自己编写复杂驱动代码的麻烦。

4.1 调用机制与参数传递规范

所有系统调用都通过TRAP #15指令触发。调用号（即你要调用哪个函数）和参数通过CPU的数据寄存器（D0-D7）和堆栈来传递。这是一种典型的Motorola 68k系列API约定。

通用调用步骤：

1. 功能号放入D0：将所需系统调用的功能编号（一个字节）加载到数据寄存器D0的低8位（D0.B）。
2. 参数准备：根据调用要求，将其他参数放入指定的数据寄存器或压入堆栈（A7）。
3. 执行陷阱指令：执行TRAP #15。
4. 处理结果：监控程序接管，执行相应功能，结果通常通过寄存器（如D0）或内存返回。
5. 返回用户程序：监控程序执行RTE指令，返回到TRAP #15之后的用户代码。

4.2 常用系统调用分类与示例

手册列出了二十多个系统调用，我将其分为几大类，并挑几个最常用的详细说明。

4.2.1 字符与字符串I/O

这是最常用的一组调用，用于实现最基本的串口输入输出。

• .OUTCHR (输出字符)：

  • 功能号：$00
  • 参数：要输出的ASCII字符放在D1.B中。
  • 示例：在终端上输出字符'A'。

    MOVE.B #$41, D1 ; 'A'的ASCII码 MOVE.B #$00, D0 ; 功能号 .OUTCHR TRAP #15

• .OUTSTR (输出字符串，指针/指针格式)：

  • 功能号：$02
  • 参数：A0指向字符串起始地址，A1指向字符串结束地址（最后一个字符的下一个字节）。
  • 示例：输出以NULL结尾的字符串。

    LEA MY_STRING, A0 ; A0指向字符串开头 MOVE.L A0, A1 FIND_END: TST.B (A1)+ ; 查找结束符 BNE FIND_END SUBQ.L #1, A1 ; A1指向结束符 MOVE.B #$02, D0 ; 功能号 .OUTSTR TRAP #15 MY_STRING: DC.B 'Hello, CPU32Bug!', 0

• **.INCHR (输入字符)**��

  • 功能号：$01
  • 参数：无。
  • 返回：输入的字符在D1.B中。这是一个阻塞调用，程序会一直等待直到用户从串口输入一个字符。
  • 示例：实现一个简单的“按任意键继续”。

    MOVE.B #$01, D0 ; 功能号 .INCHR TRAP #15 ; 此时D1.B中为输入的字符

• .INSTAT (输入状态检查)：

  • 功能号：$03
  • 参数：无。
  • 返回：如果输入缓冲区有字符，则零标志位（Z）被清除；否则置位。这是一个非阻塞调用。
  • 示例：实现非阻塞键盘检测。

    CHECK_KEY: MOVE.B #$03, D0 ; 功能号 .INSTAT TRAP #15 BEQ NO_KEY ; Z=1，无按键 ; 有按键，可以调用.INCHR读取 MOVE.B #$01, D0 TRAP #15 ; ... 处理字符 ... NO_KEY: ; ... 做其他事情 ...

4.2.2 定时器服务

MC68332内置了周期中断定时器（PIT），CPU32Bug对其进行了封装，提供了简单的延时和计时功能。

• .TM_INI (定时器初始化)：

  • 功能号：$10
  • 参数：D1.L包含PIT模块寄存器的初始化值（需根据时钟频率计算）。
  • 说明：通常只需要在程序开始时调用一次。注意：这会占用PIT资源，用户程序不能再直接操作PIT相关寄存器。

• .DELAY (定时延迟)：

  • 功能号：$13
  • 参数：D1.W包含延迟的毫秒数（最大值65535，约65秒）。
  • 示例：延迟500毫秒。

    MOVE.W #500, D1 ; 延迟500ms MOVE.B #$13, D0 ; 功能号 .DELAY TRAP #15

  • 重要限制：.DELAY是一个忙等待循环，在延迟期间CPU被完全占用，无法处理其他任务。它仅适用于简单的时序控制或调试，不适用于需要并发性的应用。

4.2.3 程序控制与工具函数

• .RETURN (返回监控程序)：

  • 功能号：$0F
  • 参数：无。
  • 作用：这是用户程序主动结束运行并返回到CPU32Bug>提示符的标准方式。相当于程序的main()函数返回。
  • 示例：程序结束。

    MAIN_END: MOVE.B #$0F, D0 ; 功能号 .RETURN TRAP #15 ; 执行后控制权交还CPU32Bug

• .BINDEC (二进制转BCD)、.MULU32 (32位无符号乘)、.DIVU32 (32位无符号除)：

  • 这些是实用的算术和转换函数，在需要显示十进制数或进行大数运算时很有用，避免了用户自己实现这些算法。

4.3 系统调用实战：编写一个交互式程序

让我们结合以上知识，写一个简单的程序：它等待用户输入一个字符，如果是‘1’，则点亮一个LED（假设连接在某个GPIO上，这里用串口输出模拟）；如果是‘2’，则报告当前程序运行了多久（用简单循环模拟）；如果是‘q’，则退出。

ORG $4000 ; 程序加载地址 START: LEA PROMPT_MSG, A0 LEA PROMPT_END, A1 MOVE.B #$02, D0 ; .OUTSTR TRAP #15 GET_CHAR: MOVE.B #$01, D0 ; .INCHR (阻塞等待) TRAP #15 CMPI.B #'1', D1 BEQ DO_LED CMPI.B #'2', D1 BEQ DO_TIMER CMPI.B #'q', D1 BEQ QUIT BRA GET_CHAR ; 无效输入，重新等待 DO_LED: LEA LED_ON_MSG, A0 LEA LED_ON_END, A1 MOVE.B #$02, D0 TRAP #15 BRA START DO_TIMER: ; 模拟一个耗时操作 MOVE.L #100000, D2 DELAY_LOOP: SUBQ.L #1, D2 BNE DELAY_LOOP LEA TIMER_MSG, A0 LEA TIMER_END, A1 MOVE.B #$02, D0 TRAP #15 BRA START QUIT: LEA BYE_MSG, A0 LEA BYE_END, A1 MOVE.B #$02, D0 TRAP #15 MOVE.B #$0F, D0 ; .RETURN TRAP #15 ; 数据区 PROMPT_MSG: DC.B 'Enter 1(LED), 2(Timer), q(Quit): ', 0 PROMPT_END: LED_ON_MSG: DC.B 13, 10, 'LED ON!', 13, 10, 0 ; 13,10是回车换行 LED_ON_END: TIMER_MSG: DC.B 13, 10, 'Timer task done.', 13, 10, 0 TIMER_END: BYE_MSG: DC.B 13, 10, 'Goodbye!', 13, 10, 0 BYE_END: END START

如何加载和运行这个程序？

1. 将上述汇编代码用交叉汇编器（如vasm或当年的Motorola ASM32）编译成Motorola S-record格式（.S19或.S28文件）。
2. 在CPU32Bug中，使用LO命令通过串口下载该S-record文件到内存（例如到$4000）。
3. 使用G 4000命令开始执行。

5. 汇编/反汇编器使用与程序调试流程

CPU32Bug内置了一个单行汇编/反汇编器，虽然功能不如完整的交叉开发环境强大，但对于快速修改代码、测试小段程序或进行紧急修补来说，是极其便利的。

5.1 使用MM命令进行交互式汇编

MM命令配合;DI参数，就进入了交互式汇编模式。

CPU32Bug>MM 5000;DI 00005000 4E560000? MOVE.L #$501C,$78 <CR> ; 输入新指令 00005008 00000000? MOVE.L #$061E0120,$FFFA22 <CR> 00005012 00000000? LPSTOP #$2500 <CR> 00005018 00000000? BRA.W $5012 <CR> 0000501C 00000000? . <CR> ; 输入一个点(.)然后回车，退出汇编模式

• 输入指令助记符和操作数（用Motorola 68k汇编语法）。
• 输入.并回车，退出汇编模式。
• 直接回车，则查看下一条指令的地址并等待输入（可用于浏览或跳过）。

5.2 一个完整的调试会话实例

假设我们下载了上一节的示例程序到$4000，现在来调试它。

1. 查看代码：

   CPU32Bug>MD 4000;DI

2. 设置断点：我们想在用户输入字符后，判断分支的地方停下来。

   CPU32Bug>MD 4010;DI ; 先找到CMPI.B指令的地址，假设是$4010 CPU32Bug>BR 4010

3. 运行程序：

   CPU32Bug>G 4000

   程序会运行，打印提示符，然后等待输入。你在终端输入一个字符（如‘1’）后，程序执行到$4010的断点处停止。
4. 检查状态：

   CPU32Bug>RD

   查看PC是否停在$4010，D1.B里是否是你输入的字符$31（‘1’的ASCII）。
5. 单步执行：

   CPU32Bug>T 1 ; 执行CMPI.B CPU32Bug>T 1 ; 执行BEQ指令，应该会跳转到DO_LED标签处

   观察PC的变化，确认程序流是否正确。
6. 修改内存（热修补）：假设我们发现DO_LED分支里输出的消息地址错了。

   CPU32Bug>MD 4080 ; 查看当前消息字符串 CPU32Bug>MM 4080 'LED is ON now!'0D0A00 ; 直接修改内存中的字符串，0D0A是回车换行，00是结束符

7. 继续执行：

   CPU32Bug>G ; 从当前PC继续执行

   现在输出的消息应该已经变了。

5.3 下载流程详解（以PC通过串口为例）

虽然手册提到了Kermit、PROCOMM等古老工具，但今天我们可以用更通用的方法，如使用minicom、screen或Python脚本。

核心原理：在CPU32Bug>下输入LO命令，监控程序会等待接收S-record格式的数据流。任何能通过串口发送文本文件的终端程序都可以。

使用screen命令（Linux/macOS）：

1. 连接串口转USB线，确定设备名（如/dev/ttyUSB0）。
2. 设置波特率：stty -F /dev/ttyUSB0 9600 cs8 -cstopb -parenb
3. 启动screen连接：screen /dev/ttyUSB0 9600
4. 给目标板上电，看到CPU32Bug>提示符。
5. 输入LO并回车。
6. 在screen会话中，按Ctrl+A，然后按:，进入命令模式。
7. 输入exec !! sx -k your_program.s19（sx是lrzsz包中的发送命令，-k表示使用1K数据包）。或者，如果screen版本支持，直接按Ctrl+A，然后:，再输入exec !! cat your_program.s19。
8. 文件传输开始。传输完成后，CPU32Bug会响铃（beep）并闪烁光标。此时按两次回车键返回提示符。

关键点：

• 确保终端程序配置为9600波特，8数据位，1停止位，无奇偶校验，无硬件流控（或仅使用XON/XOFF软件流控）。
• LO命令期望的是纯S-record文本流，不要有任何额外的终端转义字符或提示信息。
• 传输期间，屏幕上可能看不到字符，这是正常的。传输成功以响铃和光标闪烁为标志。

6. 常见问题排查与实战经验汇总

十几年下来，我在使用CPU32Bug时踩过不少坑，这里总结一下，希望能帮你节省大量调试时间。

6.1 系统调用相关

1. 问题：调用.OUTSTR或.OUTCHR后，终端没有任何输出。

   • 排查：
     • 首先检查串口线连接和终端软件设置（9600 8N1）。
     • 确保调用前正确设置了功能号（D0.B）和参数（A0, A1等）。用RD命令在调用TRAP #15前检查寄存器值。
     • 最容易被忽略的一点：CPU32Bug的I/O默认使用特定的SCI端口。如果你的用户程序在初始化阶段重新配置了SCI模块（例如改变了波特率、数据格式），那么系统调用将无法工作，因为监控程序期望的硬件状态被改变了。解决方案是：要么避免在用户程序中初始化SCI，要么在调用系统调用前，将SCI寄存器恢复到CPU32Bug期望的状态。

2. 问题：使用.DELAY函数后，系统似乎“卡死”，连ABORT按钮都不响应。

   • 原因：.DELAY是忙等待循环，并且可能禁用了中断。在此期间，Level 7中断（ABORT）可能无法被及时响应。
   • 解决：对于需要长时间延迟又不希望阻塞系统的情况，应该使用.TM_INI初始化定时器，然后利用MC68332的PIT中断来自行实现一个非阻塞的延时或定时器服务，而不是依赖.DELAY。

3. 问题：程序调用.RETURN后没有回到CPU32Bug>提示符，而是跑飞。

   • 排查：
     • 检查堆栈指针A7是否在调用TRAP #15前已被破坏。.RETURN以及所有系统调用都依赖堆栈来保存返回地址。
     • 确保没有在中断服务程序（ISR）中调用.RETURN。.RETURN设计用于主程序退出，在ISR中使用会导致上下文错误。

6.2 调试命令相关

1. 问题：断点（BR）设置后不起作用，程序直接运行过去。

   • 排查：
     • 确认断点地址在RAM中，且是有效的指令起始地址。不能在ROM或未映射的内存区域设断点。
     • 检查非法指令异常向量（$10）是否被你的程序覆盖。用MD 10查看。
     • CPU32Bug的断点数量有限，如果设置过多，新的断点可能无法生效。用BR命令不带参数查看当前所有断点列表。

2. 问题：单步跟踪（T）命令无效，程序连续执行。

   • 排查：检查跟踪异常向量（$24）是否被覆盖。同时确认状态寄存器SR中的跟踪位（T）在监控程序中是正确管理的，通常用户不应直接修改SR的T位。

3. 问题：GO命令执行后，终端失去响应，ABORT按钮也无效。

   • 排查：
     • 程序可能进入了一个死循环，并且禁用了所有中断（包括Level 7）。ABORT按钮依赖于Level 7中断。
     • 程序可能错误地修改了系统关键寄存器（如中断控制器），导致中断无法产生。
     • 终极手段：硬件复位。这是为什么在开发阶段，保留一个硬件复位按钮或循环上电开关如此重要。

6.3 资源冲突与系统配置

1. 问题：用户程序运行正常，但一旦涉及特定的内存地址访问就发生总线错误或数据错误。

   • 排查：第一怀疑对象就是片选冲突。用MD命令查看你认为可用的内存区域，如果读出的数据是随机或固定的$FFFF/$0000，很可能该区域没有被正确的片选使能。仔细对照硬件手册的片选分配表，检查你的内存控制器初始化代码，确保没有使能已被BCC占用的片选信号。

2. 问题：改变系统时钟频率后，与CPU32Bug的串口通信全部乱码。

   • 解决：如前所述，必须修改CPU32Bug参数区的时钟频率值并重新烧录监控程序EPROM。或者，在你的用户程序初始化代码中，不要在需要与监控程序交互的阶段改变时钟频率。可以在程序完全启动、不再需要监控程序I/O服务后再切换时钟。

6.4 程序设计与开发建议

1. 内存规划图：在项目开始前，画一张详细的内存映射图，明确标出：

   • CPU32Bug占用的区域（ROM， 异常向量表）。
   • BCC/EVK硬件占用的区域（RAM， 外设）。
   • 用户程序可用区域（代码区， 数据区， 堆栈区）。
   • 将这份图放在你的汇编器或链接器配置文件中。

2. 系统调用封装：为常用的系统调用编写宏或子程序库。例如，封装一个PrintString子程序，内部处理字符串指针计算和.OUTSTR调用，让主程序代码更清晰。

3. 善用ABORT按钮：在你的硬件设计上，确保ABORT按钮易于触及。它是从“跑飞”的用户程序中恢复控制的最可靠物理手段。在软件上，避免长时间关闭中断。

4. 备份与比较：在修改关键内存或寄存器前，先用MD命令将原始内容记录下来。修改后，可以再次MD进行比较，确认修改正确无误。

5. 理解“监控程序”的本质：CPU32Bug不是一个仿真器，它就是一个运行在目标板上的特殊程序。它和你写的用户程序共享同一个CPU、内存和硬件资源。因此，任何对共享资源的修改都必须谨慎，要时刻清楚“谁在管理什么”。这种思维方式对于所有带监控程序的嵌入式开发都至关重要。