RDA平台解决死机问题的经验

     最近工作是在RDA平台上做研究，解决产品的平台的相关问题。期间遇到了不少的死机问题。大致分几类：1.自写代码错误产生。2.平台接口使用不正确产生。3.平台缺陷导致。4.硬件使用不当或者硬件平台缺陷导致。5.部分编译导致实际链接与源代码不符。
    原因1：基本上是自己代码逻辑错误造成，比较容易排除。很多与写代码习惯相关。例如：uchar b[10]; uint32 a; a=*((uint *)(b+1));这样直接将串口传过来数据转换一下类型就使用。 一般编译器不会检查地址对齐，编译可以通过，逻辑上也没有错误。好的编译器会自己读2次后合成，但是一般编译器不会这么做，多数只给个警告。如果不注意解决警告的程序猿，就可能犯错。遇到在这里死机的，如果没有硬件需要地址对齐概念的人，会觉得死得很奇怪。（一般谷、度一下可以解决）
    原因2：对平台接口的流程不熟悉。调用后，消息处理上导致死锁，就是一般说的假死，也就是将自己或者系统的某个task永久性的挂住了。一般来说梳理一下系统的调用的流程，基本上就能解决这样的假死问题。系统调用流程的梳理，有几个小技巧：a、当预编译宏较多时，不知道程序走哪段代码，只要在你认为分支的代码中加个“，”，然后再单独编译这个模块。如果出错就表明你的分析是对的。b、系统调用太复杂了，不知道走哪个函数。就在系统调用最终使用到的硬件抽象层hal中，加入asset，让调用死机在调用的地方。然后用coolwatcher中的gdb工具看调用关系。c、调用到发布的库中，没法继续跟。这个一般有注释，从中你可以了解回调在哪里然后继续。d、有时候遇到宏拼接（就是利用宏规则拼接成调用函数），就需要你熟悉宏定义的规则，分析出名字来继续。
    原因3：RDA平台本身平台有限制和错误。例如：RDA平台上同步消息，经常没有判断消息发送状况就调用信号量阻塞，默认消息发送是成功的。但在一些情况下消息队列分配完，导致消息未发送，这样就永久的挂起了一个task。RDA平台上，音频部分很喜欢在堆栈上分配一个大数组，一般也没有大问题。但极端情况下容易导致堆栈的溢出。建议自己修改一下，放到堆中或者分配一个固定的数组。
    原因4： 这个就比较依赖具体的硬件平台了。一般错误会发生在操作硬件的时候，没有注意使用条件。导致硬件的异常使用。例如：2个task同时操作硬件。在写驱动的时候存在逻辑错误。等等。
    原因5：一般是个人没有注意维护源代码和板卡程序的一致性导致的。每次编译的时候，不要改动代码。改动代码的模块，一定要再编译一次。 不确定是否有不一致的情况，就将工程renew一下。这样取保不会出现不一致性问题，不一致的问题比较难发现，是个人编程习惯导致的错误，别人也很难帮你。如果遇到奇怪问题，你就先renew一下，确定问题是否由这种不一致导致的。