STMCU小助手
发布时间:2022-3-3 22:44
|
1 前言 本文根据 2017 年度广州 USB DFU 培训内容进行整理而成,主要目的是为了方便那些由于各种原因未到现场参加培训的碟粉们参阅学习。本文主要是介绍如何使用 CubeMx 这个工具,一步一步制作一个 BOOT(DFU)程序,并使用它来升级用户 APP程序,这种应用场合在产品开发中具有普遍性。 2 实验环境介绍 2.1 实验目标
如上图,本实验主要目的是制作 BOOT 程序,并通过 BOOT 来升级用户的 APP 程序,上图是 BOOT 和 APP 在 MCU 内部FLASH 的位置示意图。当然,我们也将简单的介绍这个用户 APP 需要注意哪些方面。 注:这里我们将使用 USB DFU 作为 IAP 的这个程序叫做 BOOT 程序,功能与内置 BootLoader 类似,主要负责升级 APP 或直接跳转到 APP 去运行(MCU 内置 BootLoader,为了与其区分,这里取名为 BOOT,后面不再解释)。 2.2 实验环境及 STM32F072-Discovery 板简介 硬件平台: STM32F072 Discovery 板一块 Mini USB 线两根 PC 一台 软件准备: IAR V6.7.0 或者以上版本 STM32CubeF0 V1.7.0 STM32CubeMX V4.19 DfuSeDemo(V3.0.5)
3 制作 BOOT 工程 3.1 了解 MCU 内部 FLASH 的组织结构
如上图,BOOT 程序位于内部 FLASH 的起始位置,其后跟着的 APP 程序假设放在 0x0800 7000 的位置。也就是说前面0x7000 的空间用来存放 BOOT。 在制作 BOOT 程序之前,首先我们必须得先了解目标 MCU 的内部 FLASH 结构,这个是与我们的 BOOT 程序相关的,因为不同的 MCU 类型其内部 FLASH 组织结构不尽相同,尤其在擦除 FLASH 的时候,我们必须得知道擦除是以页为单位还是以扇区为单位,以及总共有多少个单元,每个单元多大等等。 这里我们实验的目标 MCU 为 STM32F072RBT6,打开其参考手册,得到其内部 FLASH 的组织结构如下图所示:
从上图我们可以得到如下信息: 1> 内部 FLASH 起始位置 0x0800 0000,结束位置 0x0801 FFFF; 2> 总共有 64 个页(0~63),每页大小 2K,共 128K 大小; 3> 擦除 FLASH 是以页为单位。 3.2 制作 CubeMx 工程 下面我们来从零开始为这个 BOOT 程序制作一个 CubeMx 工程,在选取 STM32F072RBx 作为目标 MCU 后,使能 USB_FS外设,并将 PA0 设为 GPIO_Input 模式,PA0 对应着 STM32F072-Discoery 板上的用户按键,我们将在程序中根据 PA0 管脚的电平状态来判断是否直接跳转到 APP 还是进入到 DFU 模式,准备升级用户 APP 程序。
接下来是时钟树配置:
如上图,我们使用内置 HSI48RC 作为高速时钟源,主频配为 48MHz,另外需要注意的是,USB 外设必须给它提供固定的48M 时钟源。
如上图左边,为 USB Device 配置 DFU 子类。然后点击右侧中间件下的 USB_DEVICE 配置,弹出如下对话框:
如上图红框中所示,USBD_DFU_APP_DEFAULT_ADD 为用户 APP 程序的默认起始位置,这里设置为 0x0800 7000, 即0x0800 0000~0x0800 7000 之间的空间,都可以用来放 BOOT 程序。USBD_DFU_MEDIA_Interface 为 DFU 媒介接口,也就是 MCU 内部 FLASH 的组织结构,这里用字符串表示,其值为: @Internal Flash /0x08000000/09*002Ka,55*002Kg; @Internal Flash: MCU 内部 FLASH 在 DfuSeDemo 这个 PC 软件中显示的字符串名,这里显示为”Internal Flash”;/0x08000000 : 内部 FLASH 的起始位置为 0x0800 0000 ;/09*002Ka : 9 个只读单元,每个单元大小为 2K,后缀 a 表示只读,一般用来放置 BOOT 程序 ;55*002Kg : 55 个可读写单元,每个单元大小为 2K,后缀 g 表示可读写,一般用来表示用户 APP 空间。 BOOT 程序通过这个一个带某种特殊格式的字符串来告诉 PC 端主机的上位机软件 DfuSeDemo,当前连接的 MCU 内部FLASH 的组织结构,这个字符串的表达方式,是通过 BOOT 程序与 PC 端软件 DfuSeDemo 预先约定好的。最终在DfuSeDemo 这个 PC 端软件可以显示当前连接 USB 设备 MCU 内置 FLASH 的结构,这个在后续将会介绍到。 最后生成代码时设置下堆栈大小:
如上图,我们设置 BOOT 程序的堆为 0x500,栈大小为:0x2000; 并生成 IAR 工程。 3.3 完善 BOOT 工程 生成的 IAR 工程如下所示:
CubeMx 工具已经自动帮我们生成了大部分代码,绝大部分我们都不需要修改,我们主要是根据 STM32F072 这款 MCU 内部FLASH 本生的一些特性来修改 usbd_duf_if.c 源文件,其次,根据应用上的一些特点,我们稍微修改下 main 函数,使其达到我们需要的结果。这些我们都将逐步在后续介绍。 3.3.1 usbd_dfu_if.c 源文件的修改 usbd_dfu_if.c 源文件主要是实现对 FLASH 的一些操作,主要有这些操作:
CubeMx 自动生成的 usbd_dfu_if.c 源文件中对这些函数都已经生成了大概框架,用户只需要完成其具体实现内容即可,这好比做填空题一样。 初始化:
在初始化函数中,完成对 FLASH 的解锁。 反初始化:
对应的,在反初始化函数中,恢复 FLASH 的锁定状态。 擦除 FLASH
需要注意地是,这里擦除的是指擦除整个 APP 所在的空间,因此,将会擦除掉 page8~63 的所有内容。 上述函数用到的一些宏定义如下:
写 FLASH
读 FLASH
获取状态
上面函数中用到的一些宏如下定义:
上述函数接口的具体实现是根据具体 MCU 的特点来实现的,若换成其他类型的 STM32,则需要根据当前的 STM32 型号做相应修改。如此,usbd_dfu_if.c 源文件就修改完了。 3.3.2 main 源文件修改 在 main 函数内,我们需要根据外部用户按键的状态来判断是否跳转到 APP 还是停留在 BOOT 程序内并准备对 APP 进行升级。 Main 函数修改如下:
上述代码中:
这行代码是判断 FLASH 中是否存在 APP 程序。它的判断原理是这样的,若存在 APP,则 USBD_DFU_APP_DEFAULT_ADD 这个地址保存的是栈顶指针 MSP,栈指针肯定是指向内存的,而内存有效地址分为0x2000 0000 起始的 128K 范围内。 & 0x2FFE0000 的意思是将 MSP 的值过滤掉低 17 位,17 位二进制刚好表示 128K 空间范围,也就是说,只有 MSP 的值指向SRAM 的 128K 有效范围内时,才是合法的,此时则表示 APP 存在,否则,APP 不存在。
跳转地址为 APP 起始地址+4,因为前 4 个字节表示的是 MSP 的值。所以接下来有如下初始化 MSP 的操作:
到此,BOOT 程序已经完成了。 4 制作 APP 工程 制作 APP 的过程我们也讲一下,因为有些地方还是需要注意下。 我们再次回顾下 BOOT 与 APP 在内部 FLASH 中的位置:
如上,用户 APP 是放在起始位置为 0x0800 7000 的位置,当然这个位置是示例,实际工程中用户得根据自己的情况来设置,比如 BOOT 实际大小多少,那么 APP 肯定得放在 BOOT 之后,绝对不能有重叠的地方,第二个,APP 的起始位置一定要放在 Page 起始的地方,因为 STM32F072 内部 FLASH 擦除是以 Page 为单位的,换做其他 MCU,比如 STM32F407,则擦除是以 SECTOR 为单位,且每个 Sector 的 SIZE 不尽相同,那么这个 APP 的起始位置一定要注意放在 Sector/Page 起始的位置。 下面我们一步一步详细介绍 APP 的创建过程,以一个简单的 LED 灯 Toggle 的例程向读者介绍用户 APP 的方方面面。 4.1 使用 STM32CubeMx 制作 APP 工程
如上图,在 Pinout 中设置 LED1~4 的四个管脚为 GPIO_Output 输出模式。
时钟树设置还是配置内部 48M 专用晶振为时钟源。
然后直接点击生成代码。 4.2 完善代码与工程配置 下面我们完善下代码: 在 main 函数中,我们让 LED 等闪烁起来:
然后在 IAR 的链接选项内配置中断向量表的位置以及 APP 在内部 FLASH 的起始位置:
然后我们得将中断向量表重映射到 SRAM 中:
在 main 函数中进行重映射:
讲到这里,相信很多读者可能存在疑问,为什么这里一定要这么重映射到 SRAM?这个是应为 M0 内核的 MCU 没有 VTOR这个寄存器,当存在 BOOT 时,APP 中原先本来应该位于 0x0800 0000 这个位置的中断向量表被 BOOT 占据了,那么 M0 内核在运行后怎么找到偏移到 0x0800 7000 位置的中断向量表的呢? 在 M3/M4 内核的 MCU 中,是存在 VTOR 这个寄存器,M3/M4 内核启动后会根据 VTOR 寄存器的值来寻址中断入口,但 M0由于缺少这个寄存器,那么我们就将中断向量表整个搬到 SRAM 中,再重映射到 SRAM,这样一来,M0 内核在启动后将不再从内部 FLASH 寻址中断入口,转而从 SRAM 中寻址,这样 APP 的中断就能一样正常响应了。换句话说,如果 APP 不进行重映射,那么一旦中断产生,那么内核还会从内部 FLASH 0x0800 0000 的地址中去寻址中断入口,这不成了 APP 的中断在 BOOT 中执行么?很明显,会出现错误直接导致崩溃。这就是为什么要重映射的原因。 5 制作 DFU 文件 后续我们将演示如何使用 BOOT 来对 APP 进行升级,我们将使用到一个 PC 端软件 DfuDemo 来实现这个过程,这个DfuDemo 软件只能识别固定了后缀名为 dfu 格式的文件,因此,首先我们需要将 APP 程序转化成 dfu 文件。 5.1 生成 HEX 文件 我们先将 APP 程序生成 hex 格式文件:
如上图所示,在 IAR 中先设置生成 HEX 格式文件,最后我们将得到后缀名为 hex 的文件。 5.2 将 HEX 文件转成 DFU 文件 然后使用 DFU File Manager 软件将 hex 文件转成 dfu 文件:
最终转为 dfu 文件:
6 使用 BOOT 烧录 APP 首先,我们预先将 BOOT 工程烧录进 STM32F072-Discovery 板。在连接 USB 线到 PC,打开 DfuDemo 这个软件,在导入APP.dfu 这个转化好的 dfu 文件并开始烧录。
如上图所示,原先在 CubeMx 中对 USBD_DFU_MEDIA_Interface 的字符串设备将在 DfuSe Demo 这个 PC 端软件的 Flash结构中显示出来,字符串与显示结构的对应关系如上图标志。 烧录完后进行验证 :
如上图,烧录 APP 完成后验证是通过的,LED 能正常闪烁。 7 注意事项 1. BOOT 本身实际所占 FLASH 空间不能与 APP 空间有重叠,即 BOOT 不能超过 USBD_DFU_APP_DEFAULT_ADD 所表示的地址; 2. BOOT 本身实际所占 FLASH 空间必须在 string 所表示的只读地址范围内;而 APP 也必须在 string 所表示的可读写地址范围内; 3. USBD_DFU_APP_DEFAULT_ADD 必须向 Page/Sector 的位置对齐,即向可擦除单元块对齐。 4. 对于 Coretex-M0 核的 MCU,由于没有 VTOR 这个寄存器,APP 若不在默认地址 0x0800 0000,则必须将中断向量表重映射到 SRAM,APP 才能正常工作,对于 M3/M4/M7 核的 MCU,在 APP 内则修改 VTOR 这个寄存器即可。 5. 有些 MCU 内置 BootLoader 也是支持 DFU 模式,也是可以通过 DfuSeDemo 这个软件配合升级用户程序,它的通信协议与本文所述并没有太大差异,只不过本文所述内容为 IAP 方式,而那个是属于 BootLoader 方式,这个读者注意区分下,读者可以通过参考应用笔记 AN2606 了解详情。 |
【源码】STLINK-V3MINI 高速USB仿真器,成功改刷【高速CMSIS-DAP】
STM32 USB CDC 虚拟多串口
实战经验 | 选择USBX模块生成USB CDC ACM无PD的项目
最全USB HID开发资料,悉心整理一个月,亲自测试
STM32 USB HID键盘例程
刘氓兔的杂谈【001】-片上USB 高速PHY
【经验分享】在进行 USB CDC 类开发时,无法发送 64整数倍的数据
在线直播|无需编写任何代码即可在STM32上实现USB-C Power Delivery
圈圈发布USB图书第二版有感,以及分享一些我学习USB过程...
USB Audio设计与实现
微信公众号
手机版