在前三篇博客中主要介绍了IAP远程升级的应用背景、下位机的实现原理、以及基于STM32CubeMX对STM32F103串口DMA的基本配置，第四篇博客主要想介绍Labview端上位机和下位机端的报文定义和通信等。
当笔者工作上刚接触到STM32 IAP升级的时候，实事求是地说存在各种各样的困惑，所以这也是驱动我去撰写博客的动力，有很多CSDN朋友看过“FPGA基础知识”和“FPGA 20个例程”专栏后私信说写得接地气，让读者很容易接收和理解。学习都是从不懂到懂，从不理解到慢慢理解，而这个过程没有人指点的时候会非常痛苦。
当然上面都是题外话，下面就站在工程落地的角度去想想STM32 IAP升级在具体实施中的几个问题，其实这也是当初困扰笔者的问题，主要它们也有很多共性吧。
- IAP升级需不需要特殊上位机的支持，网络上说法不一有很多教程说用串口助手选择本地的bin文件发送即可；
- IAP升级中上位机需要做什么操作，直接把bin文件一次性地发送下去就可以吗；
- IAP升级中下位机需要做什么操作，把收到的bin文件按十六进制数计数重新写入扇区就可以吗；
- 在没有本地显示屏GUI界面的情况下，用户怎么通过上位机告知下位机是跳转到Bootloader还是跳转到Application，Bootloader和Application之间应该怎么切换；
首先回答第一个问题，IAP升级需不需要重新设计一个上位机，有些串口助手确实支持打开bin文件并将其按照十六进制数据格式发送，如果仅仅满足教学实验来说，完全可以用串口助手直接发送，但是现实当中串口通信是不可靠传输，即可能存在干扰等导致传输数据错误，这种没有校验和重发机制的方法发送bin文件显然没有可靠性而言；
其次回答第二个问题，如果上位机直接把bin文件一次性发送到下位机端，下位机则需要去一个个字节接收再去计数数据，然后按照1024字节去写入一个个flash扇区，如果在传输过程中下位机计数错误了，导致flash数据写错将无法处理，所以显然一次性把一整个bin文件串口直接发送下来不是非常稳妥；
再次回答第三个问题，假设每次要更新的bin文件有大有小，这一次更新的没有上一次的大，而上一次存在flash扇区的数据没有擦除干净可能存在风险，所以更建议每次进行IAP升级前从Application初始化地址起擦除完全；
最后回答第四个问题，Bootloader和Application可以理解成两段独立的程序，显然同一时刻STM32只能运行在其中一个状态，且上电的时候STM32先进入Bootloader状态，然后一般情况下通过读取外挂eeprom的值跳转到Application状态，也可以设定一个定时器在5秒钟内未收到上位机发送的指令，则自动由Bootloader状态跳转到Application状态，这样可以节约一颗eeprom的物料成本；
具体实现原理即上位机通过每次给下位机STM32发送1024字节的bin文件报文（最后一包报文如果不足1024字节，有多少发多少即可），下位机STM32收到每包bin文件后写入指定的flash空间，再由上位机程控跳转到Application上。
上位机和下位机之间的通信报文格式：
0x7e,0x7e,0x5a三个字节作为固定报头，第四个字节作为命令码，其中命令号包括0x00 0x01 0x02 0x03 0x04，即报文格式为：3字节固定报头0x7e,0x7e,0x5a + 1字节命令号0x00-0x04 + 2字节当前报文编号（命令号是0x01才包含） + 2字节总报文编号（命令号是0x01才包含） +1024字节bin文件内容（命令号是0x01才包含）+ 2字节Modbus CRC校验码，命令号的内容具体如下，详细数据发送细节在下面结合上位机界面做说明。
0x00：检测bootloader是否存在
0x01：打包发送application的bin文件内容
0x02：发送完所有application的bin文件内容，通知下位机从bootloader模式跳转到application模式
0x03：检测application是否存在
0x04：通知下位机从application模式跳转到bootloader模式
图1 IAP升级助手
如图1所示是笔者所设计的上位机界面，控件1处选择波特率，控件2处选择打开或者关闭串口。点击控件3处“boot检测”，上位机即发送“7e 7e 5a 00 42 b4”，如果下位机STM32发送“2b 52 49 47 48 54 2e 7a”（ASCII码：+RIGHT+CRC16），则代表上位机和下位机之间串口通信正确且下位机bootloader存在，可以操作界面其他控件；如果下位机STM32发送“2d 45 52 52 4f 52 cf 0d”（ASCII码：-ERROR+CRC16），则代表上位机和下位机之间串口通信错误且下位机bootloader不存在，不可以操作界面其他控件。
上位机在通过点击控件“boot检测”确定下位机bootloader存在的情况下，控件7“打开文件”和控件8“发送”才可以被点击，点击“打开文件”，即在本地打开.bin格式的文件，界面显示框内需要显示.bin文件的大小，需要折合发送多少包报文（每包报文默认是1024字节），再点击发送，即把.bin文件的二进制码打包报文发送给下位机STM32，上位机即发送“7e 7e 5a 00“ + 2字节该报文是第几包报文（第一包报文从0开始计数）+ 2字节一个需要多少发送总报文数 + 1024字节.bin文件二进制数据 + 2字节Modbus CRC校验码，比如第一包报文是1024字节，一共含有8包报文，则报文前八字节位是“7e 7e 5a 01 00 00 00 07“，依次类推即可。
上位机每发送一条.bin文件二进制报文，下位机STM32确认无误后会发送“2b 52 49 47 48 54 2e 7a”（ASCII码：+RIGHT+CRC16），上位机在界面显示框内需要显示xx/yy包报文发送成功，如果下位机STM32确认有误后会发送“2d 45 52 52 4f 52 Cf 0d”（ASCII码：-ERROR+CRC16），上位机会重新发送该报文，默认同一报文最多发送五次，超过五次上位机在界面显示框内需要显示STM32远程升级失败！如果报文全部发送完成，且每包报文下位机STM32都返回正确，则上位机在界面显示框内需要显示STM32远程升级成功！
在上位机确认下位机STM32接收完全所有的.bin文件二进制报文后，控件4 “app跳入”才可以被点击，点击此控件上位机即发送“7e 7e 5a 02 c3 75”，下位机STM32确认无误后会发送“2b 52 49 47 48 54 2e 7a”（ASCII码：+RIGHT+CRC16），上位机在界面显示框内需要显示application跳转成功！如果下位机STM32确认有误后会发送“2d 45 52 52 4f 52 cf 0d”（ASCII码：-ERROR+CRC16），上位机在界面显示框内需要显示application跳转失败！
点击控件5处“app检测”，上位机即发送“7e 7e 5a 03 02 b5”，如果下位机STM32发送“2b 52 49 47 48 54 2e 7a”（ASCII码：+RIGHT+CRC16），则代表上位机和下位机之间串口通信正确且下位机application存在，可以操作界面其他控件；如果下位机STM32发送“2d 45 52 52 4f 52 cf 0d”（ASCII码：-ERROR+CRC16），则代表上位机和下位机之间串口通信错误且下位机application不存在。
上位机在通过点击控件“app检测”确定下位机application存在的情况下，控件6“boot跳入”才可以被点击，点击此控件上位机即发送“7e 7e 5a 04 43 77”，下位机STM32确认无误后会发送“2b 52 49 47 48 54 2e 7a”（ASCII码：+RIGHT+CRC16），上位机在界面显示框内需要显示bootloader跳转成功！如果下位机STM32确认有误后会发送“2d 45 52 52 4f 52 cf 0d”（ASCII码：-ERROR+CRC16），