MTK dump(包含10A版本)

Dear Customer,

此问题需要借由memory dump来定位可能的原因，请帮忙抓取取memory dump
请您提供以下文件：
1. memorydump.bin (此文件是透过Catcher保存的，请参考后面的操作步骤)
2. catcher log (*.clg, 此文件是透过Catcher保存的，请参考后面的操作步骤)
3. ELF 文件 (\build\\*.elf) (请注意NFB项目会有两个ELF(for Bootloader and for MAUI)，请提供for MAUI的，即size较大的)

提示：只有当抓memory dump对应的binary与所提供的ELF文件是同一次编译生成的(需要参考ELF文件中的debug信息)，且ELF文件是打开-g之后编译生成的，我们才能分析，请务必注意!!!

您可以按如下步骤进行：
1. 打开makefile(\make\.mak)中的debug symbol选项
10A之前的项目:
在makefile中设置CUSTOM_CFLAGS = -g -gtp
10A及之后的项目:
(1)makefile中关闭--debug --no_debug_macros，即设置makefile中CUSTOM_CFLAGS = # --debug --no_debug_macros 后保存
(2)make\USER_SPECIFIC.mak文件 末尾处 添加如下两行语句后保存，
DEBUG_MODULES = init nvram # means only init and nvram will apply --debug --no_debug_macros, 若有其他module也需要debug symbol, 可以加在nvram后面
CUSTOM_CFLAGS :=
2. 对工程作new操作, 然后Download Binary.
3. 打开Memory dump开关；
进入工程模式，选择Misc.\Memory dump, 将其设置为On
提示：该开关默认为关，并且开机时系统会将其恢复成默认值，所以您的设置只对当次开机有效，若需抓Memory dump，请在每次开机的重新开启此开关
若无法进入工模操作请尝试修改代码来打开，方法如下：
(1)在application_initialize之前extern kal_uint32 INT_MemoryDumpFlag;
(2)在application_initialize中调用mainp的上一行添加INT_MemoryDumpFlag = 0x26409001;
[Note]: 项目MP时请务必删除上述代码, 否则手机在end user端遇到异常时无法自动重启
4. 连上Catcher(Catcher 的filter设置为Field Trial)，复制问题；
5. 当发生异常时，选择Advance\Memory Dump，在弹出的窗口中选择Start按钮开始Memory dump；
提示：发生异常时，LCD上显示错误类型，并且不会自动重启，若手机直接重启或者进行memorydump过程中失败, 请参考后面的常规检查项，Catcher Dump完成之后，会弹出提示窗口告诉您，请不要在此之前关闭Catcher或者断开手机与PC连接
6. Memory dump完成之后，请同时保存Log (选择File\Save As)；
7. 将以上两步保存下来的文件(*.bin, *.clg)及Build\\*.elf寄给我们。


若无法成功抓取memory dump，请先检查以下几项:
1. 确认有打开memory dump开关
提示：可以透过Catcher Sys trace来确认，若在异常信息之后有看到"Caution: To re-dump TST ring buffer!"，表示有成功打开，且系统已进入memory dump流程
请注意透过工模打开memorydump只在当次开机有效，若需抓Memory dump，请在每次开机的重新开启此开关
2. Download cable driver较旧, 建议更新至最新版本再来尝试
a.Prolific cable latest driver download address: http://www.prolific.com.tw/eng/downloads.asp?ID=31
b.FTDI cable latest driver download address: http://www.ftdichip.com/Drivers/VCP.htm
建议先卸载原先的驱动再安装新的驱动，可以在设备管理器里对比安装前后的版本号，确保驱动有更新成功
3. 若更新驱动仍然不行，可以从PCB上飞线UART的TX，RX再来测试是否可以，这样可以排除UART接口不稳定的情况
4. 检查lcd driver里面是否有用kal_sleep_task来做delay函数，一般的命名可能在LCD_Delay()里面用到，可靠的方法是在lcd driver的文件里面搜索kal_sleep_task.
如果有使用kal_sleep_task，请改用for循环来做delay
5. 有可能是异常处理的过程中watch dog timeout。可以disable watch dog再尝试。
修改Application_Initialize 调用mainp之后的如下代码：
#ifdef __PRODUCTION_RELEASE__
#ifdef __MULTI_BOOT__
if ( system_boot_mode!=FACTORY_BOOT )
#endif /* __MULTI_BOOT__ */
//WDT_Enable(KAL_TRUE);
WDT_Enable(KAL_FALSE); //disable watch dog
#endif /* __PRODUCTION_RELEASE__ */
6. 系统可能完全死机，system service无法回应Catcher tool 的指令, 此种情况只能透过TRACE32调试

另外，提醒一点：之后若有类似死机的问题，请在提交问题时一并提供memory dump，以加速问题的处理

转载于:https://www.cnblogs.com/wenlg/archive/2011/03/28/1997719.html