Location>code7788 >text

Exploring the STM32's bootloader

Popularity：734 ℃/2024-09-03 15:15:34

OTA

  • OTA（Over-The-Air Technology (OTA) is a technology that allows devices to be upgraded remotely over a wireless network. This technology was initially used in the PC computer and cell phone industries, and in recent years it has been widely used in the automotive industry as well.

  • IAP: In-Application Programming (IAP) is anEnables microcontrollers (MCUs) to update their own firmware while the system is runningThis technology allows devices to be upgraded in the field without the need for a traditional programmer or debugger. This technology allows devices to be upgraded in the field without having to go through a traditional programmer or debugger.IAP is usually implemented by using the MCU's communication interface, such as UART, USB or CAN. In addition, it is also supported through various communication protocols such as Ethernet, Wi-Fi or cellular networks, and the bootloader is the code that implements this functionality.

    • Note that this is programmed at runtime。

  • XIP: burned to flash, executed directly on flash

  • Z-Modem: is aAdvanced file transfer protocol, primarily used for transferring files between computers, especially popular in the dial-up network and early Internet era. Compared to the X-Modem and Y-Modem protocols, Z-Modem offers higher transfer speeds, error recovery, and automatic file name and file size negotiation, greatly improving the efficiency and reliability of file transfers.

    Several key features of the Z-Modem protocol include:

    1. Automatic handshake and error correction: The Z-Modem is capable of automatic connection handshaking without the need for user intervention and is equipped with powerful error detection and correction mechanisms to ensure data integrity over noisy communication lines.

    2. high speed transmission: By using larger chunks of packets (up to 32K bytes), Z-Modem is able to transfer files faster than X-Modem and Y-Modem.

    3. Flow control and interrupt recovery: The Z-Modem supports bi-directional flow control and can dynamically adjust the data rate during transmission to suit current line conditions. In addition, it supports breakpoint continuation, so that even if the transmission is interrupted, it can continue from the point of interruption without having to restart.

    4. Automatic file name and orientation detection: The Z-Modem protocol automatically transmits file name and file size information, and the receiver can decide whether to accept the transmission. At the same time, it can automatically detect the direction of file transfer without the need for the user to specify sending or receiving.

    5. Transparent data transfer: Supports seamless transfer of binary files without the need to escape special characters, increasing the versatility of file transfer.

    Although protocols such as FTP, HTTP, and SCP are more common in today's network file transfers with the development of network technologies, Z-Modem is still valuable in some specific scenarios (e.g., retro computing, embedded systems, or unreliable network environments) due to its efficiency and robustness.

Summary of bootloader functions

image-20240614110342231

  • Simple bootloader: jump to app for execution
    • Complex bootloader: U-boot - initializes hardware, boots kernel, debugging role

First bootloader

vector of no anomalies (math.)

  • There are two programs, one program is the bootloader, which is burned where the flash starts, and the other is the app, which is burned where the bootloader jumps.

  • Function implemented: bootloader program initializes the serial port after power up, then jumps to the address of the app to run the print and print out the information.

  • Program Parsing:

    • Bootloader program bootloader

      image-20240618140132050

    • The bootloader's main function:

    • image-20240618140451538

    • The app's startup file：

      image-20240618141817621

    • app's main function：

      image-20240618142155527
      • The main function here needs to be set to mymain, we don't know that yet, we'll leave it to the

vector with anomalies (math.)

  • The bootloader's startup file remains unchanged, and the main function：

    image-20240618143157451

  • Startup files for the app：

    image-20240618143432009

Using assembly jumps

  • Why use assembly code for jumping?

    • The cortex-m3 uses a vector table mechanism, which records the entry points for exception handling. When an exception occurs, the hardware will automatically locate the exception entry for us from the vector table in memory.
    • When the processor is powered on and reset, the hardware removes the first two words from the vector table and assigns them to sp and pc.
    • Because we want our app program to still be written as usual, then we have to software implement theAssign values from app's vector table to registers such as sp, pc, etc.。

  • Program Parsing:

    • The bootloader's main function
    image-20240618155556690

    • Assembly file for bootloader：

      image-20240618155850839

Relocating vectors

  • Vector table offset registers using SCBsimage-20240618161004940, locates the address of the vector table to the address of the app.

  • Program Parsing:

    • The bootloader's main function:

      ​ image-20240618161630373

      ​

    • Assembly file for bootloader:

      image-20240618162337312

Second bootloader

  • There is a bootloader, after the hardware is powered up, the bootloader jumps to the app to run, and the app copies itself from flash to RAM to run.

