Stm8s_IAP_Bootloader设计
stc8 bootloader 例程
文章标题:深入探讨STC8 Bootloader 例程1.引言在嵌入式系统设计和开发中,Bootloader 例程扮演着至关重要的角色。
STC8系列单片机作为一种常用的嵌入式芯片,其Bootloader 例程更是备受关注。
本文将深入探讨STC8 Bootloader 例程,从概念到实践,带您全面了解这一重要的技术。
2. 什么是Bootloader 例程Bootloader 例程,简称Bootloader,是一种在嵌入式系统中用于引导程序和初始化硬件的特殊程序。
在STC8单片机中,Bootloader 例程具有独特的设计和功能,可以实现固件更新、自主程序下载等重要功能。
考虑到STC8单片机在各类应用中广泛应用,Bootloader 例程的设计与应用显得尤为重要。
3. STC8 Bootloader 例程的特点STC8 Bootloader 例程具有以下几个突出的特点:- 稳定可靠:STC8 Bootloader 例程经过严格测试和验证,具有良好的稳定性和可靠性,可以满足各类应用的需求。
- 高度定制:STC8 Bootloader 例程支持用户自定义设置,可以根据具体应用的需求进行灵活配置,满足不同场景的需求。
- 易于集成:STC8 Bootloader 例程提供了完善的API接口和文档说明,方便用户在实际项目中快速集成和应用。
- 安全性保障:STC8 Bootloader 例程采用了多重安全机制,保障固件更新和程序下载的安全性,有效防止恶意攻击和非法篡改。
4. 深入探讨STC8 Bootloader 例程的实现在实际项目中,如何针对STC8 Bootloader 例程进行实现和优化是一个关键问题。
首先需要考虑Bootloader例程的整体架构和设计思路,具体包括Bootloader程序的存储器分配、引导流程设计、固件更新机制等方面。
其次需要考虑如何与应用程序进行有效的通信和数据传输,确保Bootloader 例程与用户程序的无缝衔接。
AN2659 STM8 in_application programming (IAP) using a customized user_bootloaderV4.1
November 2012Doc ID 14153 Rev 41/25AN2659Application noteSTM8 in-application programming (IAP)using a customized user-bootloaderIntroductionThis application note is intended for STM8 firmware and system designers who need to implement an in-application programming (IAP) feature in the product they are developing with the STM8 microcontroller.The STM8 is an 8-bit microcontroller family with a Flash memory for storing the user program code or firmware. IAP makes it possible to update the firmware ‘in situ’, after the microcontroller has been embedded in the final product. The advantage is that the microcontroller board can stay inside its product enclosure. No mechanical intervention is needed to make the update.IAP is extremely useful for distributing new firmware versions. It makes it easy to add new product features and correct problems throughout the product life cycle.The user-bootloader firmware source code provided with this application note shows an example of how to implement IAP for the STM8 microcontroller. Use this code as a reference when integrating IAP in your STM8 application. It includes the following features:●Bootloader activated by external pin (jumper on PCB)●Flash block programing by executable RAM code management ●Read while write (RWW) feature ●High level C-language usage ●Reduced size of the code (optimized code) ●Support for multiple communication interfaces (SPI, I 2C, and UART)●UART code compatible with ST Flash loader demonstrator software Table 1.Applicable productsProduct family Part numbersMicrocontrollers –STM8S003xx, STM8S005xx, STM8S007C8–STM8S103xx, STM8S903xx, STM8S105xx, STM8S207xx, STM8S208xx,–STM8AF6x26/4x/66/68, STM8AF5xxx, STM8AF6x69/7x/8x/9x/Ax–STM8L05xxx–STM8L101xx–STM8L151C2/K2/G2/F2 and STM8L151C3/K3/G3/F3–STM8L151x4, STM8L151x6, STM8L152x4, STM8L152x6–STM8L151x8, STM8L152x8, STM8L151R6, STM8L152R6, STM8L162R8,STM8L162M8–STM8AL313x, STM8AL314x, STM8AL316x, STM8AL3L4x, STM8AL3L6x–STM8TL5xxx Contents AN2659Contents1Operation theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52STM8 devices with built-in ROM-bootloader . . . . . . . . . . . . . . . . . . . . . 62.1Implementation details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2Adapting IAP master side to ROM-bootloader protocol . . . . . . . . . . . . . . . 73User-bootloader for STM8 devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.1User-bootloader firmware example description . . . . . . . . . . . . . . . . . . . . . 93.2Configuring the user-bootloader firmware example . . . . . . . . . . . . . . . . . 124Memory management for IAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.1Memory protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.1.1Flash memory protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.1.2User boot code protection (UBC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.1.3Vector table redirection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2Block versus word programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3RAM versus Flash programming code location . . . . . . . . . . . . . . . . . . . . 154.3.1Programming the data EEPROM area . . . . . . . . . . . . . . . . . . . . . . . . . . 154.4Library support for Flash programming . . . . . . . . . . . . . . . . . . . . . . . . . . 164.4.1Flash programming function list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Configuring the Cosmic compiler for RAM code execution . . . . . . . . 185.1Creating a segment in the STVD project . . . . . . . . . . . . . . . . . . . . . . . . . 185.2Creating a memory segment in the Cosmic linker file . . . . . . . . . . . . . . . 195.3Finishing and checking the configuration . . . . . . . . . . . . . . . . . . . . . . . . . 20 6Setting up your application firmware for user-bootloader use . . . . . . 227Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237.1Features in the final user-bootloader application . . . . . . . . . . . . . . . . . . . 23 8Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242/25Doc ID 14153 Rev 4AN2659List of tables List of tablesTable 1.Applicable products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Table 2.Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Doc ID 14153 Rev 43/25List of figures AN2659 List of figuresFigure 1.Typical bootloader application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Figure 2.Example of STM8S208xx bootloader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Figure 3.Example of user-bootloader implementation in the Flash memory. . . . . . . . . . . . . . . . . . . . 8 Figure 4.Example of the user-bootloader package provided . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Figure 5.Bootloader flowchart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Figure er boot code area and user application area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Figure 7.Define linker memory section in STVD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Figure 8.Setting the project start and vector table addresses in STVD . . . . . . . . . . . . . . . . . . . . . . 22 4/25Doc ID 14153 Rev 4AN2659Operation theory Doc ID 14153 Rev 45/251 Operation theoryIn practice, IAP requires a bootloader implemented in the STM8 firmware that cancommunicate with an external master (such as a PC) via a suitable communicationinterface. The new code can be downloaded into the microcontroller through this interface.The microcontroller then programs this code into its Flash memory.IAP can also be used to update the content of the internal data EEPROM memory, and theinternal RAM memory.This operation is useful when a microcontroller is already soldered in its final application andneeds a firmware update.Figure 1 shows a typical bootloader application.Figure 1.Typical bootloader applicationThe bootloader is that part of the code which runs immediately after a microcontroller resetand which waits for an activation signal (for example, from grounding a specific pin orreceiving a token from a communication interface). If activation is successful the code entersbootloader mode. If activation fails (for example due to a timeout or the jumper on the pin notbeing present) the bootloader jumps directly to the user application code.In bootloader mode, the microcontroller communicates with the external master devicethrough one of the serial communication interfaces available in it (UART, SPI, I 2C, CAN)using a set of commands. These commands are usually:●Write to Flash ●Erase Flash ●Verify Flash ●Additional operations such as read memory and execute code from a given address (jump to given address).The ST proprietary bootloader can be used. It is embedded in the ROM memory of STM8devices with a program memory greater than 8 Kbytes. In this case, no code development isneeded. To use the proprietary bootloader, enable it via the option bytes.Alternatively, develop a customized bootloader using, for example, a serial communicationinterface that is not supported in ST versions or in devices where the ST bootloader is notpresent. Such a bootloader should be stored in the user boot code area (UBC) in themicrocontroller. This guarantees protection against unintentional write operations.RS232RS232/TTLconverterSTM8 boardSTM8Bootloader enable PC jumper2 STM8 devices with built-in ROM-bootloaderMost STM8 devices have an internal bootROM memory which contains an ST proprietarybootloader. Consequently, they already have a built in IAP implementation (see UM0560:STM8 bootloader).details2.1 ImplementationThe built-in ROM-bootloader is located in a dedicated part of the memory called theBootROM. The ROM-bootloader code is fixed (not rewritable) and is specific for eachdevice. The communication interface supported depends on the peripherals present in thegiven STM8 device and whether they are implemented in the ROM-bootloader. For example,some devices support firmware download through UART/LIN and CAN, some devicessupport only UART, and others only SPI. Information concerning the supported interfacescan be found in the relevant device datasheet.Activation of the built-in ROM-bootloader is made by programming the BL[7:0] option bytedescribed in the option byte section of the device datasheet. The bootROM bootloaderchecks this option byte and if it is enabled, it runs its own code (it waits for the host to sendcommands/data). If the BL[7:0] option byte is inactive, the bootrom bootloader jumps to theuser reset address (0x8000).6/25Doc ID 14153 Rev 42.2 Adapting IAP master side to ROM-bootloader protocolTo be able to download firmware into the device, the host and bootloader must communicatethrough the same protocol. This bootloader protocol for STM8 devices is specified in theSTM8 bootloader (UM0560) user manuals available from . The sameprotocol is used in the firmware example provided with this application note. The UM0560user manual describes all bootloader protocol properties including used interfaces,timeouts, command formats, packet formats, and error management.Doc ID 14153 Rev 47/253 User-bootloader for STM8 devicesFor STM8 microcontrollers which do not include a built-in bootloader or which use acommunication protocol (I2C) not yet supported in the built-in bootloader, user-bootloaderfirmware can be added and customized at the beginning of the Flash memory.For this purpose, an example of a user-bootloader firmware is provided with this applicationnote. This package is divided into three main subdirectories, each one dedicated to oneSTM8 family member: STM8AF, STM8L and STM8S. For the STM8AL family, please usethe STM8L directory. Each directory is composed of the following components:●Sources: containing the firmware source code●Includes: containing the firmware header file (main.h). This file can be edited toconfigure your user-bootloader (see Section 3.2: Configuring the user-bootloaderfirmware example).●Flash_loader_demonstrator_files: contain all map files to add in the Flashloaderdemonstrator install directory to be compatible with the user-bootloader.●STVD: containing a prebuilt project for STVD using a Cosmic or raisonance compilerFigure 4 shows an example of the user-bootloader firmware.8/25Doc ID 14153 Rev 4Figure 4.Example of the user-bootloader package providedfirmware example description3.1 User-bootloaderThe basic program flow of a user bootloader application is described in Figure 5: Bootloaderflowchart.After a device reset, a selected GPIO can be used as a bootloader activation signal.Depending on its logical state (0 V or 5 V), the bootloader can be activated or not.The bootloader configures this GPIO as input mode with pull-up in order to detect anyvoltage variation. If the pin voltage level is zero (jumper present), the bootloader is activated.Otherwise, the bootloader jumps to the reset address of the user application (if this addressis valid).In the case of bootloader activation, the chosen communication interface is initialized. Atimeout count is then activated (i.e. 1 second). If, during this timeout, nothing is receivedfrom the given communication interface (UART, SPI, I2C) the bootloader jumps to the userapplication reset address.If the user-bootloader receive a valid activating token byte from the communication interfacebefore the timeout elapses, it then enters memory management mode to perform thefollowing operations:1.Initialize the Flash programming routines by copying the programming functions toRAM.2. Wait in a loop for a valid command to be received from the master3. Compute the received command (read, write, erase, version)4. If a Go command is received, the user-bootloader jumps to the address given in thecommand.All commands have a specified format and must be followed by both the user-bootloaderand the master. The command specification handles all possibilities and covers errormanagement.Doc ID 14153 Rev 49/25Several specific processing methods must be taken into account to achieve the appropriateaction in the memory using the bootloader. These methods are explained in Section 4:Memory management for IAP. They include:●Protection management●Code execution from RAM depending on memory write method (byte, word, or blockprogramming).10/25Doc ID 14153 Rev 4Doc ID 14153 Rev 411/25Figure 5.Bootloader flowchartReset IO pin groundedInit I/O pin (pull-up)Y es User application start Valid user reset vector?Received tokenin timeout interval?Perform commandWait for command from MasterGO command?(to run user code)Jump to GO address Parse commands- WRITE- ERASE- READ- VERSIONCopy write block routine into RAMCommunicationinterface init protocol No No NoNoY es Y esY es3.2 Configuring the user-bootloader firmware exampleThe provided package is configured for STM8S105xx devices with I2C protocol. Thepackage can be reconfigured easily, without any source code modification, by modifyinginformation in the main.h files (see package description).The configuration file is divided into three sections (see below). Each section can bemodified depending on requirements./* USER BOOTLOADER PROTOCOL PARAMETERS */This section is used to select a protocol. The user-bootloader firmware example supportsthree protocols: UART, I2C, and SPI. Only one protocol can be selected./* USER USER BOOT CODE Customisation */This section is used for defining byte values (acknowledge, non-acknowledge, andidentification), command numbers, and received data buffer structure./* USER BOOT CODE MEMORY PARAMETERS */This section is used to describe the memory configuration of the STM8 microcontroller. It ismandatory to set up some memory variables corresponding to the memory configuration ofthe microcontroller, for example, memory size, block size, EEPROM size, and addressrange. For more informations on these variables please refer to the appropriate devicedatasheet).12/25Doc ID 14153 Rev 44 Memory management for IAPprotection4.1 Memoryprotection4.1.1 FlashmemoryTo avoid accidental overwriting of the Flash code memory (for example in the case of afirmware crash) several levels of write protection are implemented in the STM8microcontroller family.After an STM8 reset, write access to the Flash memory is disabled. To enable it, firmwaremust write two unlock keys in a dedicated register. If the unlock keys are correct (0x56,0xAE), write access to the Flash memory is enabled and it is possible to program the Flashmemory using either byte/word or block programming mode. If the unlock keys are incorrect,write access to the Flash memory is disabled until the next device reset. After writing to theFlash memory, it is recommended to enable write protection again by clearing a specific bitin the Flash control register (to avoid accidental write). A similar protection mechanismexists for the Data EEPROM memory, with a specific unlock register and unlock keys (0xAE,0x56).code protection (UBC)boot4.1.2 UserAdditional write protection exists for the programming code itself, to protect the user-bootloader code from being overwritten during IAP. The STM8 family has a user boot code(UBC) area which is permanently write protected. This UBC area starts from the Flashmemory start address (0x8000) and its size can be changed by the UBC option byte (seedevice reference manuals and product datasheets). The boot code area also includes aninterrupt vector table (0x8000 to 0x8080). An important point to highlight in order to modifythe vector table via IAP, is that the main vector table should be redirected to another vectortable located in the rewritable application code area (see Figure 6). The only drawback ofsuch redirection, is the increase of the interrupt latency because of the execution of a doublejump.Doc ID 14153 Rev 413/25More detailed information about memory map of specific STM8 device type can be found inthe STM8 reference manuals and datasheets.redirectiontable4.1.3 VectorAs the initial interrupt vector table (address 0x8000 to 0x8080) is write protected by the UBCoption, it is mandatory to create another interrupt vector table to be able to modify it by IAP.Vector table redirection is performed in the following way:●The start of the user application area contains its own interrupt table with the sameformat as the primary interrupt table.●The primary interrupt table contains a set of jumps to the user interrupt table. If aninterrupt occurs, the user application is automatically redirected from the primaryinterrupt table to the user interrupt table by one jump.●The only requirement for the user application is that the user interrupt table must belocated at a fixed address. This is because the primary interrupt table is not rewritableand jumps to the user interrupt table at a fixed address value (see Section 6: Setting upyour application firmware for user-bootloader use).14/25Doc ID 14153 Rev 44.2 Block versus word programmingSTM8 microcontrollers contain a Flash type program memory where firmware can bewritten. There are two methods for writing (or erasing) Flash program memory:●Byte/word programming (1 or 4 bytes)–Advantages: offers small area programming, code can be executed directly on the Flash program.–Disadvantages: program stops during programming, programming speed is slow●Block programming (128 bytes or 1 Flash block for a given STM8 device)–Advantages: offers large area programming with high speed (large blocks)–Disadvantages: programming routine must run from the RAM (need to copyprogramming routine into the RAM).4.3 RAM versus Flash programming code locationDepending on the selected programming method (see Section 4.2: Block versus wordprogramming), the programming code must run from the RAM or from the Flash memory.If the programming code runs from the Flash memory, use only byte/word programming toprogram the Flash memory. During Flash memory programming, the code cannot accessthe Flash memory (the Flash is in programming mode). Therefore, program execution fromthe Flash is stopped during programming (for several milliseconds) and then continues. Thismode is useful in situations where only a small part (a few bytes) of the Flash memoryneeds to be updated or when it does not matter that programming is (very) slow.To program a large Flash memory area with optimum speed, block programming mode hasto be used. Block programming mode can be performed only by a code located in the RAM.First, copy the programming code into the RAM and then run (jump to) this code. The RAMcode can then use block mode to program the Flash. In this mode, programming one blocktakes the same time as programming one byte/word in byte/word mode. Consequently,programming speed is faster and code execution is not stopped (because it is running fromRAM). The only disadvantage of this method is the RAM code management:–Copying the executable code to the RAM–Storing the RAM code–Allocating RAM space for the code–Compiling the code to be able to run from the RAMdata EEPROM areathe4.3.1 ProgrammingFor data EEPROM programming, the programming code does not have to be executed fromthe RAM. It can be located in the Flash program memory, even if block programming isused. This read-while-write (RWW) feature speeds up microcontroller performance duringIAP. Only the data loading phase, the part of code which loads data into the EEPROM buffer,must execute from the RAM. However, during the physical programming phase, which takesmore time (several milliseconds), the code runs from the Flash while the data EEPROMmemory is programmed in the background. Completion of data EEPROM programming isindicated by a flag. An interrupt can be generated when the flag is set.Doc ID 14153 Rev 415/254.4 Library support for Flash programmingThe STM8 firmware libraries, available from , provide developed and verifiedfunctions for programming the Flash memory of every STM8 microcontroller family. Thefunctions support byte/word and block programming and make it easier for developers towrite their own programming code. The library also includes functions for managing theprogramming code execution from RAM. These functions are: copy to RAM, execution fromRAM, and storing functions in the Flash memory. They are contained in the following files:●\library\scr\stm8x_flash.c●\library\inc\stm8x_flash.hThese files contain the complete source code for Flash programming. Refer to the libraryuser manual “\FWLib\stm8s_fwlib_um.chm” for help using the STM8 library.4.4.1 Flash programming function listThis list gives a short description of the STM8S Flash programming functions (which are thesame for STM8AF, STM8AL, and STM8L devices):void FLASH_DeInit ( void)Deinitializes the FLASH peripheral registers to their default reset values.void FLASH_EraseBlock ( u16 BlockNum, FLASH_MemType_TypeDef MemType ) Erases a block in the program or data EEPROM memory.void FLASH_EraseByte ( u32 Address )Erases one byte in the program or data EEPROM memory.void FLASH_EraseOptionByte ( u32 Address )Erases an option byte.u32 FLASH_GetBootSize ( void )Returns the boot memory size in bytes.FlagStatus FLASH_GetFlagStatus ( FLASH_Flag_TypeDef FLASH_FLAG )Checks whether the specified Flash flag is set or not.FLASH_LPMode_TypeDef FLASH_GetLowPowerMode ( void )Returns the Flash behavior type in low power mode.FLASH_ProgramTime_TypeDef FLASH_GetProgrammingTime ( void )Returns the fixed programming time.void FLASH_ITConfig ( FunctionalState NewState )Enables or disables the Flash interrupt mode.void FLASH_Lock ( FLASH_MemType_TypeDef MemType )Locks the program or data EEPROM memory.void FLASH_ProgramBlock ( u16 BlockNum, FLASH_MemType_TypeDef MemType, FLASH_ProgramMode_T ypeDef ProgMode, u8 * Buffer )Programs a memory block.void FLASH_ProgramByte ( u32 Address, u8 Data )Programs one byte in the program or data EEPROM memory.void FLASH_ProgramOptionByte ( u32 Address, u8 Data )Programs an option byte.16/25Doc ID 14153 Rev 4void FLASH_ProgramWord ( u32 Address, u32 Data )Programs one word (4 bytes) in the program or data EEPROM memory.u8 FLASH_ReadByte ( u32 Address )Reads any byte from the Flash memory.u16 FLASH_ReadOptionByte ( u32 Address )Reads one option byte.void FLASH_SetLowPowerMode ( FLASH_LPMode_TypeDef LPMode )Select the Flash behavior in low power mode.void FLASH_SetProgrammingTime ( FLASH_ProgramTime_TypeDef ProgTime )Sets the fixed programming time.void FLASH_Unlock ( FLASH_MemType_T ypeDef MemType )Unlocks the program or data EEPROM memory.FLASH_Status_TypeDef FLASH_WaitForLastOperation ( FLASH_MemT ype_T ypeDef MemT ype )Waits for a Flash operation to complete.Note:The STM8 library package also contains examples that show how to use these functions in the final source code. Write your own code based on these examples.Doc ID 14153 Rev 417/255 Configuring the Cosmic compiler for RAM codeexecutionBlock programming must be executed from the RAM memory. Therefore, the code to becopied into the RAM must be compiled and linked to be run in the RAM address space but itis stored in the Flash memory.It is possible to write a simple programming code assembly, taking care with the RAMaddressing and then storing this code in the Flash (example, the code uses only relativeaddressing or RAM addresses). However, it is more efficient to use compiler support for thispurpose. Cosmic compiler support (described below) has these features built-in. Twoprocessing methods can be used:●Creating a segment in the STVD project●Creating a memory segment in the Cosmic linker file5.1 Creating a segment in the STVD projectThe first step to create a segment in the STVD project is to define one section in your code,example “FLASH_CODE”, and put your Block programming function inside. This is doneusing the following code:...//set code section to FLASH_CODE placement#pragma section (FLASH_CODE)void FlashWrite(void){...}void FlashErase(void){...}//set back code section to default placement#pragma section ()...The second step is to set the linker in your project settings window by clicking onProject>Settings, then clicking on access to Linker tab, and then selecting “input”category. In this way you can dedicate a memory area to your defined section,“.FLASH_CODE”, in the RAM . Option “-ic” must also be associated with this section (seeFigure 7: Define linker memory section in STVD).18/25Doc ID 14153 Rev 4Figure 7.Define linker memory section in STVD5.2 Creating a memory segment in the Cosmic linker fileThe second way to configure the Cosmic compiler for RAM code execution is to create aspecial memory segment which is defined in the linker file (*.lkf) and marked by the flag “-ic”.An example of a RAM space segments definition in the linker file is as follows:# Segment Ram:+seg .data -b 0x100 -m 0x500 -n .data+seg .bss -a .data -n .bss+seg .FLASH_CODE -a .bss -n FLASH_CODE -icThis example defines a RAM space from address 0x100. Firstly, the .data and .bss sectionsare defined. Then, the code defines a moveable .FLASH_CODE section where the routinesfor Flash memory erase and write operations are located. This section must be marked byoption “-ic” (moveable code).Into the marked “-ic” section, put functions which should be compiled/linked for RAMexecution but which are stored in the Flash memory. This is done in the source code bydefining a section as shown below:Doc ID 14153 Rev 419/25...//set code section to FLASH_CODE placement#pragma section (FLASH_CODE)void FlashWrite(void){...}void FlashErase(void){...}//set back code section to default placement#pragma section ()...5.3 Finishing and checking the configurationBy using either one of the above processes (Creating a segment in the STVD project orCreating a memory segment in the Cosmic linker file), the “FlashWrite()” and “FlashErase()”functions are compiled and linked for RAM execution (in the section “FLASH_CODE”) buttheir code is placed in the Flash memory (after the“.text” and “.init” sections). This can beseen in the generated map file:Example of final map file:--------Segments--------start 00008080 end 00008500 length 1152 segment .textstart 00000000 end 00000000 length 0 segment .bsctstart 00000000 end 00000003 length 3 segment .ubsctstart 00000003 end 00000098 length 149 segment .RAMstart 00000098 end 00000098 length 0 segment .sharestart 00000100 end 00000100 length 0 segment .datastart 00000100 end 00000100 length 0 segment .bssstart 00000100 end 000001F0 length 240 segment .FLASH_CODE, initializedstart 00008510 end 00008600 length 240 segment .FLASH_CODE, fromstart 00008000 end 00008080 length 128 segment .conststart 00008500 end 00008510 length 16 segment .initThe map file shows the location of the “FLASH_CODE” sections. One section is for storagein the Flash (it is stored in the map file marked “from”). The other section is for execution (itis stored in the map file marked “initialized”).Finally, the microcontroller firmware must copy these sections from the Flash to the RAMbefore calling the RAM functions. The Cosmic compiler supports this copying by a built-infunction “int _fctcpy(char name)” which copies a whole section from a source location in theFlash to a destination location in the RAM using the following code:20/25Doc ID 14153 Rev 4。
stm8 bootloader
3.4
Write memory command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.1 3.4.2 3.4.3 Write memory command via USART/LINUART/UART1/UART2/UART3 36 Write memory command via SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Write memory command via CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
UM0560 User manual
STM8 bootloader
Introduction
This document describes the features and operation of the STM8 integrated bootloader program. This code embedded in the system memory of the device (ROM memory) allows memories, g Flash program, data EEPROM, and RAM, to be written into the device using the standard serial interfaces LINUART/UART/USART, SPI, and CAN. The bootloader code is similar for all STM8 versions. However, even though a peripheral may be present in a product, the product may not support it (for example the SPI is not supported in 128 Kbyte devices). In addition, different STM8 device types support different peripherals (see Table 6: Serial interfaces associated with STM8 devices for detailed information). For further information on the STM8 family features, pinout, electrical characteristics, mechanical data and ordering information, please refer to the STM8 datasheets. Table 1.
STM8 Bootloader
自制Stm8 bootloader由于本人项目需要,要做STM8L052R8的bootloader,用于远程程序升级功能,为了安全考虑,不使用ST自带的bootloader,而是自制bootloader。
基本的功能是这样的,首先程序运行在一个V1.0的版本上,且带了BOOT,当程序收到一条命令后,程序跑入死循环,等待硬件看门狗复位;程序复位后进入bootload区,等待第二条命令的接收,接收到正确的数据帧后,bootloader开始擦除FLASH,并接收数据包,直到最后一个数据包接收完毕,通过指示灯以2HZ的频率闪烁,指示升级完成。
第一步:boot区程序设计,首先修改link文件,define region NearFuncCode = [from 0x8000 to 0xAFFF];define region FarFuncCode = [from 0x8000 to 0xAFFF];define region HugeFuncCode = [from 0x8000 to 0xAFFF];place at start of NearFuncCode { block INTVEC };以上是link文件部分,可以看出flash地址为0x8000开始,结束于0x17FFF; 长度为64kB,中断向量地址为0x8000,这样,知道了这个我们就可以修改BOOT程序的link和主程序的link了,这里我把BOOTLOAD区划分为8K,应用区为48K设置link文件如下,这样把boot区和APP区分开,互不干扰,你也可以根据需要调整他们的大小。
program:define region NearFuncCode = [from 0xB000 to 0xFFFF];define region FarFuncCode = [from 0xB000 to 0xFFFF]| [from 0x10000 to0x17FFF];define region HugeFuncCode = [from 0xB000 to 0x17FFF];place at start of NearFuncCode { block INTVEC };bootload:define region NearFuncCode = [from 0x8000 to 0xAFFF];define region FarFuncCode = [from 0x8000 to 0xAFFF];define region HugeFuncCode = [from 0x8000 to 0xAFFF];place at start of NearFuncCode { block INTVEC };像STM32这样的芯片中断向量地址可以任意定,所有boot区和APP区都可以使用中断,且互不干扰,但是STM8的中断向量表固定在0X8000地址,不能修改,所以BOOT 区不能开中断,否则会和APP区的中断打架,但是APP区的一但开启中断后就会跳转到0x8000地址,这样就跳到了BOOT区,因此需要使用跳转指令将中断跳回到APP区,__root const long reintvec[]@".intvec"={ 0x82008080,0x8200b004,0x8200b008,0x8200b00c, //当应用程序地址不是0xB000时则要相应改掉除第一个0x8200b010,0x8200b014,0x8200b018,0x8200b01c, //0x82008080以外的数值0x8200b020,0x8200b024,0x8200b028,0x8200b02c,0x8200b030,0x8200b034,0x8200b038,0x8200b03c,0x8200b040,0x8200b044,0x8200b048,0x8200b04c,0x8200b050,0x8200b054,0x8200b058,0x8200b05c,0x8200b060,0x8200b064,0x8200b068,0x8200b06c,0x8200b070,0x8200b074,0x8200b078,0x8200b07c,};这里大概的含义就是重定义STM8的中断,STM8中断向量重定义,至于这里为什么这样写,请网上自己去看,我也不是很清楚。
stm8 boot,app IAP双中断支持
重要,.s启动文件,设置地址跳转到固定的ram地址
2、APP flash地址设置为 0x9000地址。ram同样设置为 0x77f,对齐保护。0x780~0x800作为ram中断向量偏移缓存。
定义RAM缓存。 copy 0x9000 app中断服务函数的,地址 到 ram缓存中。 app的中断函数使用 官方 it.c文件
ห้องสมุดไป่ตู้
测试、 1、先烧写boot,,再烧写app,仿真看能不能进入中断。 boot使能跳转。
2、烧写boot代码。关闭跳转,看boot能不能正常响应中断。
stm8S105C6_Test…P.rar 2.57MB csv
Boot代码, 1、修改地址ICF文件 flash地址:
stm8 boot和app IAP双中断支持
RAM地址:0x800 - 128字节 = 0x077F。 link icf文件选择 当前工程目录下的icf文件。 定义一个 RAM 存放中断向量的缓存,
比如,tim4的中断服务函数 传入地址。0x82 代表指令跳转。 tim4中断的写法。
STM8S硬件电路设计注意事项
(西南办:028-8626 9815 015208108068)
STM8S 可以不需要晶振跟复位电路,但是为了最小系统能够稳定运行,所以最好增加 外部电路。 注意事项
(1)VCAP 电容引脚(STM8S103PX 是第 8 个管脚): STM8S 的 VCAP 管脚上的电容是一 个很特别的电容。它是 STM8S 的内核的工作电压。需要在外 部加一个外部的电容,以保 证内核工作电压的稳定。一般推荐 1uF 的瓷片电容。而且 1uF 的瓷片电容在进行 PCB 布线 时,必须要尽可能地靠近 VCAP 引脚,一直靠近到不 能再靠近为止。这一点非常非常重要, 切记!切记!(STM8L 系列上没有此电容)
(西南办:028-8626 9815 015208108068) 2、STM8 复位电路设计
STM8 单片机内置上电复位(POR),所以,STM8 单片机可以不设外部上电复位电路, 依然可以正常复位,稳定工作。 若是系统需要设置按键复位电路,那么注意,STM8 单片 机是低电平复位,如下图,设计按键复位电路:
只有一对。 注意:建议将VDD/VSS引脚旁的VDD_IO/VSS_IO与其连接到一起并且只使用一个退耦 电容。目的是减少VDD/VDD_IO 与电容的引线长度,以达到良好的噪声性能。 一对VDDA/VSSA (3.3 V ± 0.3 V to 5 V ± 0.5 V),专为模拟部分供电
亚太领先电子通路,16 年专业品质
பைடு நூலகம்
最小系统设计:建立一个STM8 最小系统必须要有以下几部分:
电源 复位电路 时钟 仿真与调试接口:SWIM(Single wire interface module,单线接口模块)连接 1、电源 芯片需要外部提供3.0V 到5.0V 的稳定电源。芯片内部的电源管理系统在正常工作和低 功耗模式下为内核提供1.8V 的参考电源。芯片能够监测外部(3V/5V)和内部(1.8V)电源掉 电。 芯片提供: 一对VDD/VSS 引脚(3.3 V ± 0.3 V to 5 V ± 0.5 V),连接到内部稳压参考电源 两对VDD_IO/VSS_IO (3.3 V ± 0.3 V to 5 V ± 0.5 V) ,专为I/O 供电。在32脚封装上,
STM8S启动程序用户手册(2008年12月)
UM0560User manualSTM8L/S bootloader 1 IntroductionThis user manual contains the bootloader specifications for STM8L/S devices which containa bootloader embedded in the system memory of the device (the ROM). Through thisfirmware, the device memory can be erased and programmed using one of the standardcommunication interfaces present on the particular device. For each device, please refer tothe corresponding datasheets to know if the bootloader is present and which peripherals aresupported by it.The document describes the features and operation of the STM8L/S integrated bootloaderprogram. This code allows memories, including Flash program, data EEPROM, and RAM, tobe written into the device using the standard serial interfaces UART, CAN, and SPI.The bootloader code is similar for all STM8L/S versions. However, even though a peripheralmay be present in a product, the product may not support it (for example the SPI is notsupported in STM8S20xxx devices). In addition, different cuts support different peripherals:for example, the bootloader code can be accessed via the UART1, UART3 and CANperipherals in STM8S20xxx devices, via the UART2 and SPI in STM8S105xx devices, andvia the UART only in STM8L15xxx devices.For further information on the STM8L/S family features, pinout, electrical characteristics,mechanical data and ordering information, please refer to the STM8L/S datasheets.November 2009Doc ID 14798 Rev 21/62Contents UM0560Contents1Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Bootloader introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1Bootloader activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Peripheral settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1UART settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1.1UART in “reply” mode settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2SPI settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3CAN settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Bootloader command set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.1Get command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.1.1Get command via UART1/ UART2/UART3 . . . . . . . . . . . . . . . . . . . . . . 144.1.2Get command via SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.1.3Get command via CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.2Read memory command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2.1Read memory command via UART1/UART2/UART3 . . . . . . . . . . . . . . 204.2.2Read memory command via SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2.3Read memory command via CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3Erase memory command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.3.1Erase memory command via UART1/UART2/UART3 . . . . . . . . . . . . . . 274.3.2Erase memory command via SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3.3Erase memory command via CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.4Write memory command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.4.1Write memory command via UART1/UART2/UART3 . . . . . . . . . . . . . . 344.4.2Write memory command via SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.4.3Write memory command via CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.5Speed command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.5.1Speed command via CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.6Go command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.6.1Go command via UART1/UART2/UART3 . . . . . . . . . . . . . . . . . . . . . . . 454.6.2Go command via SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2/62Doc ID 14798 Rev 2UM0560Contents4.6.3Go command via CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.7Sector codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505Software model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.1RAM erase/write routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 6Error management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 7Programming time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Appendix A How to upload ROP protected device . . . . . . . . . . . . . . . . . . . . . . . 57A.1Rules for upgrading ROP protected devices. . . . . . . . . . . . . . . . . . . . . . . 57 Appendix B Bootloader entry points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Appendix C SPI with busy state checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59C.1Modified erase/write RAM routines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Appendix D PC software support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Doc ID 14798 Rev 23/62List of tables UM0560 List of tablesTable 1.Initial checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Table 2.Serial interfaces associated with STM8L/S devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Table 3.Bootloader commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Table 4.Bootloader codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Table 5.Examples of delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Table 6.STM8L/S sector codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Table 7.Error table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Table 8.UART1/UART2/UART3 programming times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Table 9.SPI programming time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Table 10.CAN programming time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Table 11.Bootloader entry points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Table 12.Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4/62Doc ID 14798 Rev 2UM0560List of figures List of figuresFigure 1.Bootloader activation flow chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Figure 2.CAN frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Figure 3.Get command via UART1/UART2/UART3 - host side . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Figure 4.Get command via UART1/UART2/UART3 - device side . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Figure 5.Get command via SPI - host side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Figure 6.Get command via SPI - device side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Figure 7.Get command via CAN - host side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Figure 8.Get command via CAN - device side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Figure 9.Read memory command via UART1/UART2/UART3 - host side. . . . . . . . . . . . . . . . . . . . 20 Figure 10.Read memory command via UART1/UART2/UART3 - device side. . . . . . . . . . . . . . . . . . 21 Figure 11.Read memory command via SPI - host side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Figure 12.Read memory command via SPI - device side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Figure 13.Read memory command via CAN - host side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Figure 14.Read memory command via CAN - device side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Figure 15.Erase memory command via UART1/UART2/UART3 - host side . . . . . . . . . . . . . . . . . . . 27 Figure 16.Erase memory command via UART1/UART2/UART3 - device side. . . . . . . . . . . . . . . . . . 29 Figure 17.Erase memory command via SPI - host side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Figure 18.Erase memory command via SPI - device side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Figure 19.Erase memory command via CAN - host side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Figure 20.Erase memory command via CAN - device side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Figure 21.Write memory command via UART1/UART2/UART3 - host side. . . . . . . . . . . . . . . . . . . . 34 Figure 22.Write memory command via UART1/UART2/UART3 - device side . . . . . . . . . . . . . . . . . . 36 Figure 23.Write memory command via SPI - host side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Figure 24.Write memory command via SPI - device side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Figure 25.Write memory command via CAN - host side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Figure 26.Write memory command via CAN -device side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Figure 27.Speed command via CAN - host side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Figure 28.Speed command via CAN - device side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Figure 29.Go command via UART1/UART2/UART3 -host side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Figure 30.Go command via UART1/UART2/UART3 - device side. . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Figure 31.Go command via SPI - host side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Figure 32.Go command via SPI - device side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Figure 33.Go command via CAN - host side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Figure 34.Go command via CAN - device side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Figure 35.Delay elimination in modified RAM routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Figure 36."Flash loader demonstrator" software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Doc ID 14798 Rev 25/62Bootloader introduction UM05606/62Doc ID 14798 Rev 22 Bootloader introductionThe main task of the bootloader is to download the application program into the internalmemories through the integrated peripherals (UART1, UART2, UART3, SPI, CAN) withoutusing the SWIM protocol and dedicated hardware. Data are provided by any host which iscapable of sending the required protocol data through one of the required interfaces.The bootloader permits downloading of application software into the device memories,including the program memory, using standard serial interfaces. It is a complementarysolution to programming via the SWIM debugging interface.The bootloader code is stored in the internal boot ROM. After a reset, the bootloader codechecks whether the program memory is virgin or whether a specific option byte is setallowing code modifications.If these conditions are not fulfilled, the bootloader resumes and the user application isstarted.In case of a successful check the bootloader is executed.When the bootloader procedure starts, the main tasks are:●Polling all supported serial interfaces to check which peripheral is used ●Programming code, data, option bytes and/or vector tables at the address(es) received from the host.2.1 Bootloader activationThe STM8L/S hardware reset vector is located at the beginning of the boot ROM (6000h),while the other interrupt vectors are in the Flash program memory starting at address8004h.The device executes the boot ROM (jumps inside the boot ROM area) and after checkingcertain address locations (see Table 1: Initial checking on page 9), it starts to execute thebootloader or the user code defined by the reset vector (8000h).The bootloader activation flowchart is described in Figure 1: Bootloader activation flowchart .UM0560Bootloader introduction Doc ID 14798 Rev 27/621.See Flow chart description on page 8 for explanation of points 1 to 8.2.Dotted routines are loaded in RAM by the host. They are removed by the go command before jumping to the Flash program memory to execute an application.Bootloader introduction UM0560Flow chart description1.Disable all interrupt sources.2. The host can start the bootloader process according to checks shown in Table1 (inkeeping with the content of the first Flash program memory location (8000h) and“bootloader enable” option bytes). The host checks the following bootloader startconditions:Condition 1: the host checks if the device memory is empty by inspecting the content ofaddress 8000h (reset vector). If the content is not equal to 82h or ACh, the device isrecognized as being empty and the bootloader remains active and waits for hostcommands without timeouts.Condition 2: the host checks if the bootloader option bytes (two bytes) are set to enablethe bootloader or not. The bootloader is enabled with a value of 55AAh and disabled byall other values (see the device datasheets for the bootloader option byte locations). Ifthe option bytes are enabled, the bootloader remains active and waits for hostcommands with a 1-second timeout. If the host does not send a command within thistimeout, the bootloader jumps directly to the application user vector (jump to address8000h).Condition 3: If the option bytes disable the bootloader (by a value different from55AAh), the bootloader jumps directly to the application user vector (jump to address8000h).The above checking process is summarized in T able1.3. When readout protection (ROP) is active, the Flash program memory is readoutprotected. In this case, the bootloader stops and the user application starts. If ROP isinactive, the bootloader continues to be executed. (How to upload ROP protecteddevice with bootloader support - see Appendix A: How to upload ROP protecteddevice.)4. The CAN peripheral can only be used if an external clock (8 MHz, 16 MHz, or 24 MHz)is present. It is initialized at 125 kbps. The UART and SPI peripherals do not require anexternal clock.5. Set the high speed internal RC oscillator (HSI) to 16 MHz and initialize the UARTs RxDpins in input pull-up mode in the GPIO registers. Initialize the SPI in slave mode.6. Interface polling: The bootloader polls all peripherals waiting for a synchronizationbyte/message (SYNCHR = 7Fh) within a timeout of 1 s. If a timeout occurs,either theFlash program memory is virgin in which case it waits for a synchronizationbyte/message in an infinite loop, or the Flash program memory is not virgin and thebootloader restores the registers’ reset status and jumps to memory address given bythe reset vector (located at 8000h).Note: When synchronization fails (the bootloader receives a byte/message different to‘SYNCHR’ = 7Fh) two different situations can be distinguished according to theperipheral:With the UART peripheral, a device reset or power-down is necessary beforesynchronization can be tried again.With the CAN or SPI peripheral, the user can continue to poll the interfaces until asynchronization or a timeout occurs.8/62Doc ID 14798 Rev 2UM0560Bootloader introduction Doc ID 14798 Rev 29/627. If the synchronization message is received by the UART , the bootloader automaticallydetects the baud rate, initializes the UART, and goes to step 8 below. If thesynchronization message is received by the CAN or SPI, the bootloader goes directlyto step 8 below.Note: Once one of the available interfaces receives the synchronization message, allothers are disabled.8. Waiting for commands: Commands are checked in an infinite loop and executed. To exitfrom the bootloader, the host has to send a ‘GO’ command. When this is done, thebootloader removes the EM and WM routines from the RAM and jumps to the addressselected by the host.Note : To be able to write/erase data in Flash and EEPROM the host must write intoRAM executable routines for writing and erasing. Those routines (*.s19 files) areprovided with the bootloader. Host must upload those routines at address 0xA0. Seesection 5.1: RAM erase/write routines for more information.Some bootloader versions are not required to write executable routines because suchroutines are automatically loaded into the RAM from the Flash device memory whenthe bootloader starts. See Table 2.Note:After interface initialization, the ROP bit is checked to avoid non-authorized read operationsto the Flash program memory and data EEPROM.Table 1.Initial checking ChecksProgram memory location 8000h Bootloader check opt_bytes Actual Flash program memory status -> Flash action 1stXXh != (82h or ACh)XXXXh Flash program memory virgin. -> jump to bootloader 2nd XXh == (82h or ACh)55AAh Flash program memory already written, bootloader enabled by option bytes.-> jump to bootloader3rd XXh == (82h or ACh)XXh != 55AAhFlash program memory already written,bootloader disabled by option bytes.-> jump to Flash program memory resetPeripheral settings UM056010/62Doc ID 14798 Rev 23 Peripheral settingsThis section describes the hardware settings of the STM8L/S communication peripherals:●UARTs ●SPI ●CANNote:During bootloading only one (first addressed) peripheral is enabled. All others are disabled.Note:The above table reflects only current bootloader versions and device states.3.1 UART settingsThis peripheral supports asynchronous serial communication.The UART settings are:●Data frame: 1 start bit, 8 data bit, 1 parity bit set to even, 1 stop bit ●Baud rate: The baud rate is automatically detected by the bootloader. When the user sends the synchronization byte, 7Fh, the bootloader automatically detects the baudrate and sets the UART to the same baud rate. Maximum baud rate = 1 Mbps;minimum baud rate = 4800 bps.To perform the automatic speed detection, the RxD line must be stable in the applicationboard (internal pull-up is enabled on RxD line by bootloader).3.1.1 UART in “reply” mode settingsSettings are:●Data frame: 1 start bit, 8 data bit, 1 parity bit even, 1 stop bit ●Baud rate: The baud rate is automatically detected by the bootloader. When the user sends the synchronization byte 7Fh, the bootloader automatically detects the baud rateand sets the UART to the same baud rate. Maximum baud rate = 550 kbps; minimumbaud rate = 4800 bps.To perform automatic speed detection, the RxD line must be stable in the application board(by enabling the internal pull-up on the RxD line by the bootloader).Reply modeThe host must reply to all the bytes sent from the bootloader. If TxD and RxD lines share thesame physical medium (for example, 1-wire communication), then host replies are notnecessary since RxD and TxD pins coincide.Table 2.Serial interfaces associated with STM8L/S devicesDevice Serial interfaceSTM8S20xxxUART1, UART3 (in “reply” mode), CAN STM8S105xxUART2 (in “reply” mode), SPI STM8L15xxxUARTUM0560Peripheral settingsDoc ID 14798 Rev 211/623.2 SPI settingsThe SPI settings are:●8 data bit, MSB first●Bit rate: Set by the host which acts as a master ●Peripheral set in slave mode with NSS not used●Data polarity: CPOL =0 (SCK to 0 when idle), CPHA = 0 (the first clock transition is thefirst data capture edge).Note:1Before sending a ‘token’ byte, the host has to wait for a delay of a specified period of time. If this period is not quantified, it is equal to 6 µs.2The SPI peripheral is accessible via SPI_SCK, SPI_MOSI and SPI_MISO pins.3.3 CAN settingsTo address additional devices on the same bus, the CAN protocol provides a standardidentifier field (11-bit) and an optional extended identifier field (18-bit) in the frame. Figure 2 shows the CAN frame that uses the standard identifier only.The CAN settings are the following:●Standard identifier (not extended)●Bit rateBy default, it is 125kbps. The runtime can be changed via the speed command to achieve a maximum bit rate of 1 Mbps.The transmit settings (from the STM8L/S to the host) are:●Tx mailbox0: On●Tx mailbox1 and Tx mailbox2: Off ●Tx identifier: 02h●Outgoing messages contain 1 data bytePeripheral settingsUM056012/62Doc ID 14798 Rev 2The receive settings (from the host to the STM8L/S) are:●The synchronization byte, 7Fh, is in the RX identifier and not in the data field ●The RX identifier depends on the command (00h, 03h, 11h, 21h, 31h, 43h)●Error checking: If the error field (bit [6:4] in the CESR register) is different from 000b, the message is discarded and a NACK is sent to the host.●In FIFO overrun condition, the message is discarded and a NACK is sent to the host.●Incoming messages can contain from 1 to 8 data bytes.Note:The CAN peripheral is accessible via CAN_TX and CAN_RX pins.UM0560Bootloader command setDoc ID 14798 Rev 213/624 Bootloader command setThe commands supported by the bootloader are listed in Table 3 below.Table 4.Bootloader codesWhen the bootloader receives a command via the UART, CAN or SPI peripherals, the general protocol is as follows:1.The bootloader sends an ACK byte (79h) to the host and waits for an address and for a checksum byte, both of which are checked when received.2.When the address is valid and the checksum is correct, the bootloader transmits an ACK byte (79h), otherwise it transmits a NACK byte (1Fh) and aborts the command. The bootloader waits for the number of bytes to be transmitted (N bytes) and for its complemented byte (checksum). –If the checksum is correct, it then carries out the command, starting from the received address.–If the checksum is incorrect, it sends a NACK (79h) byte before aborting the command.The bootloader protocol via UART and SPI are identical on the device side, but differregarding the host. A token byte is needed when sending each byte to the host via SPI (see Figure 5, Figure 11, Figure 17, Figure 23, and Figure 31). The bootloader protocol via CAN differs from all other peripherals.Table 3.Bootloader commandsCommandCommand codeCommand descriptionGet 00h Gets the version and the allowed commands supported bythe current version of the bootloaderRead memory 11h Reads up to 256 bytes of memory starting from an address specified by the hostErase memory43hErases from one to all of the Flash program memory/data EEPROM sectorsWrite memory31h Writes up to 128 bytes to the RAM or the Flash program memory/data EEPROM starting from an address specified by the hostSpeed 03h Allows the baud rate for CAN runtime to be changed Go21hJumps to an address specified by the host to execute a loaded codeName Code DescriptionSYNCH 7Fh Synchronization byte ACK 79h Acknowledge NACK1FhNo acknowledgeBootloader command setUM056014/62Doc ID 14798 Rev 2The following sections are organized as follows:●Commands via UART1/ UART2/ UART3●Commands via SPI ●Commands via CAN4.1 Get commandThe get command allows the host to get the version of the bootloader and the supportedcommands. When the bootloader receives the get command, it transmits the bootloader version and the supported command codes to the host.4.1.1 Get command via UART1/ UART2/UART3The host sends the bytes as followsByte 1: 00h - Command ID Byte 2:FFh- ComplementUM0560Bootloader command setThe STM8L/S sends the bytes as followsByte 1: ACK (after the host has sent the command)Byte 2: N = 5 = the number of bytes to be sent -1 (1 <= N +1 <= 256)Byte 3: Bootloader version (0 < version <= 255)Byte 4: 00h- Get commandByte 5: 11h- Read memory commandByte 6: 21h- Go commandByte 7: 31h- Write memory commandByte 8: 43h- Erase memory commandByte 9: ACKDoc ID 14798 Rev 215/62Bootloader command set UM0560 4.1.2 Get command via SPI16/62Doc ID 14798 Rev 2UM0560Bootloader command setThe host sends the bytes as followsByte 1: 00h- Command IDByte 2: FFh - ComplementByte 3 (token): XYh; host waits for ACK or NACKByte 4 (token): XYh; host waits for 05h...Byte 11(token): XYh; host waits for ACK or NACK.The STM8L/S sends the bytes as followsByte 1: ACKByte 2: N = 5 = the number of bytes to be sent -1 (1 <= N +1 <= 256)Byte 3: Bootloader version (0 < version <= 255)Byte 4: 00h- Get commandByte 5: 11h- Read memory commandByte 6: 21h- Go commandByte 7: 31h- Write memory commandByte 8: 43h- Erase memory commandByte 9: ACKDoc ID 14798 Rev 217/62Bootloader command set UM0560 4.1.3 Get command via CANThe host sends the messages as followsCommand message: Std ID = 00h, data length code (DLC) = ‘not important’.18/62Doc ID 14798 Rev 2UM0560Bootloader command setThe STM8L/S sends the messages as followsMessage 1: Std ID = 02h, DLC = 1, data = ACKMessage 2: Std ID = 02h, DLC = 1 data = N = 6 = the number of bytes to be sent -1(1 <= N +1 <= 256)Message 3: Std ID = 02h, DLC = 1, data = bootloader version (0 < version <= 255)Message 4: Std ID = 02h, DLC = 1, data = 00h - Get commandMessage 5: Std ID = 02h, DLC = 1, data = 03h - Speed commandMessage 6: Std ID = 02h, DLC = 1, data = 11h - Read memory commandMessage 7: Std ID= 02h, DLC = 1, data = 21h - Go commandMessage 8: Std ID = 02h, DLC = 1, data = 31h - Write memory commandMessage 9: Std ID= 02h, DLC = 1, data = 43h - Erase memory commandMessage 10: Std ID = 02h, DLC = 1, data = ACKDoc ID 14798 Rev 219/62。
STM8S主控原理图
STM8S主控原理图
1.单片机电源电路:单片机需要一个恒定的供电电压,通常使用稳压
电路来实现,这个电路通常由电源滤波电容、稳压芯片和电位器组成。
2.外部晶振电路:STM8S单片机需要一个外部晶振来提供时钟信号,
这个电路通常包括晶振、两个电容和两个电阻。
3.通信接口电路:STM8S单片机支持UART、SPI和I2C等通信接口,
所以通常还需要一个逻辑电平转换电路和相应的连接器或插座。
4.GPIO电路:STM8S单片机有多个可编程的GPIO引脚,可以用来连
接外部设备,通常需要引脚保护电路和外部设备的驱动电路。
5.ADC电路:STM8S单片机内置了模数转换器(ADC),用于测量模拟
量输入信号,通常需要一个输入电压分压电路和滤波电路。
6.外设驱动电路:除了上述基本电路外,STM8S单片机还可以连接一
些外设,如LCD显示屏、LED指示灯、蜂鸣器等。
这些外设通常需要驱动
电路和相应的连接器。
以上仅是一个简单的例子,实际的STM8S主控原理图还会根据具体的
应用需求而有所差异。
在设计STM8S主控原理图时需要考虑电路的稳定性、可靠性和抗干扰能力,同时还要满足单片机的性能要求和外部设备的需求。
为了提高设计效率,可以借助Eagle、Altium Designer等电路设计软件
来完成。
STM8S做IAP
STM8S做IAP一:环境与平台MCU:STM8S005K6集成开发环境:STVD开发方式:库开发芯片内部存储”偷窥”软件Smart PRO 2008二:在RAM中运行代码0.在STM8s.h中将#define RAM_EXECUTION (1)的注释去掉,以使用RAM功能.1. 利用编译器函数#pragma section (FLASH_CODE) , #pragma section () 对函数void FLASH_ProgramBlock(Num,PROG, FAST ,Buffer);进行声明.FLASH_CODE是声明的这段代码的名字,可以自己随便取.同时函数用IN_RAM包括.举例代码如下:#pragma section (FLASH_CODE)IN_RAM(void FLASH_ProgramBlock(Num,PROG, FAST ,Buffer)){Num=PROG+ FAST +Buffer;}#pragma section ()2.声明编译器函数int _fctcpy(char name);3.在函数FLASH_ProgramBlock运行前时,利用编译器函数int _fctcpy(char name)将函数FLASH_ProgramBlock复制到RAM中.形参char name是指要复制的代码段名字的首字母.此例中要复制的代码段名为FLASH_CODE.所以应该写成: _fctcpy('F');4.在STVD软件, project工程, seting设置, linker链接器, Gategory , Input , RAM 栏中添加要在RAM中运行的代码" . FLASH_CODE"名, 并在option中输入"-ic".具体见图片.如果出现没有" . FLASH_CODE"的默认位置这样的错误,说明这步没有处理好.三:STM8S的中断特性1 把APP的中断向量表地址改成0xa300 , Flash地址改成oxa380 , 之后程序不能执行.把APP的中断向量表地址改成0x8000 , Flash地址改成oxa380 , 之后程序就能执行.是因为一上电STM8S就读取0x8000-0x8003的复位地址,以实现复位,但找不到. 这异常与复位中断有关,STM8S读取中断向量表的地址只能是0x8000到0x8080.谁的复位函数地址处在0x8000,就复谁的位.复位就是跳转主函数开始地址的意思.STM8S单片机主函数地址/复位地址是0x8000-0x8003.地址0x8004-0x8080为其它中断函数地址2.局部的变量,全局的变量,都在主函数运行后被赋初值或运行中改变值,这些变量都存储在RAM中.只有code/const指定了的才会在ROM中.3.可以利用软件复位实现软件间跳转(跳转前修改地址0x8000-0x8003中复位函数的地址); 也可直接利用跳转指令实现跳转.四:操作流程1 :APP软件,在STVD软件中,工程->设置->Linker->Caneral->Input中,设置中断地址0xa300 , Flash地址0xa380 .设置是否完成会在.lkf文件中看到,这是地址分配文件2 :Boot软件,在软件中利用汇编指令跳转到APP代码Flash的开始地址._asm("LDW X, SP ");_asm("LD A, $FF");_asm("LD XL, A ");_asm("LDW SP, X ");_asm("JPF $A380"); //跳转到APP Flash地址0xA380嵌入app.bin的地址为偏移地址,包含中断向量表地址/Flash 地址.Boot代码的地址分配默认.3.利用smart Pro软件将APP.hex文件转化成APP.bin4.利用二进制软件,修剪无用数据5.先在smart pro 2008中导入Boot.hex ,再导入修剪过的app.bin , 最后保存为Down.hex即可. 注意,导入app.bin时,不要清除之前导入的Boot代码.同时注意导入的app.bin 文件的Flash地址,导入到缓冲区的地址(器件地址)要对应跳转地址.五:Smart PRO 2008的应用.1.该软件可作一般二进制处理软件使用.但其特别之处在于,它的显示区/缓冲区/器件存储区都是基于具体真实的芯片存储架构,所以比一般的二进制软件好操作芯片的存储.具体操作在此不说明,可单独联系我.六:声明/其它1:以上内容为个人观点,没有经过严格测试,如有使用,请使用者自行评估风险,出现问题本人一概不负责!2:技术交流:3228504429。
STM8 Bootloader
自制Stm8 bootloader由于本人项目需要,要做STM8L052R8的bootloader,用于远程程序升级功能,为了安全考虑,不使用ST自带的bootloader,而是自制bootloader。
基本的功能是这样的,首先程序运行在一个V1.0的版本上,且带了BOOT,当程序收到一条命令后,程序跑入死循环,等待硬件看门狗复位;程序复位后进入bootload区,等待第二条命令的接收,接收到正确的数据帧后,bootloader开始擦除FLASH,并接收数据包,直到最后一个数据包接收完毕,通过指示灯以2HZ的频率闪烁,指示升级完成。
第一步:boot区程序设计,首先修改link文件,define region NearFuncCode = [from 0x8000 to 0xAFFF];define region FarFuncCode = [from 0x8000 to 0xAFFF];define region HugeFuncCode = [from 0x8000 to 0xAFFF];place at start of NearFuncCode { block INTVEC };以上是link文件部分,可以看出flash地址为0x8000开始,结束于0x17FFF; 长度为64kB,中断向量地址为0x8000,这样,知道了这个我们就可以修改BOOT程序的link和主程序的link了,这里我把BOOTLOAD区划分为8K,应用区为48K设置link文件如下,这样把boot区和APP区分开,互不干扰,你也可以根据需要调整他们的大小。
program:define region NearFuncCode = [from 0xB000 to 0xFFFF];define region FarFuncCode = [from 0xB000 to 0xFFFF]| [from 0x10000 to0x17FFF];define region HugeFuncCode = [from 0xB000 to 0x17FFF];place at start of NearFuncCode { block INTVEC };bootload:define region NearFuncCode = [from 0x8000 to 0xAFFF];define region FarFuncCode = [from 0x8000 to 0xAFFF];define region HugeFuncCode = [from 0x8000 to 0xAFFF];place at start of NearFuncCode { block INTVEC };像STM32这样的芯片中断向量地址可以任意定,所有boot区和APP区都可以使用中断,且互不干扰,但是STM8的中断向量表固定在0X8000地址,不能修改,所以BOOT 区不能开中断,否则会和APP区的中断打架,但是APP区的一但开启中断后就会跳转到0x8000地址,这样就跳到了BOOT区,因此需要使用跳转指令将中断跳回到APP区,__root const long reintvec[]@".intvec"={ 0x82008080,0x8200b004,0x8200b008,0x8200b00c, //当应用程序地址不是0xB000时则要相应改掉除第一个0x8200b010,0x8200b014,0x8200b018,0x8200b01c, //0x82008080以外的数值0x8200b020,0x8200b024,0x8200b028,0x8200b02c,0x8200b030,0x8200b034,0x8200b038,0x8200b03c,0x8200b040,0x8200b044,0x8200b048,0x8200b04c,0x8200b050,0x8200b054,0x8200b058,0x8200b05c,0x8200b060,0x8200b064,0x8200b068,0x8200b06c,0x8200b070,0x8200b074,0x8200b078,0x8200b07c,};这里大概的含义就是重定义STM8的中断,STM8中断向量重定义,至于这里为什么这样写,请网上自己去看,我也不是很清楚。
ST单片机 IAP所使用的Bootloader使用基本说明
Bootloader使用基本说明一、Bootloader程序首先通过ST烧录软件ST Visual Programmer将Bootloader程序烧录进选件板ST MCU中,烧录时需配置选项字节2(即UBC选项字节),将其设置为00000111,用于保护bootloader程序在下载用户程序时不被修改二、用户程序需修改的地方1.通过ST Visual Develop仿真文件导入用户应用程序工程文件,在Project Setings中的Linker选项中Category选项框中选Input选项,然后在下面设置用户程序的中断映射地址和主程序起始地址,由于在bootloader中设置的烧录地址为0x9600,因此用户程序中断地址设为0x9600,主程序起始地址设为0x9680,重新编译生成新的.s19调试文件2.将用户程序调试所生成的的.s19文件通过ST烧录软件ST Visual Programmer导入后重新命名并另存为新的.s19文件,然后再导入bootloader烧录PC软件,如果直接导入bootloader烧录PC软件会出现0x9680段的代码和ST烧录软件所显示的0x9680段代码不符,图示如下:该图为用户程序.s19文件导入ST烧录软件所显示的用户程序代码,其中0x9680段为01 02 03 ……..该图为用户程序.s19文件直接导入bootloader烧录PC软件所显示的代码。
其中0x9680段变为36 00 00 00 00…..该图为用户程序.s19另存为后再导入bootloader烧录PC软件所显示的代码,其中0x9680段为01 02 03…与ST烧录软件显示的相同三、Bootloader烧录软件所需设置的地方1.在软件中Settings选项如下配置2.在Buffer selection中设置每一包数据的大小为128,起始地址为0x9600,结束地址为0xFFFF,输入后哦按回车键即可选中所导入的.s19文件中0x9600到0xFFFF段代码3.在配置好选项后点击Connect进行连接,连接成功则红灯变为绿灯,且设备信息栏会显示版本号和命令字符4.然后可点击WriteData,会弹出对话框要求设置程序在目标Flash中存放的起始地址,一样需设为0x9600,即可向MCU Flash区烧录程序,左下方进度条会提示程序烧录的进度5.每一次MCU上电后,只能进行一次Connect,如需再连接需给MCU重新上电6.如果在MCU Flash0x9600段本身存有用户程序时,则需在MCU上电后规定时间内立即点击Connect进行通信,否则bootloader程序将自动跳转到用户程序执行而使得连接不上,时间大概为1-2秒之内。
stm8s系列单片机原理与应用
stm8s系列单片机原理与应用STM8S系列单片机原理与应用。
STM8S系列单片机是STMicroelectronics公司推出的一款高性能、低功耗的8位单片机,广泛应用于家电、工业控制、汽车电子等领域。
本文将介绍STM8S系列单片机的基本原理和应用。
首先,我们来了解一下STM8S系列单片机的基本特点。
STM8S系列单片机采用高性能的8位CPU内核,工作频率可达到20MHz,具有丰富的外设资源,包括通用定时器、串行外设接口、模拟数字转换器等。
此外,STM8S系列单片机还具有低功耗特性,可满足对功耗要求较高的应用场景。
在实际应用中,STM8S系列单片机可以广泛应用于各种控制系统中。
例如,可以用于家电控制领域,如空调、洗衣机、微波炉等家电产品的控制系统;还可以应用于工业控制领域,如工业自动化设备、仪器仪表等的控制系统;同时,STM8S系列单片机还可以应用于汽车电子领域,如汽车发动机控制单元、车载娱乐系统等。
在使用STM8S系列单片机进行开发时,我们可以充分发挥其丰富的外设资源和高性能的CPU内核。
通过合理的软件设计和优化,可以实现各种复杂的控制算法和功能。
同时,STM8S系列单片机还提供了丰富的开发工具和软件支持,如ST 公司提供的集成开发环境和编译器,方便开发人员进行软件开发和调试。
除此之外,STM8S系列单片机还具有丰富的通信接口,如SPI、I2C、UART 等,可以方便地与外部设备进行通信,实现系统的扩展和联网。
这些通信接口的灵活应用,使得STM8S系列单片机在各种应用场景下都能够得到充分的发挥。
总的来说,STM8S系列单片机作为一款高性能、低功耗的8位单片机,具有丰富的外设资源和通信接口,广泛应用于家电、工业控制、汽车电子等领域。
在实际应用中,我们可以充分发挥其性能优势和丰富的外设资源,实现各种复杂的控制算法和功能。
同时,ST公司提供的丰富的开发工具和软件支持,也为开发人员提供了便利。
相信随着技术的不断发展,STM8S系列单片机在各个领域的应用将会更加广泛。
单片机这么简单?一分钟看懂单片机最小系统电路原理图:STM8S
单片机这么简单?一分钟看懂单片机最小系统电路原理图:STM8S本文以ST公司的STM8S003单片机为例,给大家讲解一个单片机最小系统的电路原理图:通过单片机采集一个按键信号,点亮一颗LED灯。
如果你看懂了这张原理图,单片机硬件就入门了——真的到进门了!一、系统框架电源从电源插座P1进入电路板,经过LM7805稳压成VCC(=5V)给单片机供电,单片机采集按键S1的信号,点亮LED灯D2,编译好的程序经过程序下载口JP1下载到单片机里。
二、电路细节电源插座P1可以采用12V电源,二极管D1的作用是为了防止电源不小心反接而损坏电路器件。
LM7805前面的两个电容C1和C2和后面的两个电容C3和C4是为电压滤波的,进一步稳定VCC的电压,让VCC的纹波不要太大,因为纹波大了会影响单片机的工作。
电容C5和C6是依据STM8S003的数据手册要求必须用的两颗电容,遵照执行即可,暂时不用深究,后续我的文章中会谈到。
电阻R1是为了限制发光二极管(LED)D2的电流。
LED一般需要5-10mA的电流才能点亮,LED本身的压降一般比较固定,其值是1V左右,当单片机控制PC6口输出低电平时,LED将被点亮,这时LED中的电流为:(5V-1V)/0.47KΩ=8.5mA。
按键S1一端接地,一端接单片机PD3口,在PD3口内部可以通过软件设置上拉电阻,当S1断开时,PD3口为高电平;当S1闭合时,PD3口为低电平。
单片机依据PD3口的电平状态即可获知按键是否闭合。
JP1是程序下载接口,所有STM8单片机的程序下载接口都是一样的。
其中NRST为单片机复位接口,SWIM为程序下载的数据通道,电脑里的程序代码就是通过SWIM传输到单片机中的。
疑问:为啥没有时钟(晶振)电路?因为现在的单片机一般内部集成有RC振荡电路,通过软件可以设置单片机选用内部的RC振荡脉冲作为单片机内部的时钟。
只是内部RC振荡电路的时钟不是太精准,对于一些时钟精度要求比较高的场合可以外接晶振电路。
STM8S硬件电路设计注意事项
STM8S硬件电路设计注意事项1.输入和输出保护:为了保护STM8S芯片免受外界干扰和过电压的影响,需要为所有的输入和输出引脚添加合适的保护电路。
一般来说,输入引脚需要添加防静电保护二极管和滤波电容,输出引脚需要添加限流电阻和电流保护二极管。
2.电源滤波:为了确保供电电源的稳定性和纹波的低噪声性能,需要在STM8S芯片的电源引脚添加适当的滤波电容和滤波电感。
同时,还要注意电源线的走线规划和阻抗匹配,避免长线和干扰源的干扰。
3.时钟电路:STM8S芯片内部有多个时钟源供选择,如外部晶体振荡器、外部RC振荡器和内部高频RC振荡器。
在进行时钟电路设计时,需要根据具体的应用需求选择合适的时钟源,并添加合适的稳压电路、滤波电容和独立电源。
4.外设接口:STM8S具有丰富的外设资源,包括UART、SPI、I2C、定时器等。
在设计外设接口时,需要根据具体的应用需求选择合适的外设接口,并为其添加适当的电平转换电路、滤波电容和阻抗匹配。
5.地线设计:为了保证STM8S芯片的地线干净和稳定,需要合理规划地线走线。
一般来说,地线需要短而宽,且与信号线分开布局。
此外,还需要注意地线的良好连接和接地电位的稳定性。
6.PCB布局:在进行STM8S的硬件电路设计时,需要合理规划PCB的布局。
首先,将主要的功能模块分开布局,避免相互干扰。
其次,将高频和低频电路分开布局,尽量减少电路之间的交叉干扰。
最后,合理规划电源线、信号线和地线的走线路径,提高电路的抗干扰能力。
总的来说,进行STM8S硬件电路设计时需要注意输入和输出保护、电源滤波、时钟电路、外设接口、地线设计和PCB布局等方面。
合理的电路设计可以提高系统的稳定性和可靠性,降低故障和干扰的风险。
Stm8s-IAP-Bootloader设计
stm:Bootloader1.项目介绍在之前的例程和实践中,我们都是使用st-link调试下载的方式进行程序烧录。
大家可能已经认识到这种烧录方式的弊端了。
因为这种烧录方式首先必须要有以下几个工具或者软件:1.烧录工具(不能芯片支持的工具不一样,有ST-Link,JTAG等)2.已经安装了IDE(IAR或者SVD或者CCS等)或者与烧录工具匹配的烧录软件的电脑3.烧录前后需要物理上电掉电(不建议ST-Link进行热插拔),即开/关电源.也许大家会觉得,对于学习而言,这些都能忍受。
但是如果真正做成产品,如果还是用这种方式进行升级,那代价就太大。
举个例子吧,我之前的工作是开发和维护大功率的UPS(不间断电源),主要客户是一些大型企业,例如银行的数据中心,中国移动网络中心。
UPS内部有许多ARM芯片,DSP芯片。
这类应用场合,即便给程序升级,客户也不会让你断电的,而且因为安全性要求,一般MCU,DSP都是在产品内部,根本无法对外开放烧录盒的烧录接口。
所以绝大部分嵌入式产品,都会开发Bootloader程序。
那么什么是Boot Loader呢?一般来说,嵌入式产品的软件都会分为两部分,第一部分为Bootloader,第二部分为主程序(Main APP),它们存放在flash的不同区域。
Bootloader是上电或者复位以后先执行的,通过它,我们可以初始化硬件设备、建立内存空间的映射图,检测程序的完整性,判断是否需要从Bootloader 跳转到APP或者更新APP。
而主程序呢,则是真正用来实现产品面向客户的功能的。
通常呢,在Bootloader会实现一种或者一种以上的IAP方式,可能是UART,SPI,CAN或者Ethernet等。
本次例程呢,就是设计一个Bootloader,允许用户用电脑的串口+超级终端实现烧录功能2.程序流程设计秉承软件开发好习惯,coding前先想好思路,设计好流程框图,coding时才能事半功倍哦。
STM8串口下载使能配置
STM8串口下载使能配置STM8l串口下载还有关于复位是否运行自带Bootloader,至少符合下面两个条件之一就可以了1、器件是空的(新买的就是空的)2、optionbyte里的Bootloader是Enable的新的器件optionbyte里的Bootloader是disable的,为了能不止一次使用串口下载程序,第一次下载的程序必须修改optionbyte使得Bootloader Enable这是STM8S的程序:#include "iostm8.h"void main(void){FLASH_DUKR = 0xae;asm("nop");FLASH_DUKR = 0x56;asm("nop");while(!(FLASH_IAPSR & 0x08));asm("nop");FLASH_CR2 = 0x80;asm("nop");FLASH_NCR2 = 0x7f;asm("nop");*((unsigned char *)0x487e) = 0x55;asm("nop");*((unsigned char *)0x487f) = 0xaa;while(1);}这是STM8L的程序:#include "iostm8L152c6.h"void main(void){FLASH_DUKR = 0xae;asm("nop");FLASH_DUKR = 0x56; // 解除写保护asm("nop");while(!(FLASH_IAPSR & 0x08)); // 等待解锁asm("nop");FLASH_CR2 = 0x80; // 对选项字节进行写操作asm("nop");*((unsigned char *)0x480b) = 0x55;asm("nop");*((unsigned char *)0x480c) = 0xaa; // 写入选项字节while(1);}。
STM8 ICP和IAP
STM8 ICP 和IAP在线编程(ICP)用于更新STM8 整个存储器的内容。
ICP 使用SWIM 接口把用户的程序装载到微控制器中,同时提供迅速而有效的设计迭代并且去除了不必要的封装处理和器件插槽。
SWIM 接口(单线接口模块)使用SWIM 引脚和编程工具相连接。
相对于ICP 方式,在应用编程(IAP)可使用STM8 支持的任意通讯接口(I/O、I2C、SPI、UART)来下载要编入存储器中的数据。
IAP 允许在应用程序运行中对FLASH 程序存储器的内容重新编程。
然而要想使用IAP,必须通过ICP 对FLASH 程序存储器预先编程。
请参考STM8 Flash 编程手册(PM0051)和STM8 SWIM 通信协议和调试模块用户手册(UM0470)来了解关于编程步骤的更多细节。
R/W/E=读;写和运行;R/E=读和运行(写操作被禁止);R=读(写操作和运行被禁止);P=该区域不可存取(读;写和运行被禁止);P/WROP=被保护。
除ROP 选项字节外,写操作被禁止。
在向FLASH_PUKR 写入正确的MASS 密钥之前,Flash 程序存储器是写保护的(锁住)。
可以通过清PUL 位来重新锁住该区域,但在两次复位之间仅可解锁一次。
在向FLASH_DUKR 写入正确的MASS 密钥之前,DATA 存储器是写保护的(锁住)。
可以通过清DUL 位来重新锁住该区域。
如果想对UBC 区域编程,首先要清除UBC 对应的选项字节位。
在向FLASH_DUKR 写入正确的MASS 密钥(同时OPT 位要置1)之前,选项字节是写保护的(锁住)。
可以通过清DUL 位来重新锁住该区域。
当ROP 位被清除,整个存储器(包括选项字节)被自动擦除。
tips:感谢大家的阅读,本文由我司收集整编。
仅供参阅!。
STM8S103F写入user_bootloader实现串口下载
STM8S103F写入user-bootloader实现串口下载
一、bootloader软件的编译和写入
1、需要的软件,以下软件可以从st网站获得
STM8_UserBootloader_examples
Flash Loader Demonstrator
ST Visual Develop
ST Visual Programmer
CXSTM8
2、安装stvd等软件建立IDE工作环境
3、修改STM8_UserBootloader_examples中的相关main.h文件中的参数
4、修改编译link参数,加入红框部分
5、用ST Visual Programmer软件通过st-link写入生成的代码
二、应用程序编写时注意情况
1、写好编译程序后要修改link参数,使程序从9000开始
1、stm8s103f3的引脚接线
2、下载程序的修改
使用Flash Loader Demonstrator默认是不支持8k程序下载的,需要以stm8l_32k为蓝本修改
下smap文件。
3、修改软件界面如下
4、将nrst引脚接地,就是复位,复位结束后马上点next按钮,会出现如下页面,点确定
5、选择改好的stm8l_8k,点next下一步
6、选择要下载的文件,注意此文件编译时要修改link参数把起始地址放在9000 处
四、以下是stm8s103f修改好的相关文件
1、修改编译好的bootloader
2、修改好的STM8L_8K.STmap。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
项目实践2:Bootloader1.项目介绍在之前的例程和实践中,我们都是使用st-link调试下载的方式进行程序烧录。
大家可能已经认识到这种烧录方式的弊端了。
因为这种烧录方式首先必须要有以下几个工具或者软件:1.烧录工具(不能芯片支持的工具不一样,有ST-Link,JTAG等)2.已经安装了IDE(IAR或者SVD或者CCS等)或者与烧录工具匹配的烧录软件的电脑3.烧录前后需要物理上电掉电(不建议ST-Link进行热插拔),即开/关电源.也许大家会觉得,对于学习而言,这些都能忍受。
但是如果真正做成产品,如果还是用这种方式进行升级,那代价就太大。
举个例子吧,我之前的工作是开发和维护大功率的UPS(不间断电源),主要客户是一些大型企业,例如银行的数据中心,中国移动网络中心。
UPS内部有许多ARM芯片,DSP芯片。
这类应用场合,即便给程序升级,客户也不会让你断电的,而且因为安全性要求,一般MCU,DSP都是在产品内部,根本无法对外开放烧录盒的烧录接口。
所以绝大部分嵌入式产品,都会开发Bootloader程序。
那么什么是Boot Loader呢?一般来说,嵌入式产品的软件都会分为两部分,第一部分为Bootloader,第二部分为主程序(Main APP),它们存放在flash的不同区域。
Bootloader是上电或者复位以后先执行的,通过它,我们可以初始化硬件设备、建立内存空间的映射图,检测程序的完整性,判断是否需要从Bootloader跳转到APP或者更新APP。
而主程序呢,则是真正用来实现产品面向客户的功能的。
通常呢,在Bootloader会实现一种或者一种以上的IAP方式,可能是UART,SPI,CAN或者Ethernet等。
本次例程呢,就是设计一个Bootloader,允许用户用电脑的串口+超级终端实现烧录功能2.程序流程设计秉承软件开发好习惯,coding前先想好思路,设计好流程框图,coding时才能事半功倍哦。
此次Bootloader程序主要分为三个模式:1.升级模式Upgrademode:对硬件初始化完成以后,率先检测这个模式,进入该模式的条件为,检测到升级程序的命令,否则进入下一个模式的检测。
在这个模式下,LED指示灯闪烁速率最快,为50ms2.正常模式Normal Mode:这个模式主要作用为检测主程序是否有效,如果有效则进行程序跳转进入主程序,否则进行下一个模式的检测。
这边建议在主程序控制LED指示灯以其他的频率(例如500ms或者1s)闪烁,以示区别。
3.等待模式Wait Mode:如果上述两种模式都不满足,则停留在这个模式。
这个模式主要作用为循环检测串口数据,如果有收到数据则进行解析,满足升级模式的进入条件则转到升级模式。
该模式下,LED指示灯闪烁速率为200ms。
程序流程框图如下:2.1.正常模式从之前的程序流程图可以看出,我们已经将stm8s的flash分为了Bootloader和Main APP,所以如果没有接到烧录指令且Main APP的flash区域已经有了正常的程序,那么bootloader 就跳转到Main APP执行。
那么怎么判断Main APP已经有了程序了呢?这边我提供一个比较简单方法。
我们可以在Main APP的代码中,把某串特定的字符通过伪指令放入特定的地址,那么Bootloader只要读取该地址与预先规定好的字符是否一致。
一致的话则认为Main APP 存在。
本次实践,我在Main APP中将“XLXWW”字符放入flash的0x9180地址中。
当然如果对安全性要求更高的话,我们还可以定义更复杂的方式。
业内比较通用的方式是除了刚才提到的方法,还会加上将整个Main APP的flash的值进行checksum校验等。
2.2.升级模式升级指令会在在两种情况下收到:1.芯片内部只有bootloader2.芯片有bootloader和Main APP,且当前程序跑在Main APP。
这种情况下,我们在跳转会Bootloader前需要先将这个信息写入EEPROM,bootloader才知道需要升级程序下面定义了升级模式过程中的步骤:1.如果之前未初始化UART,则首先初始化UART的配置;2.上位机(PC)通过串口发送询问请求,包括系统型号,程序版本等信息,Bootloader根据自己的信息回复,如果上位机认为匹配成功,则进行下一步3.上位机根据烧录文件的信息,发送开始烧录请求,请求包中包含了需要擦除的地址段。
Bootloader根据上位机的请求,擦除对应地址的flash,成功后回复ok4.上位机分段将flash的Data传送给你Bootloader,Bootloader将数据依次写入Flash空间5.所有数据烧写完成后,上位机开始请求验证flash数据是否被正确写入。
此时Bootloader分段读取flash数据,发送给上位机,上位机收到数据后与原始烧录文件的数据做对比,如果完全一致,则整个烧录过程结束,如果有不一致,则提示用户是否重新烧录。
2.3.等待模式等待模式,其实就是由于Main APP不存在或者不完整,程序一直待在booloader. 在while 循环里面,一直查询是否有收到串口数据。
如果有则进行解析,并根据解析后的指令是进入升级模式还是丢弃这些不满足期望的数据。
3.前期准备3.1.编译器是怎么生成烧录文件的简单讲,编译器就是将“一种语言(通常为高级语言)”翻译为“另一种语言(通常为低级语言)”的程序。
一个现代编译器的主要工作流程:源代码(source code) →预处理器(preprocessor) →编译器(compiler) →目标代码(object code) →链接器(Linker) →可执行程序(executables).以IAR为例,编译可以细分为三个阶段:1.源文件解析IAR中有C/C++和汇编编译器,会根据实际项目中的源文件类型,翻译为中间目标文件. 这些文件具备特殊格式,可重定位,作为第二步链接器的输入文件。
2.链接第一步生成的目标文件,只是一个中间产物,需要通过链接器进行链接,生成烧录文件。
既然要链接,我们首先必须得有链接配置文件。
Stm8s链接配置文件是.icf文件,默认情况下只要我们在工程设置中选取了device,编译器会自动找寻到对应的.icf 作为配置文件。
所以之前的课程中,并没有提及。
但是在此次课程中,由于我们需要将flash分为两个部分,因此需要我们对自带的.icf进行适当的修改。
详见3.2.与此同时,链接器也可以生成其他文件,比较有参考意义的有.map文件。
在.map 文件里面我们可以详细的查看flash空间用了多少,一些全局变量和函数被分配到了flash的什么区域。
3.链接以后链接器生成的一些文件,可以根据需要进一步转换为其他文件,例如给IAR的调试器,方便我们进行调试.或者调用其他外部转换器,转为其他我们所想要格式的烧录文件。
3.2.如何将Bootloader和Main APP放入特定flash段LINK链接器是按照用户在ICF文件中的规定来放置sections的,所以理解ICF文件的内容尤其重要。
一个标准的ICF文件可包括下面这些内容:-可编址的存储空间(memory)-不同的存储器地址区域(region)-不同的地址块(block)-Section的初始化与否-Section在存储空间中的放置默认情况下IAR根据Device类别自动选取对应的icf文件,也可以根据需要选定自己写的icf文件,设置方法如下:Option Linker,选取自定义文件所以我们需要分别为bootloader和main APP准备icf文件,里面定义的flash地址需要错开,RAM空间可以共用。
下面是两个文件的部分对比,详细的内容请参见bootloader和main APP工程下的Linker文件夹。
3.3.Main APP和Bootloader间的切换和识别3.3.1.Main APP BooloaderMain APP切换到Bootloader的情形为,Main APP接收到烧录命令,需要跳转到Bootloader,然后由bootloader擦除Main APP的flash空间。
所以这里存在两个问题:1.Main APP如何跳转到Bootloader2.Bootloader怎么分辨是从Main APP跳入的,而不是系统硬复位对于第一个问题,简单的来说,就是收到烧录指令后,我们人为地让程序进入Bootloader的flash首地址存储的地址中去。
Bootloader中的flash开头存放的是中断向量表,PC跳到首地址以后,CPU会先取2个地址,第一个是栈顶地址,第二个是复位异常地址,然后执行复位初始化函数以后,转入执行bootloader的main函数。
如此便开始执行bootloader。
第二问题,我们在ifc文件中定义一段RAM空间,属性为不需要初始化。
正常来说,只要发生复位,不管是硬复位还是软复位,那么RAM区域都会初始化为0(跳入Main 函数前的汇编代码中)。
但是如果我们在icf文件中设定为不需要初始化,那么则会跳过这段区域的初始化。
所以在跳转之前,我们将这片RAM区更新为某个特定的值,那么Bootloader开始阶段,以此判断即可。
icf程序3.3.2.Booloader Main APP类似的,所以这里也存在两个问题:1.Bootloader如何跳转到Main APP2.Bootloader怎么分辨flash中已经有Main APP第一个问题与3.3.1描述的类似,不再重复。
第二个问题也需要利用icf文件。
教程里面用的方法是,在flash地址最末尾预留出一小段,存放特定的字符串。
之所以放在末尾,是因为这段地址最后更新,如果能检测到,说明icf程序3.4.如何解析烧录文件有了前面的准备,我们可以准备工程并且通过工程配置生成Intel Hex格式烧录文件。
Intel HEX 文件是遵循Intel HEX 文件格式的ASCII 文本文件。
在Intel HEX 文件的每一行都包含了一个HEX 记录。
这些记录是由一些代表机器语言代码和常量的16进制数据组成的。
Intel HEX 文件常用来传输要存储在ROM 或者EPROM 中的程序和数据。
每个记录包含5个域,它们按以下格式排列:Start Code每个Intel HEX 记录都由冒号开头Byte count是数据长度域,它代表记录当中数据字节的数量Address是地址域,它代表记录当中数据的起始地址Record type是代表HEX记录类型的域,它可能是以下数据当中的一个:00-数据记录01-文件结束记录02-扩展段地址记录03-开始段地址记录04-扩展线性地址记录05-开始线性地址记录Data是数据域,一个记录可以有许多数据字节.记录当中数据字节的数量必须和数据长度域中指定的数字相符Checksum是校验和域,它表示这个记录的校验和.校验和的计算是通过将记录当中所有十六进制编码数字对的值相加,以256为模进行以下补足。