bootloader·开发总结

1、关于到底要不要加看门狗。现在看来是要加的。跑飞，不意味着一定会停在某个地方不同，可能是到处乱窜，所以就可能跑到擦写flash的地方，所以通过狗复位初始化，让程序重新运行，这样就至少不会让片子弄坏，除非复位后又跑飞。无论如何，看门狗就是最稳妥的做法。

2、擦写flash驱动放在RAM，通过通信传输，这样进一步降低了非人为原因擦写flash的可能性。

     ST官方的一篇文章非常好《干扰环境下 Flash 数据丢失.pdf》

写到：

----------------------------

什么是可控性？如何做到严格的逻辑验证？在这个问题上不妨借鉴一下成功的案例：美国导弹核潜艇上对导弹发射按钮的管理。核武器的威力是强大的，发射按钮的管理权掌握在单个人的手里是可怕的。为了避免如此危险的武器被滥用，在导弹核潜艇上，导弹的发射按钮是由三个人共同管理的。艇长、副艇长各有一把钥匙，武控官掌握着口令。发射导弹时，必须由武控官输入口令，然后艇长、副艇长同时用各自的钥匙操纵各自的按钮，导弹才得以发射。考虑特殊的情况，如果某个人通过特别的手段同时掌握了两把钥匙和口令，能否发射导弹？答案是不能。因为艇长、副艇长和武控官各自的作业位置相距很远，而且有时间限制，一个人是无法完成这三项作业的。如果艇长、副艇长和武控官合谋叛乱又如何呢？还是发射不了导弹。因为发射导弹的另一半口令和导弹的瞄准参数根本不在潜艇上，只有在下达核攻击命令时才通过密文发给潜艇。甚至，在导弹发射之后，艇上人员也无从知到它将飞往何处，也控制不了。这样，强大的武器最终掌握在中央指挥机关的手里。回到 
STM32 的问题，如表（一）、表（二）所示的函数，谈不上逻辑验证，一旦被调用会好不犹豫的执行下去，而不在乎调用是合法的还是非法的。为了避免 Flash 被误擦、误写，STM32 在硬件设计上是有所考虑的，就是在擦除或写入之前，必须验证口令，如果口令不对 Flash 控制器拒绝相应的操作。然而，表（一）、表（二）所示的函数中，口令的验证形同虚设，没有起到应有的作用。因为，在这两段程序中，口令的验证是无条件通过的。犹如锁上门后，却把钥匙留在锁眼里，是不能防盗的。

------------------------------------------------------------------------

3、开发过程中我犯了两个错误，并且这个错误的后果多次显现。

第一个问题是我对上位机MOSX的pcomm组件不太熟悉，尤其是对timeout不熟悉。浪费我好多时间。致使后来被搞得疲惫，一些功能也没心思加上了。比如通过上位机将一些信息传送至单片机中，像电脑下载时间、电脑MAC地址等。

第二个问题是开发前期我就应该对CAN过滤展开充分的测试。我对这个过滤当时太自信了。自以为能搞定。结果等开发快结束了才展开充分测试，就说过现在有些东西都没有过滤掉。愿意不明。但是我弄一个简单的例子就行过滤都没有问题。难道是在unlocked flash模式下CAN过滤就不好用了，不得而知。反正现在的过滤能把标准frame都过滤掉就可以了。

还有一个问题是开发进度太慢，导致上位机界面弄的很粗糙，拖到后期人搞得疲惫，所以一些很人性化的小功能都懒得添加了。