STM32 10个工程篇:1.IAP远程升级(四)

      在前三篇博客中主要介绍了IAP远程升级的应用背景、下位机的实现原理、以及基于STM32CubeMXSTM32F103串口DMA的基本配置,第四篇博客主要想介绍Labview端上位机和下位机端的报文定义和通信等。

       当笔者工作上刚接触到STM32 IAP升级的时候,实事求是地说存在各种各样的困惑,所以这也是驱动我去撰写博客的动力,有很多CSDN朋友看过“FPGA基础知识”和“FPGA 20个例程”专栏后私信说写得接地气,让读者很容易接收和理解。学习都是从不懂到懂,从不理解到慢慢理解,而这个过程没有人指点的时候会非常痛苦。

     当然上面都是题外话,下面就站在工程落地的角度去想想STM32 IAP升级在具体实施中的几个问题,其实这也是当初困扰笔者的问题,主要它们也有很多共性吧。

  1. IAP升级需不需要特殊上位机的支持,网络上说法不一有很多教程说用串口助手选择本地的bin文件发送即可;
  2. IAP升级中上位机需要做什么操作,直接把bin文件一次性地发送下去就可以吗;
  3. IAP升级中下位机需要做什么操作,把收到的bin文件按十六进制数计数重新写入扇区就可以吗;
  4. 在没有本地显示屏GUI界面的情况下,用户怎么通过上位机告知下位机是跳转到Bootloader还是跳转到ApplicationBootloaderApplication之间应该怎么切换;

      首先回答第一个问题,IAP升级需不需要重新设计一个上位机,有些串口助手确实支持打开bin文件并将其按照十六进制数据格式发送,如果仅仅满足教学实验来说,完全可以用串口助手直接发送,但是现实当中串口通信是不可靠传输,即可能存在干扰等导致传输数据错误,这种没有校验和重发机制的方法发送bin文件显然没有可靠性而言;

       其次回答第二个问题,如果上位机直接把bin文件一次性发送到下位机端,下位机则需要去一个个字节接收再去计数数据,然后按照1024字节去写入一个个flash扇区,如果在传输过程中下位机计数错误了,导致flash数据写错将无法处理,所以显然一次性把一整个bin文件串口直接发送下来不是非常稳妥;

      再次回答第三个问题,假设每次要更新的bin文件有大有小,这一次更新的没有上一次的大,而上一次存在flash扇区的数据没有擦除干净可能存在风险,所以更建议每次进行IAP升级前从Application初始化地址起擦除完全;

     最后回答第四个问题,BootloaderApplication可以理解成两段独立的程序,显然同一时刻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:打包发送applicationbin文件内容

     0x02:发送完所有applicationbin文件内容,通知下位机从bootloader模式跳转到application模式

     0x03:检测application是否存在

      0x04:通知下位机从application模式跳转到bootloader模式

STM32 10个工程篇:1.IAP远程升级(四)_第1张图片

图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),

 

你可能感兴趣的:(STM32,10个工程,stm32,单片机,嵌入式硬件)