MIT License

技术解读

以下内容由 GitRead 中文社区 编辑团队基于项目 README 与官方资料整理, 结合中文开发者的常见使用场景补充技术选型建议。具体以项目官方文档为准。

GitHub 仓库深度技术分析:stm32-bootloader

项目背景与痛点

STM32 微控制器因其高性能、低功耗及广泛的适用性,在嵌入式系统中得到广泛应用。然而,产品迭代周期中常常会遇到固件更新的需求,同时期望减少更新过程中的复杂性和风险。传统的串行线调试(SWD)或JTAG接口更新方法不仅需占用相应的调试工具,而且在一些极端情况下,如更新过程中的意外中断可能会导致设备进入无法恢复的状态。因此,通过简单的 UART 接口实现安全、便捷的固件更新技术应运而生。

ferenc-nemeth/stm32-bootloader 项目正是致力于解决这一痛点。它提供了一种通过 UART 接口进行固件更新的方案,极大地方便了用户,降低了因繁琐的更新操作导致的风险。在开发和生产环境中,该方案可以通过简单的串口通信实现对设备的固件更新,提高开发效率,减少现场更新的复杂性。

核心技术揭秘

该项目的核心在于实现一个稳固的 UART 引导加载程序(Bootloader),以确保可靠的固件更新过程。其架构设计简洁明了,有效平衡了可靠性和低资源消耗的需求。以下是其核心架构和技术栈概述:

