6225_06B异常重启求助

onlytrue

大家碰到过m11304.c 270行出现Assert的问题么？我们的机器平均一天出现一次这样的重启，这个文件没有源代码，应该如何解决这个问题呢？代码版本为6225_06B，非常感谢！具体错误信息见下：

ex_assertfail_record_t = (struct)
        header = (struct)
                ex_type = 0x05  --  ASSERT_FAIL_EXCEPTION
                ex_nvram = 0x01
                ex_serial_num = 0x0001
        envinfo = (struct)
                boot_mode = 0x01
                rtc = (struct)
                execution_unit = Array [8] --  IDLE
                status = 0x00
                pad = Array [2]  --  全0
                stack_ptr = 0xa00083ac  --  0xa0007c68 D SYS_Stack_Pool
                stack_dump = Array [10]
                        stack_dump[0] = 0x00000001
                        stack_dump[1] = 0x00069ce5  --  0x00069cb4 T L1I_MeasurementsProcessResults
                        stack_dump[2] = 0x0006992f  --  0x00069714 T L1I_InitAMRQICompensated
                        stack_dump[3] = 0x00069431  --  0x000693fc T L1I_FrameTick
                        stack_dump[4] = 0x00000001
                        stack_dump[5] = 0x000693eb  --  0x000693d0 T L1I_FrameInterrupt
                        stack_dump[6] = 0x0042ea11  --  0x0042e9d0 T isrC_Main
                        stack_dump[7] = 0x00000033
                        stack_dump[8] = 0x003e5913  --  0x003e5898 T copy_data_to_tst_ring_buffer
                        stack_dump[9] = 0x0000795b  --  0x00004c40 T l1a_calculate_bl_var
                ext_queue_pending_cnt = 0x0000
                ext_queue_pending = Array [20]  --  全0
                interrupt_mask = Array [2]
                        interrupt_mask[0] = 0xf9de5800
                        interrupt_mask[1] = 0x00000000
                processing_lisr = 0xa0001045  --  0xa0001044 T isrCTIRQ1
                lr = 0xa0001ade  --  0xa0001ac8 T IdleTask
        diaginfo = (struct)
                diagnosis = 0x00
                owner = Array [8]  --  全0
                pad = Array [3]  --  全0
                timing_check = Array [6]  --  全0
        assert = (struct)
                filename = Array [24]  --  m11304.c
                linenumber = 0x0000010e  --  270
                parameters = Array [3]  --  全0
                dump = Array [252]  --  全0
                guard = Array [4]  --  全0

singlespark

肯定不是m11304.c这个文件的问题，而是别的地方的内存溢出到这个文件了。

onlytrue

singlespark：
    非常感谢你的回复，这个重启是待机20小时以后才出现的，挂Catcher也没有看到特别的出错信息，这种内存溢出通常会由是什么累积引起的呢？

DH_killer

如果是内存溢出，每隔20分钟抓一次内存剩余情况，并且打出，是哪个task在使用内存没有释放，然后继续定位。

onlytrue

以下是引用DH_killer在2008-6-30 18:39:24的发言：
如果是内存溢出，每隔20分钟抓一次内存剩余情况，并且打出，是哪个task在使用内存没有释放，然后继续定位。

谢谢你的建议，我按这种方法去尝试一下，有中间结果再发布出来。

singlespark

不一定是因为没有释放引起的，比如定义a【2】，结果某一处代码拷贝了4个元素到a，这样导致栈出现问题，溢出到某个地方出现死机。
如果是全局变量溢出，那么对应.lis文件应该很容易分析得出；如果是局部数组溢出而导致栈被破坏，这样的问题一般很难分析，只能一步一步的往下跟踪代码，一段一段的屏蔽代码。
你看看最近有没有新增加什么、修改过什么，看看重启有没有什么规律，比如进入到某个菜单才会出现重启。

onlytrue

