AN3181 STMICROELECTRONICS | Alldatasheet
Document overview
- Manufacturer or author: Provided By ALLDATASHEET.COM(FREE DATASHEET DOWNLOAD SITE)
- PDF pages: 31
Technical content
Datasheet sections
- 1 Package variation overview
- 2 Compliance with IEC and VDE standards
- 2.1 Generic tests included in the ST firmware library
- 2.2 Application specific tests
- 2.2.1 ADC/DAC
- 2.2.2 I/Os
- 2.2.3 Interrupts and external communication
- 2.2.4 Timing
- 2.2.5 External addressing
- 3 Class B software package
- 3.1 Basic software principles
- 3.1.1 Fail Safe mode
- 3.1.2 Class B variables
- 3.1.3 Class B flow control
- 3.2 Package organization
- 3.2.1 Projects and workspaces included in the package
- 3.2.2 Tool specific integration of the library
- 3.2.3 Application demonstration example
- 3.3 Package configuring and debugging
- 3.3.1 Configuration control
- 3.3.2 Verbose diagnostic mode
- 3.3.3 Debugging the package
- 4 Class B solution structure
- 4.1 Integrating software into user application
- 4.2 Detailed description of startup self tests
- 4.2.1 Watchdog startup self test
- 4.2.2 CPU startup self test
- 4.2.3 Flash complete checksum self test
- 4.2.4 Full RAM March C-/X self test
- 4.2.5 Clock startup self test
- 4.3 Periodic run mode self tests initialization
emission and noise sensitivity is tested for compliance with international standards. ■ Ultra-low power low density STM8L, STM8AL and STM8TL touch-sensing devices. reduces program memory overhead and increases the code execution speed. for some other ST 8-bit microcontrollers not yet certified. Table 1 lists the microcontrollers concerned by this application note. Table 1. Applicable products
1 Package variation overview
Available configurations of STM8S/A package support the following devices in the families:
- STM8S high-density Performance line devices with 32-128 Kbytes Flash memory (like STM8S20x)
- STM8S medium- and low-density Access line devices with 4-32 Kbytes Flash memory (like STM8S105x, STM8S103x)
- STM8S high-, medium- and low-density Value Line devices with 4-64 Kbytes Flash memory (like STM8S007x, STM8S005x, STM8S003x)
- STM8S low-density Application specific devices with 8 Kbytes Flash memory (like STM8S903x)
- STM8A high-density CAN line devices with 32-128 Kbytes Flash memory (like STM8AF5xxx)
- STM8A high and medium density Standard line devices with 8-128 Kbytes Flash memory (like (STM8AF6xxx) Available configurations of medium-density STM8L/AL package support the following devices in the ultra-low power families:
- STM8L medium density standard devices with 4-64 Kbytes Flash memory (like STM8L15xx)
- STM8L medium-density Value Line devices with 4-64 Kbytes Flash memory (like STM8L05xx)
- STM8AL medium-density devices with up to 32 Kbytes Flash memory (like STM8AL31xx, STM8AL3Lxx) Available configurations of low-density STM8L/AL/TL package support the following devices in the ultra-low power families:
- STM8L low density standard devices with up to 8 Kbytes Flash memory (like STM8L10xx)
- STM8AL low density devices with up to 8 Kbytes Flash memory (like STM8AL30xx)
- STM8TL low density devices with up to 16 Kbytes Flash memory and touch sensing interface (like STM8TL53xxx) All these firmware packages are available for free download from the ST web. Three projects have been prepared and tested for each package under following environment and toolchains: 1. IAR Embedded Workbench® for STM8 IDE (EWSTM8™) with IAR C-Compiler™ version 1.30 2. ST Visual Develop (STVD) version 4.3.0 with Cosmic STM8 C-compiler 32 K version 4.3.6 3. ST Visual Develop (STVD) version 4.3.0 with Raisonance STM8/ST7 C-compiler version 2.38
For more ElectroMagnetic Compatibility (EMC) information please refer to the following related application notes:
- AN1015 application note, Software techniques for improving microcontroller EMC performance
- AN1709 application note, EMC design guide
- AN2860 application note, EMC guidelines for STM8S
AN3181 Compliance with IEC and VDE standards Doc ID 17286 Rev 2 7/31
2 Compliance with IEC and VDE standards
The IEC (International Electrotechnical Commission) is a non-profit and non-governmental authority recognized worldwide for preparing and publishing international standards for a vast range of electrical, electronic and related technologies. IEC standards are focused mainly on safety and performance, the environment, electrical energy efficiency and its renewable capabilities. The IEC cooperates closely with ISO (International Organization for Standardization) and ITU (International Telecommunication Union). Their standards define not only the recommendations for hardware, but also for software solutions. Standards are divided into a number of safety classes depending on the purpose of the application. The other bodies that are recognized worldwide in the field of electronic standard organizations are VDE in Germany, IET in the United Kingdom and the IEEE in the United States. The VDE association also includes a Testing and Certification Institute which is a pioneer of software safety inspection. This is a registered National Certification Body (NCB) for Germany. The main purpose of this testing house is to offer standards compliance and quality testing services to manufacturers of electrical appliances. One of the pivotal IEC standards is the IEC 60335-1 norm, which covers safety and security of household electronic appliances destined for domestic and similar environment. Appliances incorporating electronic circuits are subject to component failure tests. The basic principle is that the appliance must remain safe in the case of any component failure. The microcontroller is an electronic component just like any other from this point of view. If safety relies on an electronic component, it must remain safe after two consecutive faults. This means the appliance must stay safe with one hardware failure and with the microcontroller not operating (under reset or not operating properly). If the safety depends on software, the software is taken into account with the second applied failure. The conditions required for software are defined precisely in Annex Q of the IEC 60335-1 norm. Three classes of appliances are defined here:
- Class A: Safety does not rely on software
- Class B: Software prevents unsafe operation
- Class C: Software is intended to prevent special hazards This application note and the associated ST software package covers the group B specification. Appliances under group C need some other special requirements such as dual microcontroller operation, which is outside the scope of this document. Class B compliance aspects for microcontrollers are related both to hardware and software. A list of microcontroller parts under compliance is evaluated at IEC 60335-1 Annex T which refers to IEC 60730 Annex H. This list can be divided into two groups - micro-specific and application-specific items. (see Table 2: MCU components to be tested for Class B compliance). While application-specific parts rely on customer application structure and must be defined and developed by users (communication, I/O control, interrupts, analog inputs and outputs), micro-specific parts are related purely to the micro structure and can be made generic (core self-diagnostic, volatile and non-volatile memory integrity checking, clock system tests). This group of micro-specific tests is the focus of the ST solution based on powerful hardware features of STM8 MCU such as dual independent watchdogs or clock sources. It is important to note that there are several other peer recognized bodies concerning electronic safety standards besides IEC, such as VDE in Germany, IET in the United Kingdom and the IEEE in the United States. In addition, an increasing number of product
package has been VDE certified.
2.1 Generic tests included in the ST firmware library
- CPU registers test
- clock monitoring
- RAM functional check
- FLASH checksum integrity check
- watchdog self-test
- stack overflow monitoring An overview of the methods used for these MCU-specific tests is given in Table 3 and they are described in more detail in the following chapters. The last two items from the list above are not explicitly asked for by the norm, but they improve overall fault coverage.
Table 2. MCU components to be tested for Class B compliance
would be significantly reduced.
2.2 Application specific tests
- Analog: ADC/DAC & multiplexer
- I/Os
- Interrupts and external communication
- Timing
- External addressing
Table 3. Overview of methods used in micro-specific tests provided with this method, additionally. (see Section 3.1.3).
- Window WDG feature is not available at STM8L10x devices.
pattern is written at a high boundary if it is not at the RAM end). into the dedicated timer while the other gates it. startup and a partial memory test is repeated at runtime (block by block). variable space, stack and unused space are not tested at run time.
Compliance with IEC and VDE standards AN3181 10/31 Doc ID 17286 Rev 2
2.2.1 ADC/DAC
Analog components depend on device’s application and peripheral capabilities. Used pins should be checked at correct intervals. Free analog pins can be used for checking user analog reference points. Internal references should be checked, too.
2.2.2 I/Os
Class B tests must detect any malfunction on digital I/Os. This could be covered by plausibility checks together with some other application parts (e.g. change in an analog signal from temperature sensor when heating/cooling digital control is switched on/off).
2.2.3 Interrupts and ex ternal communication
Application interrupts occurrence and external communications can be checked by different methods. One of them could be a control using a set of incremental counters where every interrupt or communication event increments a specific counter. The values in the counters are then verified at given time intervals by cross-checking against some other independent time base.
2.2.4 Timing
Timing could be verified by ensuring that the application routines execution times are correct and that there are no unexpected delays. A cross-check with a different time base could be done. Timing control is strictly dependent on the application.
2.2.5 External addressing
External addressing is not used with STM8 microcontrollers.
3 Class B software package
3.1 Basic software principles
firmware library are described in detail at this section.
3.1.1 Fail Safe mode
include procedures necessary to keep the application in a safe state. microcontroller when a failure occurs.
3.1.2 Class B variables
Class B variables are dedicated variables defined by the user as critical to the application. allocation according to application needs and with respect to device hardware capability. Figure 1. Example of RAM memory configuration for STM8S20x
3.1.3 Class B flow control
stored in the counter pair must be always complementary after any block is processed. always checked here and any unexpected value results in calling the FailSafe() routine. Figure 2. Control flow four steps check routine
- For this example, the unique number for Component test 1 is “5” and for the procedure itself it is defined as
step (return from procedure) is done.
AN3181 Class B software package Doc ID 17286 Rev 2 13/31
3.2 Package organization
This section describes how the ST solution is organized.
3.2.1 Projects and workspaces included in the package
Three projects have been prepared for each package using different toolchains. The project for IAR C-compiler is done under IAR EWSTM8 environment, while projects for both Cosmic and Raisonance C-compilers are done as ST Visual Develop (STVD) project workspaces. The corresponding Project.eww or Project.stw project file must be configured for a specific STM8x device settings and adequate workspace configuration before any compilation.
3.2.2 Tool specific int egration of the library
Each project covers all settings and includes needs for both compilation and linking processes. User has to check the symbols defined for preprocessor at project settings as these symbols configure the project main structure and used features. The user can make detailed configurations at library parametric header file (see Section 3.3: Package configuring and debugging). Predefined linker script files *.icf are included at IAR projects for different microcontrollers. Linker script files *.lkf for STVD projects are generated automatically and placed into DEBUG or RELEASE directories. User can make a copy of these files, edit them and force compiler to use the overwritten file. Reset handler must be modified to perform STL_StartUp function after reset before standard C-compiler initialization starts. Therefore startup assembly file csstartup.s (IAR) or startup.asm (Raisonance) must be modified in that way. For Cosmic, the reset handler is changed at stm8_interrupt_vector.c file. Caution: Be careful when invariable memory checksum setting is configured for the project. It is quite different for different compilers. IAR compiler uses project option setting applied at its specific Checksum card window of linker. When Raisonance C-compiler is used, user should define checksum range and its placement using user defines option declared at the project settings:
- CRCRANGE(begin_address, end_address) - continuous space under CRC computation
- CRCPLACE(crc_address) - placement of CRC result
- FILLGAP(fill_constant) - setup of unused memory areas Cosmic C-compiler requires to define all the segments under checksum computation (by adding -ck parameter to each of them) and specific checksum segment keeping the checksum descriptor table must be included into the project and allocated at invariable memory additionally with applied -ik parameter. Specific segments for Class B variables and checking stack overflow must be added into project and allocated at variable memory, too. Double storage in CLASS_B_RAM and CLASS_B_RAM_REV separated segments is necessary to ensure the redundancy of the safety critical data (Class B). All other variables defined without any particular attributes are considered as Class A variables and their storage area is not checked during the transparent RAM test. The size and allocation of these segments can be modified at linker script files or directly by project settings.
Class B software package AN3181 14/31 Doc ID 17286 Rev 2 A new Class B variable must be declared as a complementary pair of two variables allocated at different segments by definition placed into proper part of the stm32fxxx_STLclassBvar.h header file. The following syntax is used for the compilers: Cosmic EXTERN @near u16 MyClassBVariable; .... EXTERN @near u16 MyClassBVariableInv; IAR EXTERN __near u16 MyClassBVariable @ "CLASS_B_RAM"; EXTERN __near u16 MyClassBVariableInv @ "CLASS_B_RAM_REV"; Raisonance EXTERN near u16 MyClassBVariable; EXTERN near u16 MyClassBVariableInv; Note: When the version of STVD tool does not support including the vector table content into the checksum computation and the user wants to protect this part of the code, the proper linker script file must be modified by placing the vector table as follows: The line: “+seg .const -b 0x8000 -k” must be replaced by: “+seg .const -b 0x8000 -k -ck”. Note: Previously, “__ckdend__” symbol definition needed to be to included into linker script file for some older versions of Cosmic compiler. There is no longer any need to use it.
3.2.3 Application demonstration example
A short example of user application is attached in each project main.c file with respect to the package integration criteria (see Chapter 4: Class B solution structure). Except for STM8L_10x, the examples were written to run on the corresponding STM8 evaluation boards (STM8S/128-EVAL and STM8L1526-EVAL) as Class B package demonstration firmware. They use on board LCD and LED diodes to display current versus initial master clock frequency measurement changes. Display or LED outputs can be disabled in main.h file. The main loop also performs initialization and calling all run mode tests at ordinary intervals.
3.3 Package configuring and debugging
A functional part of the package may need to be changed, suspended, excluded or included. For example the microcontroller type might need to be changed or there could be a non-volatile memory space limitation. Modifications are also required to debug the user application. This section describes how the ST solution can be configured, modified and debugged.
3.3.1 Configuration control
compilation controlled by a predefined set of constants in this file. tested parts are not included in the application (e.g. HSE testing).
3.3.2 Verbose diagnostic mode
The Tx pin of dedicated UART interface is used to output text messages in verbose mode. startup, run mode or fail case only. user in Class B configuration file stm8x_stl_param.h. Figure 3. Diagnostic LED timing signal principle
Class B software package AN3181 16/31 Doc ID 17286 Rev 2
3.3.3 Debugging the package
While debugging the package, it is useful to disable:
- Reset in FailSafe() routine by servicing independent WDG,
- All program memory CRC checksum tests when using breaks in the code to prevent program memory checksum error occurrence
- Window WDG to prevent improper service out of the time slot window dedicated to refresh (a).
- Control flow monitoring (mostly done automatically by changing values of constants when some tests are omitted) At the debugging phase it may be useful to enable:
- Verbose Diagnostic mode to watch messages at UART terminal
- LEDs toggling to see basic process flow a.Window WDG feature is not available at STM8L10x devices
4 Class B solution structure
4.1 Integrating software into user application
regions which are permanently undergoing the transparent test as a part of run mode tests. interrupt tick. If any self test fails, FailSafe() routine is called. Figure 4. Integration of startup and periodi c run mode self tests into application
4.2 Detailed description of startup self tests
routine. The user must force the reset vector to the first address in STL_StartUp() routine.
- Watch dogs startup test
- CPU startup test
- Flash complete checksum test
- Full RAM March C-/X test
- Clock startup test
- Control flow checks These blocks are described in more details in the next chapters. User can control including them as usual in the configuration file stm8_stl_param.h.
Figure 5. startup self tests structure
4.2.1 Watchdog startup self test
successful end of the periodical run mode test in main loop.
Figure 6. Watchdogs startup self test structure
4.2.2 CPU star tup self test
FailSafe() routine is called. Figure 7. CPU startup self test structure
4.2.3 Flash complete checksum self test
linker result. FailSafe() routine is called if there is an error.
Figure 8) over the code memory content in the project.
- An 8-bit check sum calculation over the 16-bit address space can be used for checking up to 64 Kbytes of memory code, the simplest method.
- A 16-bit check sum calculation over the 16-bit address space can be used for checking up to 64 Kbytes of the memory code; this method is more precise and is the default method.
- A 16-bit check sum calculation over all the possible address space can be used when the code memory exceeds 64 Kbytes, 24-bit addressing must be used; this way uses the most code space and is the most time consuming. The STM8 firmware includes six separate source files defined for each of these methods. There is one pair for each method: one used for startup and one for run time. The user should include the correct source file pair into the project.
Figure 8. FLASH startup self test structure
4.2.4 Full RAM Marc h C-/X self test
Figure 9. RAM startup self test structure
4.2.5 Clock startup self test
speed external source (HSE). The CPU is running on the high speed internal source (HSI). default source. If there is no error, the test continues with the next step and HSE is checked. when no external oscillator is used.
Figure 10. Clock startup self test subroutine structure
- Low speed external (LSE) clock source can be start ed/checked at the beginning of the test and measured
feeding the dedicated timer on STM8L15x devices. They can be inserted into the beginning of this routine.
- High speed external (HSE) tests are skipped on STM8L10x devices.
- LSI frequency is different for STM8S and STM8L devices . That is why the four consequent LSI periods are
4.3 Periodic run mode self tests initialization
ensure that run mode tests are called properly and at regular intervals. variable pair as an initial reference sample of master frequency measure.
Figure 11. Periodic run mode self test initialization structure
4.4 Detailed description of pe riodic run mode self tests
4.4.1 Run time self tests structure
communication peripherals and application interrupts) are not automatically included.
- CPU core partial run mode test
- Stack boundaries overflow test
- Clock run mode test
- AD MUX self test (not implemented)
- Interrupt rate test (not implemented)
- communication peripherals test (not implemented)
- Flash partial CRC test including evaluation of the complete test
- IWDG and WWDG refresh
- Partial transparent RAM March C-/X test (under system interrupt scope) #LASS"VARIABLESINIT #LOCKMONITORINGINIT INITIALCLOCKREFERENCE,3)MEASUREMENT -AINTIMEBASEINIT #ONTROLFLOWCHECK 7RITEPATTERNONSTACKBOUNDARIES
Figure 12. Periodic run mode self test and time base interrupt service structure
4.4.2 CPU light run mode self test
not tested. In case of error, FailSafe() routine is called. Figure 13. CPU light run mode self test structure
4.4.3 Stack boundari es run mode test
the dedicated stack area when the pattern location is changed. Figure 14. Stack overflow run mode test structure
4.4.4 Clock ru n mode self test
Figure 15. Clock run mode self test structure
Figure 16. Clock run mode self test principle
4.4.5 Partial FLASH C RC run mode self test
computation cycle is initialized. Figure 17. Partial FLASH CRC run mode self test structure
- For more details about CRC calculation, please refer to Section 4.2.3: Flash complete checksum self test.
4.4.6 Watchdog service in run mode test
4.4.7 Partial RAM run mode self test
Figure 18. Partial RAM run mode self test structure
Figure 19. Fault coupling principle used at partial RAM run mode self test Table 4. March C- phases at RAM partial test
1 Test 0x00 pattern, write 0xFF pattern Increasing
- Steps 2 and 3 are skipped over w hen March X algorithm is used.
4 Test 0xFF pattern, write 0x00 pattern Decreasing
5 Test 0x00 pattern Decreasing
Table 5. STM8 Class B firmware packages
- Errors are manifested by error codes passed to FailSafe() routine.
- Window watchdog is available at STM8TL5x devices only.
- The stack is limited for some STM8S Access li ne devices and STM8A devices with up to 32 Kbytes
non-volatile memory; for proper values, see the corresponding datasheets.
- Stack is not limited for STM8TL5x devices; there is rollover (due to over/underflow) only if the stack
Revision history
Table 6. Revision history firmware package variations.