Programs linking to any place have problems with absolute jumps.

  • Program Parsing:

    • When we link the app program into RAM.and the program uses absolute jump instructionsWhen the program is run directly from an address specified by, for example, a pointer assignment, the program is run from the address pointed to by the pointer, resulting in an inability to run.

    • Compilation file for app:

      image-20240622184403989

    • app's main function:

      image-20240619090917396

  • app's disassembly file:

    • Contact above to view

    image-20240619094537872

app copies itself to where it runs

  • Program Parsing:

    • The bootloader remains unchanged, still relocates the vector table address, puts the first vector table in the app to sp, and jumps to the second 0x08040009 of the vector table for execution
    • here areThe app copies a copy of itself into RAMIf you use an absolute jump, you will not get an error, but after the jump, you will still return to FLASH to continue execution, or you can use an absolute jump directly.
    • Compilation file for app:
    image-20240625150239828

    • app's main file:

      image-20240619104626844

  • Problems encountered:

    • In MDK, setting the link address to RAM does not allow you to download the program to ROM.
      • No algorithm was found for burning this program:

​ image-20240625151040322

  • Solution: You need to use another burning tool, such as STM32CubeProgramer

Third bootloader

  • The copying method can be used where the burn is not executable (XIP), e.g. we burn to an external SD card, spi-flash, etc. for large capacity devices

  • It's up to the bootloader to copy the program to ROM or RAM and then jump to the program to run it.

  • Three elements:

    • Source: SD card, external flash
    • Purpose: Link address
      • Fixed link address
      • app is flexible, we can put a header in front of the burned program, the bootloader parses this header and then copies it based on the information in the header
    • lengths

  • How to generate this header?

    • Using U-boot's tools, you can generate image files with headers.

    • . / -n "f103ZET6_app" -a(load address) 0x20000000 -e(entry address) 0x20000008 -d app_with_header.bin

  • Program Parsing:

    • bootloader main file:
image-20240619152021137image-20240619154901414
  • bootloader boot file:
    • image-20240619155722743
  • Problems encountered:
    • When copying a program to RAM to execute it is OK, but copying it to Flash will crash, the reason is that Flash is locked by default, to write to it, you need to unlock and erase it first.
    • The internal Flash is not operated by pointers like the SRAM, so it cannot be operated by pointers.

Fourth bootloder.

Modifies the address of the exception vector:

  • Hardware support, modify vector table address by relocating vector table registers

  • There is some hardware that does not support relocating vector tablesWhen an exception occurs, the exception vector table in the bootloader is still looked for.

    • What to do, point the exception vector in the bootloader to the app's exception vector

Framework for bootloader

image-20240622190838656

  • Use the idea of layering to abstract the layers
  • image-20240622190935743
  • image-20240622190948106

Porting the shell

  • What would it look like on a shell program on a microcontroller?
      1. It must be a dead loop waiting for input, and the input characters are deposited into the buffer
      2. We enter the keyboard, there will be displayed: the input characters through the serial line to the board, the board will then send the characters back to the PC to do back to the display
      3. Special character handling: delete key, up and down arrows to show history of commands, enter

command-line passing

  • int argc, char **argv are two typical variables used for command line parameter passing in C, usually seen in the definition of the main function. They are used to receive arguments from the command line when the program is started. Let's parse these two parameters one by one:

    1. int argc: This parameter represents the "argument count", i.e. the number of arguments passed into the program. It is an integer, always greater than or equal to 1. argc is at least 1 because the name of the program itself is treated as an argument (i.e. argv[0]). If no additional arguments are supplied by the user, argc will be equal to 1; the value of argc is increased by 1 for each additional argument.

    2. **char argv[]The argument represents an "argument vector", i.e. a pointer to a character pointer, which can also be interpreted as an array of strings. It contains pointers to each argument. Each pointer points to a string ending with a null character ('\0'), i.e., a string in C. argv[0] is usually the name or path of the program itself, argv[1] starts with the first user-supplied argument, and so on, up to argv[argc-1].

    For example, let's say you have a file namedmyProgramprogram, the user runs it by typing the following command at the command line:

    myProgram -f  -o

    In this example, theargcwill be 4, since there are 4 parameters in total (including the program name itself).argvof the following:

    • argv[0] directional"myProgram"
    • argv[1] directional"-f"
    • argv[2] directional""
    • argv[3] directional"-o"
    • argv[4] directional""
    • argv[5] is NULL, indicating the end of the parameter list.

    By parsingargcrespond in singingargv, the program can learn what parameters the user has supplied on the command line and how to adjust the behavior based on those parameters. This is the basis for writing command-line tools that can accept user input or configuration.

Implementing the bootloader

  • The flash is divided into two segments, the first is the bootloader and the second is the burn file containing the header information.
    • bootloader functions:
      • There is a shell that debugs, z-modem receives files transferred from the serial port
      • Load the program to an address for execution based on the header information
<Previous Next>