定制带U盘功能的bootloader实现拖拽下载固件

定制带U盘功能的bootloader实现拖拽下载固件

引言

我们在向一些非专业开发者发放开发板时，有时对方没有调试器，开发者就无法下载体验在后续发布支持新功能的固件。并且，对于非专业开发者的用户来说，仅仅是体验新功能，而不介入开发工作，专门搭建一套开发环境，性价比实在不高。即使有调试器硬件，在不同操作系统平台上，还需要安装专门的工具软件配合工作，才能实现下载固件的功能，操作比较繁琐。为了简化下载固件的操作，本例使用MM32F5270微控制器，基于芯片自带的USB外设，实现了一个基于U盘拖拽更新固件的解决方案。我期望实现的结果是：

• 将开发板同PC连接后，PC将识别出一个U盘
• 可将开发板的固件（bin 格式）文件拖拽存放至该U盘中
• 复位开发板后，开发板能够执行新的固件程序

相对于板载带有U盘拖拽下载功能的daplink方案，本例节约了一个专门运行daplink程序的芯片，利用微控制器自带的USB外设直接建立同PC的连接，更可有机会被实现成ROM，固化在芯片内部。

关于项目的源码及相关的资料，见Gitee站点：https://gitee.com/suyong_yq/mcu-udisk-bootloader

原理

MM32F5270片内集成了256KB Flash，但可通过QSPI接口外扩spiflash存储设备，并可在外扩spiflash中执行程序（XIP）。本例实际将运行bootloader的片内Flash当做BOOT ROM，而将可执行程序的固件存放在对接的spiflash存储介质中。当芯片上电后，通过一些外部控制手段（例如使用一个按键选择启动模式），先运行带有USB功能的bootloader程序，由bootloader的程序将芯片模拟成U盘（U盘的物理存储空间位于外扩spiflash的后半段）。PC可以看到模拟U盘中的现存文件，也可以向其中拖拽新文件。当拖拽新文件后，bootloader程序会继续将新文件的程序内容复制到程序的执行区域，覆盖掉之前的程序，然后再跳转到程序的执行区域执行程序。

这里专门使用一块物理存储区域（spiflash存储器的后半段）的原因是，USB协议栈模拟U盘时，对文件系统的管理操作全部交由PC完成，这就意味着，PC向模拟U盘发送包含文件内容的数据包时，不一定是按照物理上的先后顺序发送的，微控制器端难以通过数据包本身解析出数据包的先后顺序。但是，bootloader向程序执行区域复制可执行程序的内容必须是顺序且连续的。PC在同U盘的通信过程中，数据包之间的内容可能不连续，但最终发送完成的文件内容一定是完整的。因此，这里使用使用了一个能包含整个固件文件大小的区域作为缓冲区，先缓冲下来整个完整的文件，然后再将完整的文件内容按顺序复制到程序的可执行区域。

理想情况下，如果能用一块RAM作为整个文件的缓冲区，通过U盘拖拽下载过程将会非常快。但本例中使用spiflash作为缓冲区，虽然擦除spiflash并向其写入数据需要花费更多的时间，但能容纳更大的程序文件。

如果芯片内部集成足够大的片内Flash，也可以不依赖外扩spiflash，对内部的Flash做分区，分别作为bootloader、运行程序及文件缓存的存储区。

实现

硬件相关

本例使用BIRD-F5270开发板，开发板基本情况如下：

• 晶振 12MHz
• 使用QSPI接口对接外扩spiflash存储芯片FM25Q16（2MB Flash），引脚与MM32F5280片内合封所使用的引脚保持一致：
  • QSPI_NSS - PF6
  • QSPI_SCK - PG7
  • QSPI_D0 - PG6
  • QSPI_D1 - PF8
  • QSPI_D2 - PF10
  • QSPI_D3 - PG8
• USB 引脚
  • USB_DP - PA12
  • USB_DM - PA11
• 按键引脚
  • SW1 - RESET
  • SW2 - BOOT0
  • SW3 - PA0

软件相关

启动到2nd bootloader

芯片上电复位后，默认是直接执行到用户程序中，但也可以通过指定的手段改为执行bootloader，执行U盘程序。本例使用一个按键，绑定到一个指定的GPIO输入（BOOT引脚），芯片在启动过程中判定启动模式：默认启动到用户程序，当按键按下时，启动到带有U盘程序的bootloader。

MM32F5芯片自带的BOOT0引脚虽然在微控制器复位后可作为普通GPIO使用，但可能会将芯片引导到芯片内部已经固化到ROM中的bootloader程序中，因此不适合作为2nd bootloader的BOOT引脚。BIRD-F5270开发板上除RESET和BOOT0 之外，还有PA0引脚实现按键（SW3）功能，可作为2nd bootloader中的BOOT引脚。

当 SW3 被按下时，PA0 为低电平，可执行 U 盘任务，当 SW3 松开时，PA0 为高电平，可执行跳转程序的任务，具体实现代码如下：

/* read gpio pin level, select boot mode. */
if (GPIO_ReadInDataBit(BOARD_BTN_PORT, BOARD_BTN_PIN))
{
   
   
    /* update app & run. */
    jump_to_app();
}
else
{
   
   
    /* run usb msc task. */
    msc_task();
}

/* cannot run here. */
while(1)
{
   
   }

基于USB外设模拟U盘

MM32F5270微控制器集成了USB外设，配合TinyUSB协议栈，可模拟U盘（MSC设备）。

当运行模拟U盘的程序时，需要指定一块存储区域作为U盘的存储空间，在本例中，将外扩的spiflash存储区域一分为二，前半部分作为执行程序区域，存储需要执行的应用程序，后半部分作为U盘的物理存储空间，将用于缓存用户通过拖拽方式下载的固件。

注意，spiflash作为U盘的存储介质时需要解决一个问题，spiflash的最小擦除块大小是4KB，而U盘设备对存储介质的擦除块大小是512B，擦除块大小不匹配。该问题有两种解法：

• 每次修改spiflash前，先将包含目标操作空间的4KB大小的数据块读取数据到RAM中缓存，修改指定位置的数据内容后，擦除spiflash中对应的整块，再将修改后的数据块写入到spiflash中。
• 每次修改spiflash前，先将包含目标操作空间的4KB大小的数据块读取数据到RAM中缓存，修改指定位置的数据内容后，暂不写回到spiflash中。如果接下来要写入的数据仍在该块中，则继续写入RAM缓存。只有当将要新写入的数据不在缓存的数据块中时，才写回最近缓存的数据块，并读出新的数据块到RAM缓存中。另外，每次在写操作之后的读操作，也都会重新清空RAM缓存中的数据。

第一种方法简单易实现，但会频繁擦写spiflash，消耗存储器件的寿命。第二种方法相当于实现了一个cache机制，操作行为较为复杂。当前暂时选择第一种做法，先验证原理，如果后续考虑将这个带U盘功能的bootloader集成到芯片内部，到时也可以专门集成一块以512B作为操作单元的dflash作为固件的缓存存储设备。

运行TinyUSB协议栈的程序中，在执行MSC任务时，会执行对spiflash存储设备进行读写操作的回调函数，如下：

从spiflash读数据：

// Callback invoked when received READ10 command.
// Copy disk's data to buffer (up to bufsize) and return number of copied bytes.
int32_t tud_msc_read10_cb(uint8_t lun, uint32_t lba, uint32_t offset, void* buffer, uint32_t bufsize)
{
   
   
    (void) lun;

    uint8_t * addr = (uint8_t