言归正传。我做过两种方式的串口升级固件程序。我把他们分别成为loader方式和IAP方式。
所谓的loader方式就是最初只需烧写loader程序即可，loader程序负责通过串口接收应用程序代码，完整接收并校验无误之后，跳转到应用程序区执行应用程序。再复杂一点的可以在应用程序中设置特定触发方式使其跳回loader程序区（系统复位），此时便可以接收另一套应用程序代码实现多次升级，当然了更复杂的甚至可以将除去loader程序区之外的flash区域划分多个区分别保存当前应用程序和新版应用程序，即使在新版应用程序升级失败的情况下还可以还原旧版应用程序，实现系统备份还原；
所谓的IAP其含义就是在应用升级，具体来讲就是在应用程序中接收程序代码（暂存在非当前执行区，此时需要程序员合理规划flash的分区），接收并校验无误之后跳转到引导程序（暂时也叫做引导程序），该引导程序根据flash的写入情况决定是将新版程序拷贝到应用程序执行区（这个执行区最好固定地址空间）还是还原原来的旧版应用程序（此时整个flash分以下几个区：引导程序区、旧版应用程序区（做系统还原之用）、新版应用程序区（新接收的程序代码暂存区（不同于应用程序执行区））、应用程序执行区（也即IAP中的A(Application)）在这四个分区中，除引导程序区之外的其他三个分区其大小最好一致）。
IAP设计时引导程序只负责条件判断flash代码的区域拷贝、中断向量重映射等一些基本工作，相比于loader方式引导程序无需编写串口通信程序（loader方式时串口通信接收程序最好设计成轮询方式）而且引导程序相对更加固定，但是采用此种方式时首次烧写程序需要先烧写引导程序，再烧写应用程序（仿真器烧写应用程序时不能把引导程序区擦除掉），而且每次升级的应用程序起码应该保证串口通信部分程序无bug，否则可能影响下次升级！
最后，有一个设想还未实现，如果引导程序要进行扩展（并非完全因为bug）我们可以在应用程序中接收引导程序代码覆盖旧版引导程序（或者像备份应用程序一样将其做个备份），就像两个木板过河，我们踩在其中一块木板上拿着另一块木板前移，之后跳转到前面的木板再把后面的木板前移如此一来便可以实现过河。
在此也是这样的，当程序在引导程序区执行时我们可以修改应用程序区，同样的当程序运行到应用程序区时我们也可以修改引导程序区！
如此一来程序可以设计的相当灵活，方便不合适拆卸的设备的固件维护，但是过于灵活的程序设计也可能带来更隐蔽的bug。具体设计到什么程度我想应该视应用场景而定吧！