目标板还没到位，算法、协议处理和状态机代码也可以先开展调试。Green Hills MULTI支持连接指令集仿真器，在开发电脑上执行目标处理器程序。不过，能运行程序与能完整模拟一块电路板是两回事。准备仿真工程时，要确认处理器支持范围，还要检查代码是否依赖外设、板级初始化和操作系统环境，否则程序可能在进入业务函数之前就停住。

　　一、Green Hills MULTI没有目标板能调试吗

　　可以，前提是安装环境中具有适用的仿真器及相应使用条件。MULTI是调试入口，实际执行程序的是所连接的仿真目标，不能仅凭电脑上装有MULTI就判断工程一定能运行。

　　1、先确认目标处理器与仿真环境

　　MULTI支持指令集仿真，也可以连接受支持的第三方虚拟平台。不同处理器、软件版本和安装包提供的连接类型不完全相同，应按当前环境检查，不能照搬其他架构的配置。

　　①打开工程，在【Project Manager】中核对编译器使用的处理器类型、指令集、字节序及浮点配置。

　　②启动调试器，选择【Target】→【Connect】，打开【Connection Chooser】。

　　③检查连接列表，选择与程序匹配的【Simulator】连接；需要建立配置时，在【Connection Editor】中设置对应仿真目标。

　　④核对仿真器组件和授权状态，保存连接配置，再点击【Connect】。

　　2、用不依赖外设的小程序验证连接

　　①准备包含【main】的测试程序，加入整数计算、数组处理或函数调用，暂不调用板级驱动。

　　②编译并加载带调试信息的【可执行文件】，在【main】入口及计算结果所在行设置断点。

　　③运行到断点后执行单步操作，在【Data Explorer】或变量查看区域检查输入与结果。

　　④修改一组测试输入，重新运行，核对函数返回值与预期值。

　　这一步用于区分连接问题和工程问题。简单程序能够运行，说明基本执行链路已经建立；原工程仍然停住时，就可以继续检查启动代码、链接地址和硬件依赖。直接加载整套板级工程，往往会把这些问题混在一起。

　　二、Green Hills MULTI仿真运行与实机运行有什么区别

　　两种环境都可以使用断点、单步、调用栈和内存查看等调试功能，但程序接触到的运行资源不同。判断某项测试能否放在仿真环境中，要看它依赖什么。

　　1、仿真执行指令，实机连接真实硬件

　　指令集仿真器可以模拟受支持处理器的指令执行，却不一定包含芯片上的全部外设。UART、CAN、定时器、DMA等资源是否可用，要查看具体模型，不能把能够访问某个地址理解为已经模拟了对应设备。

　　①在源代码中找到【寄存器访问】、【外设初始化】和【等待状态位】的位置。

　　②给相关函数设置【断点】，单步检查程序是否停在等待循环或异常处理入口。

　　③对尚无模型支持的设备访问，通过测试接口或【桩函数】提供输入，单独验证上层处理逻辑。

　　④将需要真实设备响应的测试项记录下来，留到目标板上执行。

　　2、仿真时间不能直接当作实机耗时

　　①测试算法时固定【输入数据】和【编译选项】，记录仿真环境采用的处理器模型。

　　②查看【Profiler】等工具的结果时，核对统计单位和采集方式，区分指令统计、模型时间与电脑上的等待时间。

　　③对中断响应、任务周期和通信超时，在目标板上重新测量，记录处理器时钟及运行条件。

　　仿真运行速度会受到电脑性能和模型实现影响。即使某个仿真器提供周期信息，也要确认它是否建模了缓存、流水线及存储器等待。缺少这些条件时，可以借助统计结果寻找可疑代码，但不能据此保证实机满足实时要求。

　　3、仿真可重复输入，实机还要承受现场变化

　　①在仿真测试中准备【正常输入】、【边界输入】和【错误输入】，保存各组预期结果。

　　②对依赖设备返回值的函数，设置不同【测试返回值】，检查成功、失败和超时后的处理分支。

　　③到实机阶段，恢复真实【驱动接口】，测试设备断开、异常返回及连续运行等情况。

　　④对仿真与实机结果不同的位置设置【断点】，比较调用参数、内存内容和状态变化。

　　仿真便于重复同一组条件，适合追查计算和控制流程。实机还包含真实中断、总线竞争及设备响应，错误出现的时机可能变化。另外，断点停机会干扰部分实时行为，不能只在反复单步的状态下评价系统运行情况。

　　三、Green Hills MULTI从仿真转到目标板时如何检查

　　仿真与实机可以共用业务代码，但启动、内存布局和设备接口可能需要分别配置。迁移时应保留已经通过的测试数据，减少环境切换带来的干扰。

　　1、分别保存仿真和实机工程配置

　　①为工程建立独立的【仿真构建配置】与【实机构建配置】，分别设置输出位置。

　　②检查两套配置中的【启动代码】、【链接脚本】、运行库及预处理宏。

　　③在仿真配置中使用适合模型的内存布局和输入输出支持，在实机配置中恢复板级初始化与真实驱动。

　　④在【Connection Chooser】中分别保存仿真连接和目标板连接，核对当前选中的连接名称。

　　业务代码在仿真中通过，并不表示同一个可执行文件可以原样下载到板上。反过来，板级程序在仿真器中卡在时钟或存储器初始化，也不能直接判定业务代码错误。应先检查两套运行环境的差别。

　　2、带着同一组用例检查实机结果

　　从仿真转到实机后，先验证输入输出一致性，再检查硬件行为和时间要求，排查范围会更清楚。

　　①使用同一份【测试数据】调用相同业务函数，比较返回值、输出缓冲区及错误码。

　　②对不一致的结果，检查【字节序】、数据类型宽度、初始化值和编译优化设置。

　　③检查【中断】、【DMA】及外设交互，补做仿真环境未覆盖的测试。

　　④保存【构建配置】、测试记录和硬件版本，为后续复现保留依据。

　　总结

　　没有目标板时，MULTI仿真调试可以先完成一部分程序验证，尤其适合算法、数据处理和错误分支检查。目标板到位后，外设交互、启动过程和实时性能仍需回到硬件上确认。把两类测试分工写清楚，比追求整套程序在仿真器里一次跑通更有用。希望这些检查能帮助大家提前推进开发，也避免把仿真通过误当成实机验收完成。