简介：面向手机开发入门者、电子工程师及嵌入式学习者的MTK平台资料索引手册，围绕MTK6225、6226、6223、6235、6253系列多媒体手机开发平台展开。文档从产业背景切入，梳理了光盘套件中的参考电路设计、器件规格、PC仿真开发环境、平台源代码、编译烧录工具、UI制作工具，以及MMI设计、设备驱动、工厂校准、软件系统调试等开发文档，并列出量产版开发套件的硬件特性、器材清单与软件特性，便于读者在接触实际工程前建立完整的平台资源地图。压缩包内仅含1个doc文件，约35KB，体量轻便，适合作为资料查阅与学习路径规划的入口。已有844人浏览学习，可作为了解MTK功能手机SDK组成、工具链与文档体系的参考；对想进入手机开发或嵌入式实践的自学者而言，它能帮助减少盲目搜集资料的成本，快速定位源码阅读、工具使用与模块学习的方向。

1. 一台旧功能机接上电脑，跳出来的 MT6226 就是入口

一台旧功能机接上电脑，设备管理器里跳出 MT6226 这样的字样，很多人到这一步才意识到：手上这块板子里的软件，是一整套完整的手机系统。MTK 6225、6226、6223、6235、6253 这几个型号共用同一套手机开发平台，从 L1 协议栈、KAL 内核抽象层、设备驱动、文件系统一路到 MMI 界面层，源代码全部在内，还配了 PC 端仿真环境、编译工具链、烧写与 Trace 工具。它不是教学玩具，也不是几万行的示例工程，而是当年真正跑在量产机上的代码。适合两类人：想弄明白「一部手机从上电到点亮屏幕中间发生了什么」的嵌入式新手，和打算把 MMI 框架、文件系统这些模块拆出来复用到别的项目里的老手。源码规模确实大，两张盘的体量，别指望一口气读完。

2. 平台全景：一套 SDK 里的六层软件栈和四类工具

这套资料最容易劝退人的地方，不是代码难，而是打开目录后不知道从哪看起。源代码、工具、文档、参考设计混在一起，几万个文件平铺，第一眼看不到主线。我一般会先把软件栈的层次关系画清楚，再回头对照目录，这样每打开一个文件夹都知道它在整条链路里的位置。

2.1 软件分层：从 L1 到 MMI 的职责边界

按这套平台的典型组织方式，软件从下往上是这么分的。最底层是 L1，管 GSM 物理层和硬件时序，跟射频、基带直接打交道，代码大多是汇编和高度依赖寄存器的 C，改动的风险最高，新手建议只读不写。往上一层是设备驱动层，GPIO、LCD、Camera、音频 Codec、键盘、SIM 卡、充电管理都在这里，接口通常以GPIO_、LCD_、Kbd_这类前缀开头。

驱动之上是内核抽象层，这套代码里叫 KAL，本质是对底层 RTOS 的一层封装，提供任务创建、消息队列、信号量、定时器这些原语，类型定义统一成kal_uint8、kal_uint32，消息发送走msg_send_ext_queue这一类接口。再往上是 L4 协议栈，负责呼叫控制、短信、GPRS 会话管理，跟 MMI 之间靠消息通信，不直接函数调用。

最上面两层是 MMI 框架和应用。MMI 是这套代码里体量最大、也最值得研究的部分：它是一套事件驱动的界面框架，按键、触摸、定时器、协议栈回调统统转成事件投递到窗口，窗口再调gdi_前缀的绘图接口刷屏。应用层就是待机、通话、短信、电话本、多媒体这些具体功能模块。整个分层的价值在于：越往下越接近硬件、越不适合改；越往上越接近业务、越适合做二次开发。

2.2 工具链拼图：ADS1.2、ActivePerl、MCT 各管一段

这套代码是 ARM7/ARM9 时代的产物，编译器用的是 ARM ADS 1.2，也就是armcc、armlink、fromelf那一套。链接靠 scatter 文件描述内存布局，代码段、数据段、文件系统区、NVRAM 区在 NOR Flash 上的偏移全靠它定，改了分区表却没改 scatter 文件，编出来的 bin 一定跑飞。

