想要搞明白Green Hills INTEGRITY工程怎么创建，还有Green Hills INTEGRITY任务启动失败怎么排查，这两个问题只要是用MULTI来开发那种实时嵌入式应用，就绕不过去，一个INTEGRITY工程不是简简单单把几个C文件塞进项目里就完事了，它还要管目标板上的BSP、地址空间怎么分、内核怎么配、任务从哪里进去、共享库怎么弄，还有怎么连到目标板，工程能顺顺利利编译过去，也不等于任务就一定起得来，好多启动的问题其实是卡在了镜像没有正确加载进去，入口函数没配对，依赖的那些服务还没跑起来，或者任务申请的内存和系统资源已经超过了配置给它的范围。

使用MULTI调试嵌入式控制器的时候，Green Hills Flash下载脚本该怎么写，下载以后程序不运行又要怎么办，这类问题是常会碰到的。目标连接、芯片复位、存储器初始化、擦除、写入、校验还有运行这些操作，都可以由Flash脚本给固定下来。脚本执行成功了，也只能说明数据或许被写到了指定的区域里，处理器复位之后能不能从这个地址启动，那还不一定。要是程序没有运行起来，链接地址、启动模式、复位向量和硬件初始化的检查，就得接着往下做。

在嵌入式项目的开发过程中，只要工程里用到的预编译库稍微多起来，路径设置混乱、不同版本互相覆盖、同一个符号被重复定义这类问题就会变得非常常见，单靠把所有能看到的库文件一股脑儿塞进工程里并不能解决问题。更稳当的处理办法，是先花些力气把每一个库的来源、它所对应的芯片平台、当初编译时用了哪些选项，还有链接过程中各个库的先后次序都理清楚，然后再借助map文件和链接日志，准确地找出到底是哪两个目标文件或者哪两个库之间发生了冲突。

在Green Hills MULTI下面调试嵌入式程序的时候，Watch窗口还有Data Explorer，是大家最常用来盯着变量变化的两个地方。不少人其实都能够正常地把断点给打上，可偏偏变量要么死活都加不进去，要么加进去了，里头显示的那个值却老半天都不见它刷新一下。真的到了动手去查的时候，问题的根子往往都集中在符号信息、编译优化那些选项、能不能做到实时刷新，以及目标板到底连没连稳当这几样上面，反倒不是监视窗口本身出了什么毛病。

Green Hills MULTI怎么调试Green Hills MULTI断点与变量窗口怎么用，常见卡点不是不会单步，而是会话口径不统一：同一份源码在不同机器上生成的下载文件不一致，符号版本对不上，连接方式又各用各的，最后表现为断点不命中、变量窗口一堆问号、跑一会就断连。把Green Hills MULTI调试拆成“可复现构建、可复现连接、可复现观察”三件事，你就能把问题从玄学拉回到可验证的工程流程。

做Green Hills启动代码时，最容易出问题的地方，不是语法本身，而是把启动文件、链接脚本和运行时初始化当成三件互不相关的事来改。实际上一旦入口地址、栈地址和数据段搬运关系没先定清，后面就算`main`能编过去，板子也未必能正常起来。NXP基于Green Hills的启动示例里就把这几层放在了一起：链接文件给出入口和段地址，启动文件负责进复位入口、建栈、准备小数据区，再去做数据搬运和后续运行时初始化。

Green Hills MULTI用久了变卡，往往不是单一原因，而是工程放置位置、索引扫描范围、构建派发、调试连接模式一起叠加出来的体感问题。处理思路可以更务实一点：先把卡顿点定位到编辑浏览、构建、调试三类动作之一，再把索引与缓存落到本地高速盘，并用一次可回滚的重建流程把“越用越慢”的状态拉回到可控。

单步本来是用来快速验证分支与寄存器变化的，一旦一步要等好几秒，排查节奏就会被打断，甚至会让你误判为程序卡死。Green Hills Software的MULTI里，单步变慢通常不是单一原因，而是连接链路的往返开销叠加了界面取值与日志记录等额外动作，先把“慢”分门别类，再动设置会更快见效。

用Green Hills做嵌入式开发，最省时间的做法不是到处搜零散帖子，而是把文档入口与示例工程入口先找准。你先能在MULTI里快速定位到对应手册与菜单路径，再用一套最小可跑通的示例把创建工程、编译、下载、调试这条链路跑顺，后面切到真实项目时就不会反复卡在环境与配置细节上。

Green Hills INTEGRITY内存占用飙升怎么办,Green Hills INTEGRITY内存泄漏怎么定位，现场排查时不要只盯着总内存曲线。更有效的做法是把增长拆回到分区可用地址空间VAS的内存池与堆，再把增长与任务行为、分配调用、异常访问联系起来核对，这样才能判断是参数配额不足、碎片化累积、真实泄漏，还是内存破坏引发的连锁反应。INTEGRITY的分区内存通常是可控配额方式分配，因此趋势分析与配额核对要同时推进。