1、使用系统API前先判断自身传入参数的有效性和范围等是否符合要求，一般系统API是库文件，使用错误更难发现问题。
2、针对不同的平台常用的接口，务必增加适配层隔离，便于调试和后续移植。比如有的平台中断（SDK提供的中断回调不一定是硬件中断）不支持串口日志。
3.4 RTOS系统特性
1、多任务的竞争，在RTOS系统中，需要注意全局函数、全局变量的使用，避免互相竞争影响，对公共函数尽量做到可重入设计 。
2、中断与任务的调度关系。
3、合理分配任务栈空间和消息队列的深度，函数内部尽量少用大数组。
3.5 个人素养
软件编码完成，不是能编译就收工了，其功能是否符合预期，开发人员自己检查是最高效的，很多问题都是开发不仔细，或者很简单的C基础应用错误，这不是技术问题而是心态。可以多看看开源代码，或者《C专家编程》等。
4、后期解决问题
如果软件问题不可避免，该如何去修复解决呢？
一般来说100%出现的问题都比较容易解决，找到相关代码仔细检查或者加点日志就能发现问题。难处理的是小概率出现的问题，稳定复现它就是成功的一半。
4.1 问题复现
稳定复现问题才能快速对问题进行定位、解决以及验证，如何提高复现的概率？
1、模拟复现条件，问题只在特定的条件下出现，对于依赖外部输入的条件难以满足，可以考虑程序里预设直接进入对应状态，或者软件内部进行极端的压力测试。
2、提高相关代码执行频率，进行某个操作才可能出现异常，人工持续操作，或者软件频繁执行相应的功能，提高问题点的执行频率，加快复现速度。
3、增大测试样本量 ，个别样机难出现，如果条件允许，可以使用多个设备同时进行测试。一般情况下试产就是为了发现这类问题。
4.2 问题定位
缩小排查范围，确认引入问题的函数或代码片段。
1、打印日志 ，日志是最直接、简单的调试方法，在问题的可疑点增加日志输出，以此来追踪程序执行流程以及关键变量的值，观察是否与预期相符。
2、版本回退，使用版本管理工具时可以通过不断回退版本，验证前面版本的情况，定位首次引入该问题的版本，针对该版本的改动进行排查。
3、二分注释，“二分注释”类似二分查找法的方式注释掉部分代码，以此判断问题是否由注释掉的这部分代码引起。具体为将与问题不相干的部分代码注释掉一半，看问题是否解决，未解决则注释另一半，如果解决则继续将注释范围缩小一半，以此类推逐渐缩小问题的范围，确定是哪一块代码导致这个问题。
4、硬件协助，借助示波器、逻辑分析仪分析波形，必要时也请硬件协助分析；问题样机与正常样机的主控对调，看问题是否随芯片走。尤其是涉及驱动方面的问题，比如充电、中断、复位、外设通信调试异常时。
5、仿真调试 ，在线调试可以起到和打印LOG类似的作用，适合排查程序崩溃类的BUG，当程序陷入异常中断候可以直接STOP查看call stack以及内核寄存器的值，快速定位问题点，不过这需要硬件支持。
6、三板斧，使用最多的是前面三种方法，这三板斧足以应付大部分业务逻辑问题；偶尔请硬件协助解决驱动问题，日常开发中的问题都能解决。个别系统层面或者架构不合理导致的深沉问题，要么花时间死磕coredunmp，要么联系原厂FAE协助，一般芯片方案商都提供技术支持。
4.3 问题修复与回归测试
1、缩小范围确定问题代码，再排查具体的函数，修复问题点
2、有些问题属于架构层面，比如和RTOS相关的竞争关系，这种就无法定位到具体问题代码点，只能在宏观上依靠经验或操作系统理论去解决
3、解决后需要进行回归测试，确认问题是否不再出现，也要确认修改不会引入其他新问题。
4.4 复盘
1、一般情况下最后发现原因都是很简单的几句话，比如数据越界或者循环体多执行一次，看起来都是很简单的基础用法，因为一句错误可能需要几周时间来发现解决，为什么当初写错而且没检查发现呢？
2、总结问题产生的原因及解决方法，今后如何防范，对其他平台否值得借鉴，做到举一反三，从失败中吸取经验。
5、心得
业务指示开发、测试驱动开发，这一荒谬方法论，体现在部门合作与职责不清，整体就是效率低下、互相推诿，在这样的环境下开发软件也很累。