ActivePerl 在这里不是可有可无的装饰。资源编译、部分代码生成、批量文件处理都靠 Perl 脚本驱动，MCT 这个 UI 制作工具导出的图片、字符串、菜单结构，最终要经过脚本转成 C 源文件参与编译。很多人装完 ADS 就以为环境好了，一编译报找不到某个.c文件，本质是资源生成这一步没跑。

剩下三件工具各管一段：FlashTool 负责把 bin 下载到板子上，META 负责射频校准和产线测试，Catcher 通过串口抓系统日志和断言信息。前两个决定你能不能把程序跑起来，第三个决定程序跑挂了你知不知道为什么挂。

2.3 光盘目录速览：先看目录再看代码

拿到资料别急着搜main.c，这套代码的入口不在你熟悉的地方。按功能把目录归个类，心里就有地图了：

这份清单里，文档的价值被严重低估。MMI 设计文档里通常会讲清楚窗口栈、事件分发、软键机制这几件事，看懂这几页，比在代码里翻三天都管用。我的习惯是：先读系统与调试文档，再读 MMI 设计文档，然后才动代码。顺序反了，就是拿时间换教训。

3. 环境搭建：在 PC 上把编译和仿真跑通

真实硬件环境的成本对入门者不友好，这套资料里最有价值的部分之一，就是能在 PC 上把 MMI 层跑起来看看。仿真环境的意义不是替代真机，而是把「改一行代码 → 编译 → 烧写 → 上板验证」这个长循环，压缩成「改一行代码 → 编译 → 看效果」的短循环。界面逻辑、菜单跳转、字符串显示这类问题，在仿真里调比在板子上调快十倍。

3.1 目录落位与环境变量：路径不能带空格和中文

ADS1.2 那个年代的构建系统对路径极其敏感，装到C:\Program Files下面基本必挂，路径里有中文更不用说。我一般直接建一个短路径根目录，把所有东西平铺进去，比如D:\mtk6225，下面分tool、src、custom、out四个子目录。工具链、源码、客户化配置、编译产物各占一个，互不干扰。

环境变量也要设对。ADS 需要ARMROOT指向安装根目录，Perl 需要能找得到脚本依赖的库路径。这些变量在命令行里 export 一次，比在 IDE 里点来点去可靠得多。老项目还有个坑：脚本里可能写死了盘符或者用反斜杠拼路径，在别的机器上直接失效，遇到这种就用文本搜索把硬编码路径找出来改掉，别一处一处试。

3.2 编译一个最小目标：从资源生成到 bin 产出

完整编译一次这套代码，在当年的机器上要跑十几分钟，现在反而更快。但第一次别直接全量编，先挑一个最小的客户化工程验证工具链通不通。典型流程是这样：

# 1) 工具链路径，全部落在无空格无中文的短路径下 export ARMROOT=/d/mtk6225/tool/ads12 export PATH=$ARMROOT/bin:$PATH export MTK_ROOT=/d/mtk6225 export PERL5LIB=$MTK_ROOT/tool/perl/lib # 2) 先跑资源生成：MCT 导出的图片/字符串/菜单要变成 C 文件才能参与编译 cd $MTK_ROOT/custom/app perl $MTK_ROOT/tool/scripts/resgen.pl config=release # 3) 再编译，makefile 内部调 armcc / armlink make -f make_custom.gpr clean make -f make_custom.gpr 2>&1 | tee build.log # 4) 产物检查：bin 没出来就先翻 build.log 里的链接错误 ls -lh $MTK_ROOT/out/*.bin

这里的每一步都有讲究。第一步的MTK_ROOT不只是方便，很多脚本靠它定位相对路径。第二步的config=release是配置名，实际项目里可能有debug、release、customer_a多套，改错配置就会引用到另一套资源。第三步先把clean跑一遍，是因为这套构建系统的依赖关系描述得不够严谨，增量编译经常留下上一版的中间文件，出现「改了代码没生效」的玄学问题。第四步的 bin 才是能烧进 Flash 的东西，armlink阶段的 L6220、L6218 错误基本都是内存布局超了，得回头改 scatter 文件而不是改代码。

3.3 下载与 Trace：FlashTool 烧写、Catcher 抓日志

bin 有了，下一步是让它跑起来。FlashTool 需要一份下载配置，里面描述 Flash 型号、分区地址、每个 bin 段该落到哪个偏移。这套配置一般随平台资料提供，但换一块不同型号的板子就可能要改。我的习惯是：动手前先用工具把原机固件整片读出来存一份，这是唯一的后悔药，读不出来就别往下走。

