接前一篇文章PY32F系列MCU在OTA时App区概率性跑不起来的根因分析5四、总结与感悟前边几篇文章分析定位并解决了笔者在实际项目中遇到的OTA时偶发的程序跑飞问题。本篇文章对于整个过程进行总结并给出笔者在此过程中的一些感悟。定位这个问题前后花了差不多一个月的时间期间笔者经过了前边文章所述的不断增强手段、绕过此问题的过程但是对于根因一直不能捕捉到。实际上之前笔者是改过这一块的前文书给的例子是基于PY32F0系列的笔者之前修改过这块只是当时没觉得这块如此重要。真正出现问题、花时间探寻问题的是另外一块板子它是基于PY32F4的不过意思上差不多。为了便于说明和理解问题前文书笔者就合二为一了。这个问题的解决过程实际上是分了两条线。第一条线由于笔者一直不能定位到根因只能采取尽量规避的方案这个过程就是笔者前文书讲的不断增强复位手段的过程。真正让这个问题有所转机的是那天下午在天使用户家没有经过OTA也出现跑飞的那一次。笔者之前经过最强复位手段仍不能完全解决问题时就曾怀疑过并非是OTA引发的问题刚好那天复现同样的问题印证了笔者的猜测。这样一来就有一个好处将问题定位范围锁定在了APP_Bootloader_Go函数进而锁定在APP_DeInitInterface函数中。按照正常流程笔者接下来会将APP_DeInitInterface函数也按照PY32F0系列的做修改修改之后大概率就不会复现问题了。那么再倒推想清楚为何做出如此改动后会解决问题从而定位到根因。这个过程属于反向定位。第二条线本来应该会按照第一条线的流程走但是当时时间太紧迫了经过组会集思广益后决定使用Cursor定位问题。好在当时前一天已经再天使用户家复现了问题将范围已经缩小到了APP_Bootloader_Go函数中。结果经过了几分钟的思考Cursor给出了它的根因分析。这个过程属于正向定位。那天赶得也巧前一天天使用户家复现问题后第二天上午就开始走第一条路线下午基本上代码就快改完了。但由于当时并不知道这样能否解决问题因此同时走第二条线。两条线在下午交织汇聚到了一起都指向了APP_DeInitInterface函数。最终解决了该问题。但是这其中有一个特别要说的也就是笔者在此过程的感悟。即使走的是第一条线笔者也只能是先解决问题再反推代码差异进而找到问题跟因。并不能做到直接正向分析出根因。笔者从业20多年了在单片机领域也算颇有经验了但比AI在短短几分钟之内就能分析代码、正向推断问题的能力相差甚远。后边又有一个问题同样是靠AI解决的后边会有专门文章那个问题的解决过程就更凸显笔者和AI的差距了。这个差距一度让笔者十分沮丧干了二十年、最起码单片机经验也有十几年反倒不如AI。不过后来笔者想明白了笔者所面对的不单单是AI而是其背后的大数据、大模型。这其中蕴含了全球成千上万的工程师的智慧结晶笔者比不过AI其实输得不冤。这就好比一个人和一个汽车比赛谁跑得快是一个道理。