以下是引用singlespark在2008-7-1 13:31:13的发言：
不一定是因为没有释放引起的，比如定义a【2】，结果某一处代码拷贝了4个元素到a，这样导致栈出现问题，溢出到某个地方出现死机。
如果是全局变量溢出，那么对应.lis文件应该很容易分析得出；如果是局部数组溢出而导致栈被破坏，这样的问题一般很难分析，只能一步一步的往下跟踪代码，一段一段的屏蔽代码。
你看看最近有没有新增加什么、修改过什么，看看重启有没有什么规律，比如进入到某个菜单才会出现重启。

不好意思，昨天下午没有过来看帖。
重启规律不是特明显，并不是到某个菜单就必然出现，而是长时间工作后，就算不动它（待机状态），它也会自己重启。另外重启好像的确和m11304.c没有必然关系，因为最近几次出现的重启，并没有出现DEBUG_ERROR的Trace，而是直接就重启了，晕！

singlespark

没有exception信息很可能是因为死机的太快，导致tst task还没来得及将exception输出到catcher中。待机死机而且是随机死机的问题比较棘手，不容易确定出现问题的地方。
你最近没新增什么功能吗？另外死机的时候，有没有死在能看得到源代码的文件里？

DH_killer

如果是堆栈溢出一般情况是 data abort。他明显是asset了。

DH_killer

如果实在死机太快，建议用串口调试。

singlespark

全局变量溢出一般是data abort，并且仅仅是一般而已。局部数组（栈）溢出什么类型都可能。明显这里assert并不是由于本身条件不满足引起，而是别的地方溢出到这里引起ASSERT的。
要迅速的解决这个问题，最好是接上JTAG线，用trace32单步跟踪；或者得到手机的memory dump交给MTK帮你分析。自己的话，只能根据最近的修改来跟踪，或者一个功能一个功能的屏蔽。

DH_killer

他这个问题本身就比较随机，trace32单步跟踪可能性多大？
另外一般现在没有多少公司还有这个东西，大的公司可能有吧。
这东西2年没见到过了。

onlytrue

以下是引用DH_killer在2008-7-2 12:32:50的发言：
如果实在死机太快，建议用串口调试。

通过串口跟踪了三次重启，重启前输出的可见的文本信息如下，不知道能否看出什么新问题？
[1] Fatal Error (804): Buff
[1] Fatal Error (804): Buffer not ava
[1] Fatal Error (804): Buffer not available (10) - L1

onlytrue

以下是引用DH_killer在2008-6-30 18:39:24的发言：
如果是内存溢出，每隔20分钟抓一次内存剩余情况，并且打出，是哪个task在使用内存没有释放，然后继续定位。