Catcher 是这套平台里我最看重的工具。它通过串口把系统内部的 trace、断言、任务切换信息打出来，程序跑飞、白屏、死机、重启，第一件事永远是接上它看最后几行输出。很多人遇到问题就猜代码，猜一天不如看三十行日志。端口波特率、COM 口号这些基础参数不匹配的话，表现是「连上了但一个字都没有」，这时候先怀疑线序和波特率，别怀疑工具坏了。

4. 核心链路拆解：一个按键事件从驱动到屏幕的完整路径

要看懂这套代码，最有效的办法是跟一条完整链路。按一下键盘，屏幕上的高亮块换了一行，中间经过中断、消息队列、任务调度、事件分发、窗口重绘五个环节。这条链走通了，其他功能都是同一套模板换参数。

4.1 驱动层：GPIO 与键盘中断注册

键盘在硬件上是一组行列扫描线，软件上先要把引脚配置成正确的方向和中断模式，然后在中断里只做最轻的一件事——把消息投出去。这是这套代码里反复出现的写法：

/* gpio_kbd.c —— 键盘扫描引脚配置与中断注册（按这套平台的驱动命名习惯） */ #include "kal_public_api.h" #include "gpio_public.h" #define KBD_COL0_PIN (12) /* 列线：输出，主动拉低扫描 */ #define KBD_ROW0_PIN (16) /* 行线：输入，下降沿触发中断 */ void kbd_ext_init(void) { /* 1. 引脚先切到普通 GPIO 模式，方向和上下拉分别设置 */ GPIO_ModeSetup(KBD_COL0_PIN, 0); GPIO_InitIO(OUTPUT, KBD_COL0_PIN); GPIO_ModeSetup(KBD_ROW0_PIN, 0); GPIO_InitIO(INPUT, KBD_ROW0_PIN); /* 2. 行线下降沿触发，按下瞬间进中断 */ GPIO_EnableIntr(KBD_ROW0_PIN, EDGE_FALLING); } /* 中断服务程序：只投消息，不做扫描，不在中断里延时 */ void kbd_eint_handler(void) { kal_uint8 row_state = (kal_uint8)GPI_GetData(KBD_ROW0_PIN); msg_send_ext_queue(MMI_TASK_ID, MSG_ID_KBD_SCAN_REQ, row_state, 0, 0); }

GPIO_ModeSetup(pin, mode)的第二个参数传 0 表示普通 GPIO 功能，传其他值是复用成 I2C、UART 这类外设；GPIO_InitIO(dir, pin)定方向，输出用于扫描驱动，输入用于检测；EDGE_FALLING是触发边沿，接上拉的键盘一般用下降沿。中断服务程序里绝不能做扫描延时，因为按键抖动和长按判断都要毫秒级轮询，放中断里会把整个系统拖住。这套代码里所有中断基本都是这个套路：硬件事件进来，投消息，回中断，剩下的事交给任务。改键盘映射时，改的是引脚定义和扫描表，别动中断逻辑。

4.2 MMI 层：事件队列和窗口绘制

消息到了 MMI 任务，就进入事件驱动的那一套。窗口压栈、按键回调注册、软键功能绑定、绘图接口刷屏，这四件事构成一个界面的骨架：

/* custom_menu.c —— 注册一个自定义菜单屏，按键走事件回调 */ #include "mmi_features.h" #include "custom_menu.h" static void custom_menu_highlight(void) { /* 先清局部区域再画，避免残影；gdi_ 前缀是这套平台的绘图接口 */ gdi_draw_rect(10, 40, 230, 120, GDI_COLOR_BLUE); gui_print_text(20, 50, g_menu_text[g_menu_index]); } static void custom_menu_key_handler(U16 key_code, MMI_EVENT_TYPE evt) { switch (key_code) { case KEY_UP: g_menu_index = (g_menu_index + MENU_COUNT - 1) % MENU_COUNT; custom_menu_highlight(); break; case KEY_DOWN: g_menu_index = (g_menu_index + 1) % MENU_COUNT; custom_menu_highlight(); break; default: break; } } void custom_menu_entry(void) { EntryNewScreen(SCR_CUSTOM_MENU, NULL, NULL, NULL); /* 压栈，返回时自动恢复 */ ClearScreen(); custom_menu_highlight(); /* 按键注册：第三个参数区分按下和抬起，长按要另注册 */ SetKeyHandler(custom_menu_key_handler, KEY_UP, KEY_EVENT_DOWN); SetKeyHandler(custom_menu_key_handler, KEY_DOWN, KEY_EVENT_DOWN); SetLeftSoftkeyFunction(custom_menu_confirm, KEY_EVENT_UP); DrawSoftkey(); }

