View AN3181_8236781.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

november 2012 doc id 17286 rev 2 1/31 AN3181 application note guidelines for obtaining iec 60335 class b certification in an stm8 application introduction the role of safety has become very important for electronics applications. the level of safety requirements for components used in electronic designs is steadily increasing. the manufacturers of electronic devices include many new technical solutions in the design of new components. software techniques for improving safety are continuously being developed. the current safety recommendations and requirements are specified at worldwide level by recognized international standards bodies such as iec (international electrotechnical commission) and come under the compliance, verification and certification process of testing houses and authorities like vde (a ssociation for electrical, electronic and information technologies). the certification process is closely associated with electromagnetic compatibility (emc) tests when the robustness of the system against noise emission and noise sensitivity is tested for compliance with international standards. the main purpose of this applic ation note and its associated so ftware is to facilitate and accelerate user software development and certification processes for appliances which are subject to these requirements and certifications and are based on some of the st 8-bit family of microcontrollers. three packages certified by vde are provided for: mainstream stm8s and automotive stm8a high, medium and low density devices, ultra-low power medium-density stm8l and stm8al devices ultra-low power low density stm8l, stm8al and stm8tl touch-sensing devices. due to limited memory capacity of most of 8-bit devices all these packages are optimized and independent from other firmware libraries published by st. proper headers stm8xxx.h and stm8xxx_type.h from st standard peripheral libraries are included only to keep consistency of names of registers, bit masks and constants defined there. optimized code reduces program memory overhead and increases the code execution speed. all certified packages use similar principles de scribed by this document, with focus on main differences. while using hardware and firmware (see appendix a: stm8 class b firmware package variations ) compatibility between st families, these packages can also be adapted for some other st 8-bit microcontrollers not yet certified. ta bl e 1 lists the microcontrollers concerned by this application note. table 1. applicable products type product category microcontrollers stm8xxxx www.st.com
contents AN3181 2/31 doc id 17286 rev 2 contents 1 package variation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2 compliance with iec and vde standards . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1 generic tests included in the st firmware library . . . . . . . . . . . . . . . . . . . . 8 2.2 application specific tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.1 adc/dac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.2 i/os . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.3 interrupts and external communication . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.4 timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.5 external addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3 class b software package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1 basic software principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.1 fail safe mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.2 class b variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.3 class b flow control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2 package organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.1 projects and workspaces included in the package . . . . . . . . . . . . . . . . 13 3.2.2 tool specific integration of the library . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.3 application demonstration example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3 package configuring and debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.1 configuration control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3.2 verbose diagnostic mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3.3 debugging the package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4 class b solution structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1 integrating software into user application . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2 detailed description of startup self tests . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2.1 watchdog startup self test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.2 cpu startup self test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2.3 flash complete checksum self test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2.4 full ram march c-/x self test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2.5 clock startup self test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.3 periodic run mode self tests initialization . . . . . . . . . . . . . . . . . . . . . . . . . 22
AN3181 contents doc id 17286 rev 2 3/31 4.4 detailed description of periodic run mode se lf tests . . . . . . . . . . . . . . . . . 23 4.4.1 run time self tests structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.4.2 cpu light run mode self test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.4.3 stack boundaries run mode test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.4.4 clock run mode self test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.4.5 partial flash crc run mode self test . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.4.6 watchdog service in run mode test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.4.7 partial ram run mode self test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 appendix a stm8 class b firmware package variations . . . . . . . . . . . . . . . . . . 29 revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
list of figures AN3181 4/31 doc id 17286 rev 2 list of figures figure 1. example of ram memory configuration for stm8s20x . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 figure 2. control flow four steps check routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 figure 3. diagnostic led timing signal principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 figure 4. integration of startup and periodic run mode self tests into application . . . . . . . . . . . . . . . 17 figure 5. startup self tests structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 figure 6. watchdogs startup self test structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 figure 7. cpu startup self test structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 figure 8. flash startup self test structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 figure 9. ram startup self test structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 figure 10. clock startup self test subroutine structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 figure 11. periodic run mode self test initialization structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 figure 12. periodic run mode self test and time base interrupt service structure . . . . . . . . . . . . . . . . 24 figure 13. cpu light run mode self test structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 figure 14. stack overflow run mode test structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 figure 15. clock run mode self test structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 figure 16. clock run mode self test principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 figure 17. partial flash crc run mode self test structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 figure 18. partial ram run mode self test structure) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 figure 19. fault coupling principle used at partial ram run mode self test . . . . . . . . . . . . . . . . . . . . . 28
AN3181 package variation overview doc id 17286 rev 2 5/31 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 de vices 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
package variation overview AN3181 6/31 doc id 17286 rev 2 for more electromagnetic compatibility (emc ) information please re fer 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 comm ission) is a non-profit and non-governmental authority recognized worldwide for preparing and publishing international standards for a vast range of electrical, electronic and re lated technologies. iec standards are focused mainly on safety and performance, the enviro nment, electrical energy efficiency and its renewable capabilities. the iec cooperates clos ely 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 world wide in the field of electronic standard organizations are vde in germany, iet in th e 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 dest ined 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 complianc e 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-specif ic 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 seve ral 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 un ited states. in addition, an in creasing number of product
compliance with iec and vde standards AN3181 8/31 doc id 17286 rev 2 safety standards are being harmonized to international safety standards. for example, the ul 60335-1, the dsa 60335-1 and the en 60335-1 are all documents which are based on the iec 60335-1. vde 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 for electrical appliance manufacturers. the stm8 fw in this package has been vde certified. 2.1 generic tests included in the st firmware library stm8 firmware library packages include the following microcontroller specific software modules, which have also been certified by vde: 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 ta b l e 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 group components to be tested micro specific cpu registers cpu program counter clock fixed and variable memory spaces internal addressing internal data path application specific interrupt handling external communication and addressing (if any) timing i/o periphery adc and dac analog multiplexer
AN3181 compliance with iec and vde standards doc id 17286 rev 2 9/31 the user can include a part or all of these vde certified software modules into his project. if the modules stay unchanged and are integrated in accordance with the guidelines provided in this application note, development time and costs to have end-application certification would be significantly reduced. 2.2 application specific tests the user should be aware that the following are also required for class b certification but are not included in the st firmware library: 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 application note components to be verified method used cpu registers functional test a, x and y registers, flags and stack pointer is done at startup. in the run time flags are not tested. stack pointer is tested for overflow and underflow. if any error is found, the software jumps directly to the fail safe routine. program counters two different watchdogs driven by two independent clock sources can reset the device when the program co unter is lost. the window watchdog (driven by main oscillator) performs time slot monitoring (1) while the independent one (driven by low speed internal rc oscillator) is impossible to disable once enabled. both watchdogs must be serviced at regular intervals. program control flow is monitored by specific software method, additionally. (see section 3.1.3 ). 1. window wdg feature is not available at stm8l10x devices. addressing and data path this is tested indirectly by ram func tional and flash integrity tests, stack overflow (a specific pattern is writ ten at a low boundary of stack space and checked for corruption at regular intervals) and underflow (a second pattern is written at a high boundary if it is not at the ram end). clock two independent internal frequencies are used for the dedicated timer clock and they are verified by reciprocal comparison. one frequency is fed into the dedicated timer while the other gates it. non-volatile memory a 16-bit crc software checksum test of the entire memory is done at startup and a partial memory test is repeated at runtime (block by block). variable memory space march c- (march x optionally) full memory test is done at startup. partial memory test is repeated at run time (block by block). word protection with double inverse redundancy (inverse values stored in non-adjacent memory space) is used for safety critical class b variables. class a 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 app lication and peripheral c apabilities. 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.
AN3181 class b software package doc id 17286 rev 2 11/31 3 class b software package this section highlights the basi c common principles used in st software solution. the workspace organization under different tools is described together with its configuration and debugging capabilities. 3.1 basic software principles the basic software methods and common principles used for all the tests included in the st firmware library are described in detail at this section. 3.1.1 fail safe mode failsafe() routine is called (defined in stm8x_stl_startup.c file) at any fail detection. the program stays in a never ending loop waiting for wdg reset. except for some debugging features, the routine is almost empty. when editing this routine, the user must remember to include procedures necessary to keep the application in a safe state. if the user wants to recognize the error raised, the debug or verbose mode described in section 3.3: package configuring and debugging can be used. in debug mode the independent wdg is refreshed inside the never ending loop to prevent resetting the 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. they are always stored as a pair of complementary values in two separate ram areas. both normal and redundant values are always placed into non-adjacent memory locations. partial transparent ram march c- or march x test is performed permanently on these two regions through the system interrupt routines in run mode. the integrity of the pair is compared before the value is used. if any value stored is corrupted, failsafe() routine is called. an example of ram configuration is shown in figure 1 . the user can adapt the ram space allocation according to applic ation needs and with respect to device hardware capability. figure 1. example of ram memory configuration for stm8s20x :ero0age #lass"variables redundantcomplementaryvalues #lass"variables normalvalues #lass!variables 3pecificpatternisstoredhereto detectstackoverflowunderflow 3tack x x x x x x x&& !)
class b software package AN3181 12/31 doc id 17286 rev 2 3.1.3 class b flow control a specific method is used to test and chec k program execution flow. unique user defined numbers are assigned for every software execution block. these unique numbers are stored in two complementary counters. when a block is executed, a symmetrical four step change of the counter pair content is done (add or subtract the label values). the first two steps check if the block is correctly called from main flow level (processed just before calling and just after return from the called procedure). the next two steps check if the block is correctly completed (processed just after enter and just before return from the procedure). an example is given in figure 2 where a routine performing a component test is called in the control flow sequence and the four step checking service is shown. this method decreases cpu load as the check is done by counting one member of the complementary counter pair only. as there is always the same number of call/return and entry/exit points, the value stored in the counter pair must be always complementary after any block is processed. several flow check points are placed subsequently in the code flow. counter integrity is always checked here and any unexpected value results in calling the failsafe() routine. figure 2. control flow four steps check routine 1. for this example, the unique number for component test 1 is ?5? and for the procedure itself it is defined as ?7?. the counters are initialized to 0x0000 and 0x ffff. the table in the upper right corner in figure 2 shows how the counters are changed in four steps. also shown is their complementary value after the last step (return from procedure) is done. %xecutionflowsequence !) #ounter#ounter? 8/2 xx&&&& x#x&&& x#x&&& x#x&&&& x&&&! x&&& x&&& &ail3afe routine #omponenttestn #omponenttest &ail #ounter#ounter= #omponenttest #ounter?#ounter? = #ounter#ounter= #ounter?#ounter? = &lowcheckpoint check #ounter value and #ounter8/2#ounter?x&&&& x&&&&
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 pa ckage using different toolchains. the project for iar c-compiler is done under iar ewstm8 en vironment, while projec ts for both cosmic and raisonance c-compilers are done as st visual develop (stvd) project workspaces. the corresponding project.eww or project.stw proj ect 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 rel ease 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 in itialization starts. therefor e 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 placemen t 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. doub le storage in class_b_ram and class_b_ram_rev separated segments is nece ssary 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 re placed 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 initializati on and calling all run mo de 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.
AN3181 class b software package doc id 17286 rev 2 15/31 3.3.1 configuration control software configuration is done at two levels. the first one is automatic and consists of configuring the project for a given microcontroller. this is done by selecting the corresponding device project while adapting its preprocessor user-defined options. the second one is done through user configuration. all user defined configuration settings are collected in the class b configuration file stm8x_stl_param.h . the user must be very careful when modifying this file. most of the package functional blocks are under conditional compilation controlled by a predefined set of constants in this file. it is possible to disable some part(s) of the library by putting definitions in comments. this is useful e.g. disable flash crc when break points are inserted to debug the code. the full class b package, even optimized and with disabled verbose messages, takes about 3.5 kbytes of code memory. disabling some library parts could be required for microcontrollers where the memory space is too small for applicatio n needs or when the 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. this mode is useful in debug phase as the interface can be connected to an external terminal (the line setting is 115200 bd, no parity, 8-bit data, 1 stop bit). however the text messages consume too much code space in th is mode. different levels of verbose mode can be enabled or disabled by the user through definition of constants in the class b configuration file stm8x_stl_param.h . for example, verbose mode could be limited to startup, run mode or fail case only. leds toggling is another way to verify a class b event. first led toggles at each begin and end of run mode checks and with every successful finish of program memory test. next led toggles with each begin and end of ram partial check called on at each tick interrupt and with every successful finish of the ram memory test. leds slow toggling signals the main processes and quick pulses modulated on the slow signal correspond to the length of partial services, in other words, the loading time (see figure 3 ). led control can be disabled by user in class b c onfiguration file stm8x_stl_param.h . note: verbose mode via uart line is not used at stm8l10x package. error codes are passed to failsafe() routine instead. figure 3. diagnostic led timing signal principle #omplete#lass"testperiod 0artialtest period 0artialtest duration !)
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
AN3181 class b solution structure doc id 17286 rev 2 17/31 4 class b solution structure 4.1 integrating software into user application class b routines are divided into two main processes: periodic run mode self tests and startup tests. the periodic run mode test must be initialized by the set-up block before it is applied. all the blocks are checked by sufficient flow control checked at a number of flow check points (see section 3.1.3: class b flow control ). all class b variables are kept redundantly in a pair of control registers stored in the class b variable space defined by user (see section 3.1.2: class b variables ). this variable space is split into two separate ram regions which are permanently undergoing the transparent test as a part of run mode tests. figure 4: integration of startup and periodic run mode self tests into application shows the basic principle of how to integrate the class b software package into user software. the reset vector should be forced by the user to stl_startup() routine which collects all system startup self tests. if they pass successfully, then the standard initialization procedure of c-compiler routine is performed. while the app lication is running, periodic tests must be executed at regular intervals. to ensure this, the user must initialize these tests by calling the initialization routine stl_initruntimechecks() before entering main loop and then inserting a periodical call of stl_doruntimechecks() at main level. for best results, this should be inside the main loop . tim4 (or tim6 for some devices), which is configured during initialization routine to generate periodic system interrupts, provides the time base for all the tests. short partial transparent ram march c- or march x check is performed at each 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 the startup self test is forced during initialization phase as the earliest checking process after resetting the microcontroller (see figure 4 ) and before standard application startup 2%3%4 3tartupselftest 34,?3tart5p !pplicationstartup 0eriodicruntimeselftestinit 34,?)nit2un4ime#hecks -ainloop 0eriodicruntimeselftest 34,?$o2un4ime#hecks 4ask 4ask 4ask 4imebase)32 4)-x?50$?/6&?)21(andler )32 )32 &ail3aferoutine &ail3afe !)
class b solution structure AN3181 18/31 doc id 17286 rev 2 routine. the user must force the reset vector to the first address in stl_startup() routine. the startup tests block structure is shown in figure 5 and includes the following self tests: 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 t he configuration file stm8_stl_param.h . figure 5. startup self tests structure 4.2.1 watchdog startup self test the first startup self test is to enter wdg self test routine. the program passes through this routine three times. first the routine checks th e reset source in reset status register. if independent watchdog (iwdg) is not flagged in reset status register, then reset sources is cleared and iwdg test begins. the iwdg is set to the shortest period and the microcontroller is reset by hardware and iwdg flag is set (see figure 6 ). the routine comes back to the beginning and check wdg flags. when iwdg is recognized, it looks for wwdg flag. if wwdg is not flagged, the test continues a second time with window watchdog (wwdg) test. again the microcontroller is reset by hardware and wwdg flag is set. when both wdg flags are set in the reset status register, the test is assumed as finished and both flags are cleared. wwdg is not present at stm8l10x devices, so wwdg test is not present. user must carefully set both iwdg and wwdg periods. time periods and window refresh parameters must be set according to the time base interval because refresh is done at the successful end of the periodical run mode test in main loop. 2%3%4 7atchdogsselftest #05coreselftest &lashintegritycheck 2!-functionalcheck #lockfrequencycheck #ontrol&lowcheck 2esume#startup &ail3afe routine &ail &ail &ail &ail &ail !) (7reset
AN3181 class b solution structure doc id 17286 rev 2 19/31 figure 6. watchdogs startup self test structure 4.2.2 cpu star tup self test core flags, registers and stack pointer are tested for functionality. in case of any error, failsafe() routine is called. figure 7. cpu startup self test structure 4.2.3 flash complete checksum self test the crc checksum computation is performed over the entire flash memory space announced by linker checksum structure. the resulting computation is compared with the linker result. failsafe() routine is called if there is an error. )7$'&lag 2eset&lags 4est)7$' 4est77$' 77$'reset 2eset&lags 4est/+ .o .o 9e s 9e s !) (72esetto beginningof routine (72esetto beginningof routine 4est!89 6erifyramppattern!89 4est/+ 4est3tack0ointer &ail3afe routine 4est&lags &ail &ail &ail &ail !)
class b solution structure AN3181 20/31 doc id 17286 rev 2 the user actually has a choice of three di fferent methods for calculating the crc (see 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 the whole ram space is alternately filled an d checked simultaneously by zero and 0xff pattern in six loops, either by march c- or march x algorithms. march x algorithm is faster as the two middle steps are skipped over. the first three loops are performed in incremental order of addresses the last three in decremented order. in case of error, failsafe() routine is called. &ail3afe routine .o 4est/+ bit#2# ?checksum 9e s #ompute bit#2#checksum !)
AN3181 class b solution structure doc id 17286 rev 2 21/31 figure 9. ram startup self test structure 4.2.5 clock startup self test when the test begins, first the low speed internal clock (lsi) source is started, then the high speed external source (hse). the cpu is running on the high speed internal source (hsi). hsi is switched onto a dedicated timer input, mainly tim3, but tim1 or tim2 can also be used on some devices. the timer is gated by the lsi source. the number of gated ticks is compared and if it falls outside of the predefined interval (more than +/- 25% from nominal value) an hsi fail is signaled and failsafe() routine is called. cpu clock continues with hsi, default source. if there is no error, the test continues with the next step and hse is checked. hse is switched on as the new cpu clock sour ce and input into the dedicated timer. the same measurement and check of gated ticks are repeated but with hse feeding the timer. if the measure falls out of the interval, cpu clock is immediately turned back to hsi and hse fail is signaled with a failsafe() routine being called. otherwis e, the test returns ok. cpu clock is switched back to default hsi source after the test is finished. all the parts of this test are under conditional compilation control, so the user can skip over some test e.g. hse test when no external oscillator is used. 7ritex #heckx7ritex&& 4est/+ &ail3afe routine &a il &a il &a il #heckx&&7ritex #heckx7ritex&& #heckx&&7ritex #heckx &a il &a il )ncreasingorder ofaddresses $ecreasingorder ofaddresses !)
class b solution structure AN3181 22/31 doc id 17286 rev 2 figure 10. clock startup self test subroutine structure 1. 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. 2. high speed external (hse) tests are skipped on stm8l10x devices. 3. lsi frequency is different for stm8s and stm8l devices . that is why the four consequent lsi periods are gated at stm8s devices (lsi=128 khz) and only one period is used for measure on stm8l devices (lsi=38 khz). 4.3 periodic run mode self tests initialization run time self tests must be initialized just before th e program enters the main loop performing the run mode self tests (refer to figure 4 ). this must come just after start-up self tests have been executed and standard initialization done. the timing should be set to ensure that run mode tests are called properly and at regular intervals. all class b variables must first be initialized. zero and its complement value are stored in every class b variable complementary pair. the magic pattern is than stored at the top of stack space. timer peripherals are configured for the tick interval measurement and master clock frequency measurement. master frequency is gated by the lsi clock. the same method as for startup test is used. the resulting number of pulses is stored into the class b variable pair as an initial reference sample of master frequency measure. 3tartof,3)clock 3tartof(3%clock 4est/+ &ail3afe routine &ail -easure,3)frequency by(3) 3witchclockfrom(3)to(3% &ail -easure,3)frequency by(3% 9e s 9e s 3witchclockfrom(3%to(3) 3witchclockback from(3%to(3) !) ,3)frequency inrange ,3)frequency inrange .o .o
AN3181 class b solution structure doc id 17286 rev 2 23/31 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 run time self tests are performed periodically, their period is based on time base interrupt settings. before the first run, all tests must be initialized by run mode initialization routine (refer to figure 4 ). all tests are performed in the main loop level except partial transparent ram test, which is executed during the time base interrupt service. some tests (analog, communication peripherals and application interrupts) are not automatically included. depending on device capability a nd application needs, the user could implement them. the following is the list of the run mode self tests: 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 !)
class b solution structure AN3181 24/31 doc id 17286 rev 2 figure 12. periodic run mode self test and time base interrupt service structure 4.4.2 cpu light run mode self test cpu core run mode self test is a simplified startup test where the flags and stack pointer are 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 magic pattern stored at the top of the stack is checked here. in case the original pattern is corrupted, failsafe() routine is called. the pattern is placed at the lowest address dedicated for stack area.overflow and underflow are detected as the stack pointer rolls over 0artial#05coretest 3tackboundariestest #locktest 0artial&lashtest #ontrolflowcheck )7$'and77$'refresh &a il &a il &a il &a il &a il )nterruptratetest #ommperipheralstest !$-58test .ot implemented &a il &ail &a il &ail3afe routine 0artial 2!-test 2eturn &a il 4ime"ase)32 &rommain 2esumemain 4"&lag 4ick4ime "ase 4ick 4"&lag&alse 4ick 4"&lag4rue 4rue &a lse 9e s .o !) 4est !89 6erifyramppattern!89 4e st/+ &ail3afe routine &ail &ail !)
AN3181 class b solution structure doc id 17286 rev 2 25/31 inside this range in both cases. this area differs among the devices. the user must respect 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 the current master clock frequency selected by user application is gated by lsi internal clock source. the resulting number of pulses is compared with the initial master frequency reference sample measure which was stored during initial run mode self tests. when there is more than +/-25% difference found, failsafe() routine is called. occasional over captured measure is ignored. it can appear when a longer user interrupt service corrupts current measurement. figure 15. clock run mode self test structure 4est/+ &ail3afe routine &ail !ny difference 9e s .o !) #hecklowerpattern 4est/+ &ail3afe routine -easure,3)frequency bycurrentclocksource &ail -easure overcaptured ,3)frequency inrange .o 9e s .o 9e s #ompare,3)frequency withinitialreference measurement !)
class b solution structure AN3181 26/31 doc id 17286 rev 2 figure 16. clock run mode self test principle 4.4.5 partial flash c rc run mode self test partial 16-bit crc checksum over the flash memory block is performed in every step. the boundaries are given in the segment table created by the linker. when the last block is reached the crc checksum is compared with the value stored by linker at the last record in the segment table. in case of a difference, failsafe() routine is called, otherwise a new computation cycle is initialized. figure 17. partial flash crc run mode self test structure 1. for more details about crc calculation, please refer to section 4.2.3: flash complete checksum self test . !ccepted range 'atingby ,3)clock -asterclock counting &^2ef &2ef &2ef 2untimemeasure )nitialreference measure 2eferencelevel x !) #omputecontinuous#2# &,!3(?pointer at2/-?%.$ #2# ?checksum &,!3(?0ointer 4est/ngoing )nit#2#computation 4est/+ &ail3afe routine .o .o 9e s 9e s !)
AN3181 class b solution structure doc id 17286 rev 2 27/31 4.4.6 watchdog service in run mode test if the run mode service block is correctly completed, then both window and independent watchdogs (wdgs) are refreshed at the last step just before returning to the main loop. to correctly refresh watchdogs, t he user must ensure calling stl_doruntimechecks() routine (see figure 12 ) at corresponding intervals in order to be able to properly react to the time base flag change. only one wdg refresh inside the main loop is necessary and contributes to overall efficiency. there should be no other wdg refresh except the one in stl_doruntimechecks() routine. sometimes it is necessary to refresh wdgs at initialization phase, too. in this instance, the refresh should be outside of any software infinite loop. 4.4.7 partial ram run mode self test partial transparent ram test is performed inside the time base interrupt service. the test covers the part of the ram containing the class b variables. one block of six bytes is tested at every test step. to guarantee coupling fault coverage, consecutive test steps are performed on memory blocks with an overlapping of two adjacent bytes. during the first phase, the block content is stored in the storage buffer. the next phase is to perform the marching destructive tests on all the bytes in the tested ram block. then, the final step is to restore the original content. march x algorithm is faster as two middle marching steps are skipped over (see ta b l e 4 ). the last test sequence step is to perform a marching test on the storage buffer itself, again with the next two additional bytes to cover coupling faults. then the whole test is re-initialized and it begins again. in case any fault is detected, failsafe() routine is called. figure 18. partial ram run mode self test structure ) 2!-?pointer%nd of#lass"2!- 3avecontentof2!- blockintothe"uffer !pply-archtesttothe 2!-block 2estorecontentof2!- blockfromthe"uffer 2!-?pointerblock?size 4est/ngoing !pply-archtest tothe"uffer &ail3afe routine 4est/+ 2!-?pointer3tart of#lass"2!- 9e s .o &ail &ail !)
class b solution structure AN3181 28/31 doc id 17286 rev 2 figure 19. fault coupling principle used at partial ram run mode self test table 4. march c- phases at ram partial test march phase partial bytes test over the block address order initial write 0x00 pattern increasing 1 test 0x00 pattern, write 0xff pattern increasing 2 (1) 1. steps 2 and 3 are skipped over w hen march x algorithm is used. test 0xff pattern, writ e 0x00 pattern increasing 3 (1) test 0x00 pattern, write 0xff pattern decreasing 4 test 0xff pattern, write 0x00 pattern decreasing 5 test 0x00 pattern decreasing !)
AN3181 stm8 class b firmware package variations doc id 17286 rev 2 29/31 appendix a stm8 class b firmware package variations table 5. stm8 class b firmware packages stm8s/a package medium density stm8l/al package low density stm8l/al/tl package optional uart verbose mode yes yes no (1) 1. errors are manifested by error codes passed to failsafe() routine. demo mode with optional lcd screen yes yes no window watchdog test yes yes no (2) 2. window watchdog is available at stm8tl5x devices only. high speed external (hse) clock test yes yes no low speed external (lse) clock test no yes no low speed internal (lsi) frequency / number of lsi periods used at clock tests (measurement) 128 khz / 4 38 khz / 1 38 khz / 1 stack space at the top of ram [bytes] 1024 / 512 (3) 3. the stack is limited for some stm8s access li ne devices and stm8a devices with up to 32 kbytes non-volatile memory; for proper val ues, see the corresponding datasheets. 513 513 (4) 4. stack is not limited for stm8tl5x devices; there is rollover (due to over/underflow) only if the stack overlaps the 4 kbytes.
revision history AN3181 30/31 doc id 17286 rev 2 revision history table 6. revision history date revision description of changes 01-jun-2010 1 initial release 29-nov-2012 2 modified introduction and document throughout to include all new members of the stm8 family. added section 1: package variation overview and ta bl e 1 : applicable products . modified table 3: overview of methods used in micro-specific tests provided with this application note and appendix a: stm8 class b firmware package variations .
AN3181 doc id 17286 rev 2 31/31 please read carefully: information in this document is provided solely in connection with st products. stmicroelectronics nv and its subsidiaries (?st ?) reserve the right to make changes, corrections, modifications or improvements, to this document, and the products and services described he rein at any time, without notice. all st products are sold pursuant to st?s terms and conditions of sale. purchasers are solely responsible for the choice, selection and use of the st products and services described herein, and st as sumes no liability whatsoever relating to the choice, selection or use of the st products and services described herein. no license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted under this document. i f any part of this document refers to any third party products or services it shall not be deemed a license grant by st for the use of such third party products or services, or any intellectual property contained therein or considered as a warranty covering the use in any manner whatsoev er of such third party products or services or any intellectual property contained therein. unless otherwise set forth in st?s terms and conditions of sale st disclaims any express or implied warranty with respect to the use and/or sale of st products including without limitation implied warranties of merchantability, fitness for a parti cular purpose (and their equivalents under the laws of any jurisdiction), or infringement of any patent, copyright or other intellectual property right. unless expressly approved in writing by two authorized st representatives, st products are not recommended, authorized or warranted for use in milita ry, air craft, space, life saving, or life sustaining applications, nor in products or systems where failure or malfunction may result in personal injury, death, or severe property or environmental damage. st products which are not specified as "automotive grade" may only be used in automotive applications at user?s own risk. resale of st products with provisions different from the statements and/or technical features set forth in this document shall immediately void any warranty granted by st for the st product or service described herein and shall not create or extend in any manner whatsoev er, any liability of st. st and the st logo are trademarks or registered trademarks of st in various countries. information in this document supersedes and replaces all information previously supplied. the st logo is a registered trademark of stmicroelectronics. all other names are the property of their respective owners. ? 2012 stmicroelectronics - all rights reserved stmicroelectronics group of companies australia - belgium - brazil - canada - china - czech republic - finland - france - germany - hong kong - india - israel - ital y - japan - malaysia - malta - morocco - philippines - singapore - spain - sweden - switzerland - united kingdom - united states of america www.st.com

▲Up To Search▲

Price & Availability of AN3181

	To Download AN3181 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .