自学编程的网站,页面设计培训多少钱,全球知名电子商务网站统计,中国中建设计网站上面理论实践当初花了3天时间弄完的#xff0c;但是#xff0c;当你真正做项目的时候#xff0c;你会发现#xff0c;只有上面的这些知识还不够#xff0c;还有更多的细节要去处理#xff1a;APP程序怎么跳转到BootLoader程序#xff1f;APP程序和BootLoader之间是否会互…上面理论实践当初花了3天时间弄完的但是当你真正做项目的时候你会发现只有上面的这些知识还不够还有更多的细节要去处理APP程序怎么跳转到BootLoader程序APP程序和BootLoader之间是否会互相影响APP和BootLoader之间如何传递参数固件更新一到一半因为某种原因失败了通信错误、掉电该如何处理如何确保更新的APP是你需要的APP而不是别的一个APP经过一个项目的固件升级功能洗礼以上问题都得到了较好的解决为了避免以后忘记在此记录一下。芯片为STM32F103ZET6第一个问题APP程序怎么跳转到BootLoader程序看似很简单因为这是基本的功能但是实际情况并不简单。由前面的小节了解到从BootLoader跳转到APP可以通过指针进行跳转但是当你从APP通过指针跳转到BootLoader时发现会出现问题具体原因不明有机会的话去研究一下。那么又该怎么办可以通过复位的方式让程序重新从开始地址运行有以下几种方式复位内核复位系统复位上电复位第一、第二种方式都是通过设置相关寄存器使单片机发生复位的两者的区别就是内核复位只复位芯片的内核但对单片机的片上外设并不进行复位比如USART、SPI、USB等外设是不会进行复位的。系统复位的话就会对整个芯片进行复位不管是外设还是内核都会回到最初始的状态就如按下复位按键一样。最后一种上电复位其实和系统复位、按键复位的效果差不多都是会进行全部复位的不过这个需要外部硬件控制单片机的电源的开启与关闭增加了额外的硬件。一开始鱼鹰准备采用系统复位的直接设置寄存器触发导致复位因为这样更彻底测试发现项目中的单片机根本无法复位而我自己的开发板是能进行复位的后来经过硬件工程师的查找发现是看门狗电路导致无法复位这样一来系统复位这条路堵死了因为项目的硬件已经确定无法再更改了。那么是否有其它方法前面提到的指针跳转的方式发现会出现问题因为项目比较急就没怎么花心思解决。后来在调试过程中突然发现KEIL中的复位按钮是能进行复位的那么问题就简单了既然调试器能进行复位那我应该也能进行复位才对之前说了系统复位不好使那么按下复位按钮时应该是采用的内核复位实际上CMSIS-DAP调试器是有单独的一条复位线的但是当时没考虑它可能采用了这种方式只考虑可能采用了内核复位阴差阳错。那么就试试内核复位吧一试发现果然有效但是因为内核复位不彻底导致出现了问题。这就到了第二个问题两个程序之间是否会有影响第一首先从BootLoader对APP的影响考虑我们知道BootLoader程序也是需要一些资源的比如串口之类的用于固件的传输如果说BootLoader的寄存器和APP的寄存器配置要求不一样那么就可能出现问题鱼鹰的项目中还用了一个定时器喂狗发现一进入APP程序就挂了后来才找到这个原因。比如BootLoader采用串口查询的方式接收数据而APP为了提高效率使用DMA空闲中断的方式处理那么两者的寄存器配置肯定不同那么该怎么消除BootLoader程序对APP的影响呢有人说让BootLoader程序用完串口之后自动复位串口外设即可确实这是一种方法但是你是否考虑过两个程序是独立的万一后面的人在BootLoader程序中忘记了复位串口呢所以说靠别人不如靠自己与其担心害怕别人不靠谱不如APP自己去复位串口即APP在配置串口之前可以先复位串口再进行配置从这里可以知道为什么有些代码会使用XXX_DeInit()之类的函数在配置前复位片上外设一开始以为是多余的毕竟一般程序开始运行的时候一般都是上电之后才运行的这个时候已经复位外设了为什么还要多此一举直到现在才明白这才是安全的做法。第二从APP对BootLoader的影响考虑APP程序使用的资源一般比BootLoader的资源多如果两者之间使用了相同的资源比如串口那么肯定得考虑两者的差异性所以根据上面的考虑也可以让BootLoader程序在使用串口之前先进行复位然后再进行配置这是比较安全的做法。但是仅仅如此就足够了吗在项目里的APP程序中有一个加热过程如果说APP跳转到BootLoader之前没有考虑这一点就盲目的运行到BootLoader那么很可能出现APP正在加热但是因为跳转到了BootLoader中运行导致无法对温度进行控制那么结果将是灾难性的轻点的只是设备烧毁重的可能就引发火灾了。所以说两者之间的影响一定要慎重考虑。事实上如果采用系统复位或者上电复位的方式第二点关于APP对BootLoader的影响是可以不考虑的因为系统复位或者上电复位自动将外设进行初始化了但是你不能肯定你现在采用这些方式以后就不会采用内核复位的方式所以为了安全还是要考虑进去。现在说说第三个问题APP和BootLoader之间如何传递参数首先思考为什么要传递参数在前面的小节中选择让BootLoader程序在开始复位时等待一段时间再进入APP运行在等待的过程中就可以判断是否需要固件升级比如等待时由上位机发送一条特殊的命令确定是否升级或者通过引脚电平等方式反正就是要让BootLoader程序知道下面我要开始升级了别急着进入APP运行。但这里有一个问题就是这里需要一个冷启动的过程即先上电后再接收命令而且时间短暂有一个好处就是即使单片机中暂时没有APP程序也能够实现固件升级过程这样保证了由BootLoader接收升级命令而不是由APP接收所以当初在无法解决升级到一半时如何恢复时有考虑使用这种强制升级的方式。 那么有没有更好一点方式不需要冷启动过程而是由APP决定是否升级有的。既然是APP决定是否升级那么肯定需要在进入BootLoader之前给它传递一个参数告诉它这次复位需要升级不能直接跳到APP中运行那么BootLoader就会乖乖地等着升级了。那么怎么传递呢有人说往FLASH中写入参数这样复位的时候就可以判断是否需要升级了这确实是一个方法但是我们知道如果我们要往FLASH写入参数那么必须先进行擦除工作才行而擦除的往往是一个扇区为了写入几个字节的参数擦除几K的数据鱼鹰感觉实在是太浪费了还有这个参数保存地址也是需要好好考虑的放在APP区还是BootLoader区那么有没有更好的方式有的。还不只一种。一开始鱼鹰想到的是利用后备域保存参数因为如果有电池存在的话它的数据是不会丢失的但不巧的是这个项目没有这个功能。还有可以使用外部的FLASH空间有些FLASH芯片是可以进行字节编程的不需要整片擦除挺合适的。但是缺点就是你的项目要有这种芯片而你的BootLoader需要写相应的代码驱动这个芯片显然很麻烦。最后鱼鹰采用的是RAM传参。鱼鹰在之前的小节说过APP和BootLoader共用RAM如果说能用RAM传递参数的话只是操作一个变量相当方便。但是怎么保证两者之间顺利传递参数呢我们知道C语言申请的变量空间是由编译器自动分配的也就是说同样申明一个同名变量APP和BootLoader申请的变量地址不一定是一样的而且还有一点就是即使你申请的变量通过某些方法让它地址固定也会有问题因为申请的变量会在进入main函数之前会被初始化掉当然你可以说通过某种方式让它不被初始化但是鱼鹰想到了更好的方法。通过指针直接操作RAM空间最后几个字节用于参数传递之前有看到说STM32单片机中有个寄存器可以直接掉电不丢失但具体不知道是哪一个。因为采用指针操作所以编译器并不会对你指向的地址进行初始化这样可以很方便的绕过编译器的处理。其次通过操作最后几个字节保证了这个空间不会被程序的其他变量占用其实占用了也关系不大只要你传递的参数足够特别比如0x05055555就问题不大。这样BootLoader在复位后只要检查这个地址的值就可以轻松知道是否该升级了。但是还有一个隐患就是在上电那一刻如果这个地址的值刚好是你设置的特殊值因为上电后RAM的值是随机的那么必然会出现问题但这种可能性微乎其微因为要让四个字节在复位哪一刻刚好都变成你设置的特殊值简直比中彩票还要困难。不过即使你真的中彩票了重新上电复位一下就好了如果说第一次中彩票还能接受第二次还如此那就需要烧烧香、拜拜佛了。需要注意的是一旦使用完这个参数必须清零防止下次内核复位又进入升级了比如在线调试时可能会使用KEIL中的复位按钮。第四个问题固件更新一到一半因为某种原因失败了通信错误掉电该如何处理我们知道升级过程中很大可能是会失败的但是单片机升级不像电脑升级这次升级不成功恢复成原来的系统就是了。单片机空间有限没办法同时保存两份APP程序的那么又该如何处理呢现在换个角度思考你如何确定你升级失败了如果能做到这一点那么你的BootLoader程序就可以在升级失败后继续运行BootLoader的程序而不进入APP运行那只升级到一半的程序运行这种半残程序鬼知道会发生什么怪异事件呢。如果从这个角度来看其实就简单了只要上位机把bin文件的大小发下来然后由BootLoader程序判断是否升级完成就可以了而Ymodem刚好可以有这个功能。但是这样一来就出现了一个问题需要一个掉电不丢失的参数来保存是否升级成功否则下次上电又会继续运行APP。但是鱼鹰对整个扇区擦除的方式很反感就是不愿使用这种方式怎么办苦思冥想之下终于找到了一个巧妙的方式去处理。我们知道运行APP之前一般会对APP的前面8个字节的栈顶指针、复位地址的合法性进行判断判断是否是有效的APP程序毕竟随便拿一个程序去升级还不乱套了。不管怎样APP程序都是要往FLASH更新程序的那么我们是否能利用这个过程呢APP更新之前必定把该擦除的扇区进行擦除了如果说我们一开始就对写入的工作进行特殊处理那么是否可以达到我们想要的效果呢比如说前面8个字节本来是在一开始的时候就会被写入的如果我们在一开始写入数据的时候跳过这8个字节的写入然后把剩余的代码全部写入当判断已全部接收到大于等于bin文件大小因为Ymodem协议稍微有点特殊最后一帧数据可能填充0固件之后最后再对前面8个字节写入这样一来就保证了程序的完整性如果说你中途数据中断了掉电或上位机中断那么前面那8个字节肯定不会写入也就无法正常进入APP中运行了。第五个问题如何确保更新的APP是你需要的APP而不是别的一个APP前面的问题保证了更新的程序是完整的但是完整的程序不一定就是你需要的程序那么怎么确定是你需要的APP呢通过bin文件名来确定吗这是一个方法但是bin文件名可以被用户轻易更改那就只能从bin文件内容本身入手了。常规方法是通过某些工具在bin文件中加几个字节标着文件的特殊性但是众所周知的是鱼鹰比较懒看似简单的只是加入几个字节的事情如果产品成型的话比较好说更新次数比较少但是一旦产品处于测试阶段更新频繁累人不说还可能出错。那么有什么办法呢就从代码本身入手好了。方案确定下来了但是怎么处理呢标志位放在哪里怎么放又是一番苦思冥想。一开始想到的是想将标志位放在bin文件最后但是bin文件的大小是不固定的虽然说上位机可以把bin文件大小传下来但是怎么放是个问题开始打算通过修改链接文件实现但是发现自己对链接过程不熟对汇编语言汇编可以指定地址也不熟怎么办最终鱼鹰选择把程序标志放在向量表的后面即通过指定变量地址的方式保证地址唯一性需要注意一点的就是通过指定地址的方式不一定就确保最终的地址就是你设定的地址如果和其它地址冲突了的话可能不一致需要看map文件确定。而且在设置APP程序的时候一般都会重新定义向量表的位置那么可以在定义标志地址时利用这个地址进行偏移。当BootLoader在写前面8个字节前只要再判断这个地址的标志位是否正确即可。到此固件升级方面的知识应该比较完善了但还有一个问题如何对bin文件加密与解密呢这个问题只有下次项目需要的时候再研究了。------------------------------------------------------------------------------2019-06-30 Osprey喜欢就来关注鱼鹰吧如果对你有帮助点个赞再走呗