EntryNewScreen的第一个参数是屏幕 ID，用来标识这一屏，返回栈靠它做恢复；后面三个参数分别是进入前回调、退出回调、销毁回调，不需要就传 NULL。SetKeyHandler里的KEY_EVENT_DOWN和KEY_EVENT_UP必须成对考虑：只注册 DOWN，右软键的返回功能可能被上层拦截；只注册 UP，快速连按会漏事件。绘图部分gdi_draw_rect的四个坐标是左上右下，超出屏幕范围不会报错，只会画不出来，这是排查白屏问题时最容易被忽略的一点。新增一个界面，标准动作就是：定义屏幕 ID、写 entry 函数、注册按键、在主菜单里挂一行入口，四步缺一不可。

4.3 文件系统与 NVRAM：参数存哪儿、掉电怎么不丢

这套平台有两套持久化机制，用途完全不同。文件系统挂在 Flash 的一个独立分区上，存图片、铃声、录音这类大块数据；NVRAM 存的是小块的、必须绝对可靠的参数，比如校准值、IMEI、开关机状态、用户设置。NVRAM 按 LID 编号管理，系统占用了一批，客户化参数要从空闲段往后分配：

/* nvram_custom.c —— 自定义参数区读写，掉电不丢 */ #include "nvram_public.h" #define NV_CUSTOM_LID 0x00F0 /* 自定义起始 LID，避开系统已占段 */ #define NV_CUSTOM_SIZE (4 * 1024) /* 预留 4KB，够放几十个配置项 */ kal_bool nv_custom_read(void *buf, kal_uint16 len) { kal_uint16 read_len = len; if (len > NV_CUSTOM_SIZE) { return KAL_FALSE; } /* 第三个参数是出参，失败时会被置 0，靠它判断是否真的读到了 */ if (!ReadRecord(NV_CUSTOM_LID, buf, &read_len)) { return KAL_FALSE; } return (read_len == len) ? KAL_TRUE : KAL_FALSE; } kal_bool nv_custom_write(const void *buf, kal_uint16 len) { if (len > NV_CUSTOM_SIZE) { return KAL_FALSE; } /* 写入建议放在关机流程或参数真正变更时，别在循环里频繁调 */ return WriteRecord(NV_CUSTOM_LID, (void *)buf, len); }

LID 冲突是这套平台上很典型的翻车点：自定义参数的起始编号如果正好压在系统段上，编译没问题，烧进去也能跑，但某个功能会莫名其妙失效，或者校准值被覆盖。安全做法是先查文档里系统 LID 的占用表，从明确标注空闲的位置开始分配。写入频率也要控制，NVRAM 底层是 Flash，擦写寿命有限，把「当前页码」这种变化频繁的东西往 NVRAM 里塞，半年就能把一块区域写坏，这类数据应该放内存，关机时落一次盘。

5. 排查与避坑：编译、下载、跑飞三类问题的现象和根因

这套代码的坑有个共同点：报错信息离真正的原因很远。编译报找不到符号，问题可能在资源没生成；烧进去不启动，问题可能在 scatter 文件的分区偏移；界面显示乱码，问题可能在字库没编进去。下面几条是我和身边人踩过的，按现象、原因、解决三段写清楚。

5.1 编译期：工具链与资源生成制造的假故障

现象一：全量编译报大量语法错误，指向一些看不懂的宏。原因：编译器版本不对或者用了更新版的 ADS 补丁。这套代码对编译器版本敏感，armcc的小版本差异会带来内建宏和预处理行为的变化。解决：严格用资料里配套的编译器和补丁，别图省事装个新版。装完先编一个官方示例工程，能过再编自己的。

现象二：报找不到某个.c文件，但文件明明在磁盘上。原因：资源生成脚本没跑，或者跑了但配置名不对。MCT 导出的资源在编译前要生成一堆中间 C 文件，脚本靠配置名决定读取哪套资源目录。解决：按顺序先跑资源生成、再跑编译，配置名和 makefile 里的一致；生成完去输出目录确认那几个文件的时间戳是不是刚刚。

现象三：改了代码重新编译，烧进去行为没变。原因：增量编译没有重新链接，或者烧的是旧 bin。这套构建系统的依赖描述不完整，头文件改了不一定触发重编。解决：涉及宏定义、结构体、头文件的改动，一律先clean再全量编；烧写前看一眼 bin 的修改时间，别烧错目录。

5.2 下载与启动：能烧进去不等于能跑起来

现象四：FlashTool 提示下载成功，但开机无反应、黑屏、或者反复重启。原因：scatter 文件描述的段地址和实际 Flash 分区对不上，或者下载配置里的起始地址写错。这套平台的 Flash 布局是硬编码的，代码区、文件系统区、NVRAM 区各有固定偏移，改了一处没改另一处，程序会被加载到错误位置。解决：把 scatter 文件和下载配置里的地址表逐项对照，先下载官方原始 bin 验证板子和工具链没问题，再换自己编的。

现象五：Catcher 连上没输出，或者只输出一行就断。原因：串口参数不匹配、线序不对，或者程序在串口初始化之前就挂了。最后一种最坑，看起来像工具问题，实际是启动早期就异常。解决：先确认波特率和 COM 口，再换一根确认可用的串口线；如果仍然只有一行输出，把 trace 打点往启动流程更早的位置挪，定位到第一个挂掉的初始化函数。

5.3 运行期：白屏、死机和内存问题

现象六：进入某个界面白屏，返回后其他界面也花屏。原因：绘图坐标越界或者没做局部清屏，也可能是窗口退出时没恢复裁剪区域。直接在屏幕上画而不走窗口裁剪，会把内容画到别的区域。解决：绘图前设定裁剪矩形，退出界面时恢复；排查白屏就先在 entry 函数第一行打 trace，确认函数进了没有，再二分定位到具体哪一行绘图调用。

现象七：运行一段时间后死机，重启后又能跑一段。原因：多半是内存泄漏或任务栈溢出，MMI 层反复创建窗口却没释放。解决：接上 Catcher 看死机前的最后几条日志，重点看任务切换和内存分配记录；界面退出路径上逐步注释掉资源申请，用二分法找到泄漏点。这套代码没有现代意义上的内存检查工具，靠日志和代码审查是主要手段。

6. 二次开发：把 MMI 框架和文件系统拆出来单独用

这套代码里最值钱的部分，不是手机功能本身，而是两个可以脱离手机场景复用的东西：事件驱动的 MMI 框架，和基于 Flash 的小型文件系统。我做过一次迁移，把 MMI 的窗口栈和事件分发抽出来，套到一个带彩屏的工控面板上，验证下来完全可行，关键在于抽的时候别贪。

抽 MMI 的思路是分层剥离。先只保留事件队列、窗口栈、按键映射三块，把手机特有的通话、短信、SIM 相关的消息 ID 和回调全部摘掉，绘图接口替换成目标屏的驱动。迁移时我列了一张对照表，逐项确认：

文件系统的剥离相对独立，重点看两块：分区挂载和掉电保护。挂载部分要改的是起始地址和容量，掉电保护部分要看它的写入策略是不是先写备份区再更新索引，如果不是，移植过去之后必须自己补一层，否则断电时目录表损坏，整个分区都读不出来。我当时图快省了这一步，测试阶段断了两次电，文件系统直接变砖，只能整片擦除重来。从那以后我每次移植文件系统，都强制走一遍「写入过程中随机断电二十次」的验证，过不了就不上线。

改代码的顺序也有讲究。先改显示，再改输入，最后改存储。显示改完能点亮，输入改完能操作，存储改完能保存设置，每一步都有可见的验证结果，出问题也好定位。反过来先动存储，前面两步还没通，你根本分不清是存储写坏了还是界面本来就没画出来。

这套资料真正的用法，不是把它当成一门课从头学到尾，而是当成一个可以随时翻的参考实现：想看中断怎么组织，去看驱动；想看界面怎么解耦，去看 MMI；想看小系统怎么做持久化，去看 NVRAM 和文件系统那几段。工具链旧、文档散、坑不少，但能看到一个完整商用量产系统的全部代码，这件事本身就少见。希望帮到你。

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