ISP效果经验总结
基于最近平台独立分析排查宏视另一个强光下，ISP偏红震荡问题，最后由李志确认方案的案例。
结合平时解决问题的经验，个人认为在这种模块负责人没有时间情况下，有些时候问题负责人根据一定的套路可以尝试着解决。不合理的地方，还请多多指教。
对ISP效果问题总结如下：
1、收集：根据图像异常现象，打印常见ISP参数，观察参数的变化情况，这个过程要细心，不要放过任何蛛丝马迹。
2、猜测：确定某个参数异常变化的时间点是否和图像异常的时间点吻合，如果吻合，那么这个参数应重点跟踪。（这个猜测有了依据）
3、求证：阅读代码，梳理参数的变化过程，在异常的地方，临时调试性修正。查看结果，如果有效果，基本锁定了问题。如果没有效果，回到第1步。
4、修复：请模块负责人确认问题，如果负责人认为确实有问题并给出修复方案，问题负责人还需从正常程序设计逻辑上监控修复方案的合理性。 如果负责人认为不是问题，应该解释临时修正有效果的原因。
5、验证：合理性修复后，测试整个系统验证问题是否已修复。
ps:细心收集、大胆猜测、小心求证。对这个模块经验不足的人切记臆想型猜测，然后使用试错的方法解决。
rt-thread: vi动态模块线程被意外终止（内存异常）问题调试记录
1、追踪确定动态模块异常终止的原因：
动态模块创建的camera驱动线程的线程控制块出现异常，内核检测到后，将这个动态模块终止。
2、调试内存异常的过程：
a、在问题内存前后申请测试10K内存作为测试内存，问题依然存在，基本排除相邻内存越界。
b、怀疑是内存意外被线程释放（线程删除），放开内核调试打印，问题又不出现了，结合之前添加打印，有时异常，有时异常，随机性比较大，所以更可能是内存踩踏。 c、把不相关模块都剔除，缩小范围，重新梳理异常的现象，每次name被修改的比较随机，但是同一个结构体内的type却每次都被修改为0。
d、将该线程控制块每隔段时间打出来，基本可以缩小范围到函数DrvModule_Terminate_Task，只有在这个函数附近才会出现，屏蔽其中某些子函数可以恢复正常。但是不能确定是具体哪个子函数执行完才出现的，不能定位到具体那条语句。
e、那么就和线程调度有关，执行某个子函数被切出去踩踏了，回来就异常，全部查看其子函数是否有任务切换，手动添加线程调度打印，发现确实有线程调度。
f、阅读理解驱动框架drv_module，发现rt_drv_entry线程退出后，会调用DrvModule_Free，想起rtt开发手册有一条注：“在线程运行完成，自动结束的情况下，系统会自动删除线程，不需要再调用rt_thread_delete()函数接口”，但是手册没有说如果调用后会有什么后果。
g、为了验证这个猜测，在rt_drv_entry阻塞住，不退出，经过多次测试，问题没有再复现。
h、结合代码，确实是会在idle中将线程控制块中的type清零，name不会清零，所以才会出现c中描述的type每次都是0，name异常的比较随机。
i、想起剑平、兴建原来也遇到thread_dele接口问题，他们通过修改rtt代码绕过，通过验证也是这个问题，于是纠正原来的修复方式。
3、问题原理描述：
如果有子线程主动退出成为僵尸线程，在任务切换时又先执行了idle线程，idle线程会把僵尸线程的控制块释放，然后再切回应用主线程时，主线程又调用了rt_thread_delete接口释放资源，这时rt_thread_delete接口里仍然会意外访问该线程控制块，导致该内存访问异常。
4、解决方案：
修复驱动框架，避免子线程主动退出后，资源被idle线程释放，然后主线程又调用rt_thread_delete访问资源。
待续：
对录像问题：
对网络传输问题：
对写卡问题：
对系统崩溃问题：