1. Foreword

         SCM APP upgrade of IAP functional foundation development (II) When it comes to the specific design scheme for the single chip microcomputer to upgrade the APP program, this article introduces the upgrade advanced function and how to automatically add the verification flag at the end address of the program after compilation (you can use the script tool, but what is introduced here is to add it after compilation in the program).

1.1 purpose

         What this paper writes is how to update the program in the single chip microcomputer without downloading. At present, it introduces the advanced design scheme of BootLoader of STM32.

2. Preliminary preparation

2.1 compilation process

First, let's understand the following process of C source code compilation: preprocessing - > compilation - > assembly - > link - > execute file

Pretreatment:     Expand header file / macro replace / remove comments / conditional compilation
compile:          Check syntax and generate assembly
Compilation:          Assembly code conversion machine code
Link:          Link together to generate executable programs

The compilation process of MDK is shown in the figure (borrowed from the Internet)

2.2. Distributed loading files

        ARM's linker provides a decentralized loading mechanism. When linking, the executable image file can be divided into specified partitions and located at the specified memory physical address according to the memory allocation scheme specified in the decentralized loading file (. scf file). In this way, when the embedded system is reset or powered on again, after initializing the corresponding registers of MCU, first execute the Bootloader code of ROM memory, and copy the corresponding code and data from the loading address to the running address according to the memory allocation scheme at the time of connection. In this way, the code and data located in RAM memory will run in RAM memory, Instead of fetching data or instructions from ROM memory, the running speed and efficiency of MCU are greatly improved.

Application scenario: sometimes users want to put different codes in different storage spaces, that is, the image file generated by the compiler needs to contain multiple domains, and each domain can have different addresses during loading and running. To generate such an image file, the compiler must be informed of the relevant address mapping relationship in some way (in MDK/ADS/IAR and other compilation tools, decentralized loading can be realized through decentralized loading mechanism. Decentralized loading is realized through configuration files, and such files are called decentralized loading files). There is no detailed introduction here, and those interested can baidu themselves (Zhou Ligong single chip microcomputer: a brief explanation of decentralized loading files. pdf).

3. APP engineering application

Only the settings of APP project are introduced.

3.1. Modify distributed loading file

Set the specified distributed loading file (copy the default file to the specified path, and then reselect it)

The default distributed loading file of STM32 is as follows:

; *************************************************************
; *** Scatter-Loading Description File generated by uVision ***
; *************************************************************

LR_IROM1 0x08000000 0x00080000  {    ; load region size_region
  ER_IROM1 0x08000000 0x00080000  {  ; load address = execution address
   *.o (RESET, +First)
   *(InRoot$$Sections)
   .ANY (+RO)
   .ANY (+XO)
  }
  RW_IRAM1 0x20000000 0x00010000  {  ; RW data
   .ANY (+RW +ZI)
  }
}

It needs to be modified into the following contents, and the general information segment (code_info) and code end segment (CodeEndFlag) are added

; *************************************************************
; *** Scatter-Loading Description File generated by uVision ***
; *************************************************************

LR_IROM1 0x08000000 0x00080000  {    ; load region size_region
  ER_IROM1 0x08000000 0x00080000  {  ; load address = execution address
   *(.code_info, +First)
   *.o (RESET)
   *(InRoot$$Sections)
   .ANY (+RO)
   .ANY (+XO)
  }
  RW_IRAM1 0x20000000 0x00010000  {  ; RW data
   .ANY (+RW +ZI)
   *(.CodeEndFlag, +Last)
  }
}

3.2 definitions and declarations

Define the end flag in the program (when it is convenient to erase during upgrade, only the memory required by the upgrade program needs to be erased)

/* FLASH Partition check code */
#define FLASH_EFFECTIVE_VALUE           (uint32_t)0x5555AAAA

/**
  * @brief Flash Partition general content information structure definition
  */
typedef struct {
    uint32_t effective;                     /*!< Valid check code */
    uint32_t startAddr;                     /*!< Start address */
    uint32_t endAddr;                       /*!< End address */
    uint32_t reserve[13];					/*!< reserve */
} FlashComInfoType;

/* app Program FLASH partition program segment start / end address */
#define CODE_FLASH_START_ADDR			(uint32_t)Load$$ER_IROM1$$Base
#define CODE_FLASH_END_ADDR 				 (uint32_t)(Load$$RW_IRAM1$$RW$$Limit - 0x4) // -4 is caused by subtracting the size of the section(".CodeEndFlag")

extern uint8_t Load$$ER_IROM1$$Base[];         /* The starting address of the program in FLASH */
extern uint8_t Load$$RW_IRAM1$$RW$$Limit[];    /* End address of program in FLASH (Code + RO + RW) */

/** Flash Sector end flag */
static volatile uint32_t sg_appEndFlagend __attribute__((used, section(".CodeEndFlag"))) = FLASH_EFFECTIVE_VALUE;

/**
  * @brief  APP Code Flash sector information
  * @note   The following information is automatically stored in Flash with compilation,
  *         Since the system will not allocate space in RAM when running (the address is the address corresponding to Flash), it is read-only
  *         An error will be reported during external reference
  */
const FlashComInfoType gc_appFlashInfo __attribute__((used, section(".code_info"))) = {
        FLASH_EFFECTIVE_VALUE,
		CODE_FLASH_START_ADDR,
		CODE_FLASH_END_ADDR,
        {0}
};

3.3 compilation

After compilation, you can open the hex file for viewing (from the address, the start address is 0x0800000, the end address is 0x08000D38, and the end address is followed by the code end verification flag)

The memory diagram of the code is as follows:

4.4 application of Boot engineering code

Define the same structure in the boot code and point to the general content information structure of the Flash partition in the APP area through the structure pointer.

const FlashComInfoType *gc_pAppFlashInfo = (FlashComInfoType *)APP_CODE_FLASH_START_ADDR;

The end address of the code is obtained in the boot through the information of the APP. During the upgrade, it can be erased to the Flash segment where the end address is located. It is not necessary to erase all of them, so as to shorten the upgrade time. After the upgrade, when the APP jumps, check whether the flag of the end address of the APP code meets the expectation.