刚开机10分钟左右时的内存使用情况：
[sysinfo] status = 1
[sysinfo] Max SysMem used = 224208
[sysinfo] Max SysDbgMem used = 62908
[sysinfo] Max task stack used:
0: [     --    0][  NVRAM 1412][    TST  732][     TR  724][     MM  708]
5: [     CC  676][   CISS  708][    SMS  580][    SIM 1244][     L4 1540]
10: [     RR 1172][  REASM  676][    LLC  732][  SNDCP  348][     SM  484]
15: [   DATA  356][    MED 1092][    MMI 4044][     L1  660][L1AUDIO  636]
20: [   IDLE   96][TP_TASK  492][ DRVKBD  444][ DRVBMT  640][    AUX  404]
25: [     --    0][     --    0][     --    0][    USB  420][    FMT  580]
30: [  VIDEO  388][     --    0][     --    0][    ABM  420][    PPP  356]
35: [  TCPIP  628][    SOC  564][    WAP 2532][    WPS 1020][     --    0]
40: [     --    0][     --    0][     DT  356][    GDC  268][    GDD  476]
45: [     --    0][     --    0][     --    0][     --    0][     BT 1348]
50: [     --    0][     --    0][     --    0][     --    0][     --    0]
55: [     --    0][     --    0][ CAMERA  676][     --    0][     --    0]
60: [     --    0][     --    0][     --    0][     --    0][    MQQ  356]
[sysinfo] Max hisr stack used:
0: [DRVHISR  492][VISUHISR  268][L1_HISR  588][L1Audio_HISR  556][     --    0]
5: [     --    0][     --    0][     --    0][     --    0][     --    0]
10: [     --    0][     --    0][     --    0][     --    0][     --    0]
15: [     --    0][     --    0][     --    0][     --    0][     --    0]
[sysinfo] Max task extq enqued:
0: [     --    0][NVRAM Q    6][  TST Q    0][  TR  Q    2][   MM Q    3]
5: [   CC Q    3][ CISS Q    2][  SMS Q    2][  SIM Q    7][   L4 Q   21]
10: [   RR Q    5][REASM Q    1][  LLC Q    2][SNDCP Q    1][   SM Q    2]
15: [ DATA Q    0][  MED Q    6][  MMI Q   14][   L1 Q    3][     --    0]
20: [     --    0][TP_TASK Q    0][     --    0][DRVBMT Q    3][  AUX Q    5]
25: [     --    0][     --    0][     --    0][    USB    1][  FMT Q    0]
30: [MED-V Q    1][     --    0][     --    0][  ABM Q    1][  PPP Q    1]
35: [TCPIP Q    1][  SOC Q    2][  WAP Q    2][  WPS Q    1][     --    0]
40: [     --    0][     --    0][   DT Q    0][     --    0][  GDD Q    1]
45: [     --    0][     --    0][     --    0][     --    0][   BT Q    3]
50: [     --    0][     --    0][     --    0][     --    0][     --    0]
55: [     --    0][     --    0][MED-C Q    1][     --    0][     --    0]
60: [     --    0][     --    0][     --    0][     --    0][  MQQ Q    0]
[sysinfo] Max ctrl buff num allocated:
(8/16/32/64/128) / (256/512/1024/2048/4096) / (8192/16384/32768/65536)
0: [  32][  35][  23][  48][  20]
5: [  14][   8][   7][   4][   0]
10: [   0][   0][   0][   0][   0]
[sysinfo] Max tst buff num allocated:
0: [   0][   0][   0][   0][   0]
5: [   0][   0][   0][   0][   0]
10: [   0][   0][   0][   0][   0]

一次死机前的内存使用情况
[sysinfo] status = 1
[sysinfo] Max SysMem used = 224208
[sysinfo] Max SysDbgMem used = 62908
[sysinfo] Max task stack used:
0: [     --    0][  NVRAM 1412][    TST  732][     TR  724][     MM  708]
5: [     CC  676][   CISS  708][    SMS  580][    SIM 1244][     L4 1540]
10: [     RR 1180][  REASM  676][    LLC  732][  SNDCP  348][     SM  484]
15: [   DATA  356][    MED 1092][    MMI 4044][     L1  672][L1AUDIO  636]
20: [   IDLE   96][TP_TASK  492][ DRVKBD  444][ DRVBMT  640][    AUX  404]
25: [     --    0][     --    0][     --    0][    USB  420][    FMT  580]
30: [  VIDEO  388][     --    0][     --    0][    ABM  420][    PPP  356]
35: [  TCPIP  628][    SOC  564][    WAP 2532][    WPS 1020][     --    0]
40: [     --    0][     --    0][     DT  356][    GDC  268][    GDD  476]
45: [     --    0][     --    0][     --    0][     --    0][     BT 1348]
50: [     --    0][     --    0][     --    0][     --    0][     --    0]
55: [     --    0][     --    0][ CAMERA  676][     --    0][     --    0]
60: [     --    0][     --    0][     --    0][     --    0][    MQQ  356]

后面的因为串口没有输出，所以就没有信息了。就这些信息来看，RR多使用了8Byte，L1多增加了12Byte，其他基本上没有变化，未能看出Stack使用上的明显错误。