graph TD A[UART通信] --> B[接收Firmware文件] B --> C{"校验Firmware?"} C -->|"通过"| Z1[D[ ]擦除旧固件"]" D --> E[写入新固件] E --> F[跳转到新固件] C -->|"失败"| H[返回错误]
  1. UART 通信:Bootloader 通过 UART 接口与外部设备(如PC)进行通信。通信协议类似于XMODEM,简单但可靠。
  2. Firmware 接收:外部设备通过 UART 将新的固件文件传输给 Bootloader。每一次传输包含一个小的数据包,并且具有校验机制,确保数据的完整性。
  3. Firmware 校验:Bootloader 接收到数据包后进行校验。通过检查数据包的大小和内容完整性来确保有效性。如果任何数据包出错,整个固件更新过程会被中止,从而避免了不完整或损坏固件被加载的风险。
  4. 擦除旧固件:校验通过的固件文件会被临时存储在RAM中。Bootloader随后会擦除STM32微控制器的旧固件段。
  5. 写入新固件:擦除操作完成后,Bootloader将新固件写入存储区,并进行校验保证正确性。
  6. 跳转到新固件:如果整个流程无误,Bootloader会跳转到新固件的入口点,启动新固件执行。

该技术栈在整个处理流程中保证了高效的资源利用与操作安全性,有效减少了设备不稳定运行的风险。

功能亮点与差异

相较于常见基于 SWD 或 JTAG 接口的固件更新方式,stm32-bootloader 项目具体通过 UART 接口实现基于已加载固件的更新能力,可大幅降低更新过程中所需的工具复杂度,并将风险降至尽可能低的水平。这种设计巧妙地缩短了开发周期,允许可依靠最少开发工具的情况下随时进行固件更新。此外,项目提供了完善的文档和开源的代码库,便于社区成员进行二次开发和故障诊断,进一步增加了其灵活性和可用性。

应用场景与落地建议

stm32-bootloader 项目非常适用于那些希望简化固件更新流程的开发团队或产品制造商。适用于以下场景:

  • 产品处于迭代过程中,固件需频繁更新,需要确保更新流程效率高且无风险。
  • 在不具备复杂开发工具且需要远程更新的设备上,该方案尤其适用。
  • 常借鉴此项目作为固件更新的参考模型,实施快速迭代的研发项目。

需要注意的是,在实际应用中,考虑到安全性,用户应设置固件升级的权限控制,并确保通信链路的安全性。同时,考虑到更新过程中通信可能会受到的干扰,用户需建立重试机制以确保更新过程的可靠与完整性。

综合评价

ferenc-nemeth/stm32-bootloader 凭借其简单、可靠且高效的UART固件更新能力,显著降低了固件更新过程中的复杂性。这项目不仅为开发者带来了极大便利,也为嵌入式领域提供了一个开创性的更新方案。然而,它同样有其限制:UART更新速度相对较慢,且对通信可靠性有较高要求。总的来看,此项目是一项优秀的开源贡献,值得深入研究与利用。

关于

GitHub 原始描述(英文)

UART bootloader for STM32 microcontroller.

描述取自 GitHub 官方 API,保持仓库作者书写的原文。

语言占比

Assembly
C
C++

贡献者

README

stm32-bootloader

UART bootloader for STM32 microcontroller.

Table of contents

Introduction

A bootloader for STM32F100 (STM32VLDISCOVERY board) [1] with UART and Xmodem protocol [2][3]. The software is created with Atollic trueSTUDIO and the drivers are generated with CubeMX.

Main features:

  • UART & Xmodem protocol
  • CRC16 checksum
  • Supports 128 and 1024 bytes data length

How it works

Overall

The bootloader was developed for STM32VLDISCOVERY board, the only extra thing needed is an USB-UART module on PA10 (RX) and PA9 (TX) pins.


Figure 1. Pinout of the system.

After start-up, the system sends a welcome message through UART and checks if the user button is pressed. If it is pressed, then it stays in booatloader mode, turns on the green (PC9) LED and waits for a new binary file. If the button isn’t pressed, then it jumps to the user application.


Figure 2. Brief overview of the workflow of the system.

The Xmodem protocol is clearly explained in the references.

Memory map

The bootloader starts from 0x08000000 and the user application starts from 0x08008000.


Figure 3. The organization of the memory.

Code

Every important code is inside the Src and Inc folders. main.c holds the button check, xmodem.c and .h hold the communication portocol, uart.c and .h are a layer between Xmodem and the generated HAL code, flash.c and .h have the writing/erasing/jumping related functions. Everything else is provided by ST. The code is fully commented, so it should be easy to understand.

How to use it

Embedded

To use the bootloader, just get the softwares mentioned in the Introduction and flash it.

I included an example binary file called “blinky_test.bin” in the root folder. It blinks the blue (PC8) LED on the board. To make your own binary, you have to modify the memory location in the linker script (STM32F100RB_FLASH.ld):

FLASH (rx)      : ORIGIN = 0x8008000,

And the vector table offset in system_stm32f1xx.c

#define VECT_TAB_OFFSET  0x00008000U

Last step is you have to generate a *.bin file:

arm-atollic-eabi-objcopy -O binary "input.elf" "output.bin"
PC

To update the firmware, you need a terminal software, that supports Xmodem. I recommend PuTTY [4] or Tera Term [5].

Configure them in the following way:

  • Baud rate: 115200
  • Data bits: 8
  • Parity: none
  • Stop bits: 1

In PuTTY: select Files Transfer >> Xmodem (or Xmodem 1K) >> Send and then open the binary file.


Figure 4. PuTTY.

In Tera Term: select File >> Transfer >> Xmodem >> Send and then open the binary file.
Figure 5. Tera Term.

In case everything was fine, then the output should be the same:

================================
UART Bootloader
https://github.com/ferenc-nemeth
================================

Please send a new binary file with Xmodem protocol to update the firmware.
CCCCCCC
Firmware updated!
Jumping to user application...
Porting

I included the *.ioc file, so the drivers can be regenerated for any ST microntroller (if it has similar memory structure). If you have a non-ST microntroller, then the xmodem protocol can be reused, but nothing else.

References

[1] ST - Discovery kit with STM32F100RB MCU
[2] Xmodem protocol with CRC
[3] Chuck Forsberg - XMODEM/YMODEM PROTOCOL REFERENCE
[4] PuTTY
[5] Tera Term

评论

暂无评论