onlytrue

以下是引用singlespark在2008-7-2 14:24:18的发言：
全局变量溢出一般是data abort，并且仅仅是一般而已。局部数组（栈）溢出什么类型都可能。明显这里assert并不是由于本身条件不满足引起，而是别的地方溢出到这里引起ASSERT的。
要迅速的解决这个问题，最好是接上JTAG线，用trace32单步跟踪；或者得到手机的memory dump交给MTK帮你分析。自己的话，只能根据最近的修改来跟踪，或者一个功能一个功能的屏蔽。

因为后来的平台都直接就能起来，基本上串口还是能通的，所以已经有比较长时间没有使用仿真器了，而且6225还从来没有连过JTAG，还不知道我们的仿真器能不能支持了。我去找硬件配合接线了，先试着连一下先，谢谢你的建议！
最近的修改比较多，而且很零碎，最郁闷的是我们很早的版本就有重启的问题，只是没有现在频繁，所以屏蔽都不知道从那个屏蔽起了，郁闷。

whfrog1981

叫HW的人也动动手吧
另外,请问LZ的memory是否在MTK的approve list里面?

onlytrue

以下是引用whfrog1981在2008-7-3 23:03:02的发言：
叫HW的人也动动手吧
另外,请问LZ的memory是否在MTK的approve list里面?

非常感谢你的回复！
我们的仿真器是Multi-ICE兼容仿真器，可以挂三星ARM和PXA，但是昨天折腾了半天，又是上拉，又是下拉，又是复位之类的飞线，还是没有挂上6225，郁闷。
板子上用的MCP是K5L2731CAM，但是他在List中没有6225的配置，我代码中用的是S71PL129JB0BFW9Z的，两者的分块和读写时间基本上一样，难道2731真的和6225有兼容问题，所以MTK才不推荐？

onlytrue

以下是引用onlytrue在2008-7-3 10:12:09的发言：
通过串口跟踪了三次重启，重启前输出的可见的文本信息如下，不知道能否看出什么新问题？
[1] Fatal Error (804): Buff
[1] Fatal Error (804): Buffer not ava
[1] Fatal Error (804): Buffer not available (10) - L1

删除定时输出信息代码中的get_ctrl_buffer，Size为16的块使用量已经恢复到原来的数值，这个重启不再重复出现了。
[em03]但是还是有别的重启[em03]

singlespark

Fatal Error (804): Buffer not available这样的错误我今年刚刚遇到过，当时原因是oslmalloc分配的空间太小，而使用时，strcpy拷贝了超过分配的大小的字符串导致溢出。溢出导致了动态分配的区域不正确，这样只要用oslmalloc分配，得到的地址都是不在有效地址之内。当时问题出在初始化，开机就死机，找了三天才找到原因。
如果不好确定问题出在哪里，你可以试试用catcher导出memory dump：
Memory dump必須是手機死機了之後才能工作, 在工模中將memory dump選項打開的目的, 是要讓手機不會重起, 而停在死機的畫面.所以抓取之前必須確認:
1. 工模中有將memory dump打開,
2. 手機必須停在死機畫面.
memory dump会记录所有的RAM中的内容，如果确实是溢出，根据导出来的文件，应该可以分析的出来，你可以叫MTK的人一起帮你看看，否则一大堆二进制也不好分析。

另外随机死机不排除是驱动的问题，我以前也遇到过，就是手机不管进入哪个模块都会死机，完全随机，死机信息什么都有。最后查出来是EMI文件不对，EMI中的信息和实际的Nor flash不匹配。

singlespark

还有，可以借助OslMalloc是宏的特性，修改#define get_ctrl_buffer(size) get_int_ctrl_buffer(size, __FILE__, __LINE__)宏定义，将__FILE__和__LINE__打出来，这样可以知道都有什么地方分配了空间。