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

Datasheet File OCR Text:

june 2014 docid5833 rev 2 1/19 AN1015 application note software techniques for improvi ng microcontrollers emc performance introduction a major contributor to improved emc performance in microcontroller-based electronics systems is the design of hardened software. problems induced by emc disturba nces need to be considered as early as possible in the design phase. emc-oriented soft ware increases the security and the reliability of your application. emc-hardened soft ware is inexpensive to implem ent, improves the final goods immunity performance and saves hardware and development costs. you should consider emc disturbances to analog or digital data just like any other application parameter. examples of problems induced by emc disturbances: ? microcontroller not responding ? program counter runaway ? execution of unexpected instructions ? bad address pointing ? bad execution of subroutines ? parasitic reset and/or parasitic interrupts ? corruption of ip configuration ? i/o deprogramming examples of consequences of failing software: ? unexpected response of product ? loss of context ? unexpected branch in process ? loss of interrupts ? loss of data integrity ? corrupted reading of input values. this application note deals with two cat egories of software techniques, namely: ? preventive techniques: these can be implemented in existing designs, their purpose is to improve product robustness. ? auto-recovery techniques: when a runaway cond ition is detected, a recovery subroutine is used to take the decision to execute fail -safe routines, optionally sending a warning and then automatically returning back to normal operations (this operation may be absolutely transparent to the user of the application). www.st.com
contents AN1015 2/19 docid5833 rev 2 contents 1 related documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2 preventive techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 using the watchdog and time control techniques . . . . . . . . . . . . . . . . . . . . 6 2.2 securing the unused program memory area . . . . . . . . . . . . . . . . . . . . . . . 8 2.3 input filtering and comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4 management of unused interrupt vectors . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.5 removing illegal and critical by tes from your code . . . . . . . . . . . . . . . . . . 9 2.5.1 critical bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.5.2 iilegal bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.6 averaging the a/d converter results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.7 register reprogramming and regular checking . . . . . . . . . . . . . . . . . . . . 10 2.8 redundant data storage and exchange . . . . . . . . . . . . . . . . . . . . . . . . . . .11 3 auto-recovery techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1 saving your context in ram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2 using the watchdog for local control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3 using the reset flags to identify the reset source . . . . . . . . . . . . . . . . . . . 14 3.4 saving data into non-volatile memory . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4 which results can be achieved? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5 revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
docid5833 rev 2 3/19 AN1015 list of tables 3 list of tables table 1. summary of preventive techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 table 2. summary of auto-recovery techniqu es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 table 3. document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
list of figures AN1015 4/19 docid5833 rev 2 list of figures figure 1. classic examples of bad watchdog usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 figure 2. example of correct watchdog usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 figure 3. example of auto-recovery software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 figure 4. local control by the watchdog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 figure 5. identify reset sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
docid5833 rev 2 5/19 AN1015 related documents 18 1 related documents ? an3181 ?guidelines for obtaining iec 6033 5 class b certification in an stm8 application? ? an3307 ?guidelines for obtaining iec 6033 5 class b certification for any stm32 application? ? an4435 ?guidelines for obtaining ul/csa/ie c 60335 class b certification in any stm32 application?
preventive techniques AN1015 6/19 docid5833 rev 2 2 preventive techniques you can implement preventive techniques in exis ting designs to improve product robustness and immunity against external or internal emc disturbance. 2.1 using the watchdog and time control techniques the watchdog is the most efficient tool availa ble to ensuring that the mcu can recover from software runaway failures. its principle is very simple: it is a timer which generates an mcu reset at the end of count. once the watchdog is started, the only way of preventing the watchdog from resetting the microcontroller is to update the counter periodically in the program. but to make the watchdog work at its full potenti al, you have to insert the enable and refresh instructions in your software at the right place of code execution. figure 1 shows two classic examples of bad watchdog implementation. to do it the right way (see figure 2 ), the following rules sh ould be implemented: ? enable the watchdog as soon as possible after reset, or use the hardware option if available. ? never refresh the watchdog during an interrupt routine or inside any local loop not guarded by timeout at code. it is very important to optimize the period bet ween the two refresh instructions according to the duration of the various routines, including the interrupt routines. the minimum use of the watchdog resets the mc u, this means that the program execution context is lost as well as the application data's integrity. after reset, in addition to enabling the watchdo g, on some mcus you can use the reset flags to distinguish between power on or low voltage reset or watchdog reset (refer to section 3.3: using the reset flags to identify the reset source . for more details).
docid5833 rev 2 7/19 AN1015 preventive techniques 18 figure 1. classic examples of bad watchdog usage $ggu""" ,1),1,7( /223 :'*127 (1$%/(' :dwfkgrjhqdeohgwrrodwhdiwhu6wduwxs 069 ,17 :'*(1$%/( 6sxulrxv 3&mxps 6sxulrxv 5hvhw $ggu""" ,1),1,7(/223 :'*5()5(6+(' ,1,19$/,'/223 :dwfkgrjuhiuhvkhggxulqj,qwhuuxswurxwlqh 069 0$,1 ,17(55837 5287,1( :'* 5()5(6+ 5(7851 6sxulrxv 3&mxps
preventive techniques AN1015 8/19 docid5833 rev 2 figure 2. example of correct watchdog usage 2.2 securing the unused program memory area in most applications, program me mory space is not filled comple tely by user code. for extra security, fill the unused memory locations with code that forces a watchdog reset or jumps to a known program location if you do not want to generate a reset. this will ensure that even if the program counter is corrup ted and jumps to an unused memory location, the mcu will recover and return to no rmal operations. in this unused area you can also jump to a reco very fail safe subroutine, which allows you to return to normal operations. :'*(1$%/( ,17 ,17(55837 5287,1( 5(7851 0$,1:'*5()5(6+ (qdeohzdwfkgrjlpphgldwho\dw6wduwxs 1rzdwfkgrjuhiuhvkgxulqj,qwhuuxswurxwlqh 069
docid5833 rev 2 9/19 AN1015 preventive techniques 18 for stm8 users, the stm8 "trap" instruction is also very convenient (only one instruction byte:83) for generating a software interrupt in order to recover from a jump to an unexpected location in memory. another effective way for recove ry to normal operation is f illing memory by value of illegal instruction opcode which fetch and execution generates reset on stm8 microcontrollers. stm32 microcontrollers with arm ? cortex ? -m core use fault exce ption which trap illegal memory accesses and illegal program behavior wh ich may occure if t he system is exposed to emc disturbances. the unde fined instruction opcode may be used to fill the unused memory of stm32 microcontroller to rise the usage fault exception where the fail safe routine recovers from errors in case of program counter run-away. another option is to use system serivce call wi th svc instruciton to execute fail safe routine. 2.3 input filtering and comparison the routine which checks several times that t hat the state of input pin is stable before validating the state and continuing the program execution is a good practice to avoid unwanted reaction on spikes caused by external noise induced in input circuit. this is a simple means of critical input filtering for no extra cost! 2.4 management of unused interrupt vectors to avoid problems caused by unexpected interr upt occurrences (whatever the source) it is recommended to manage all the possible inte rrupt sources by putting a valid interrupt routine address in the corresponding vector. in the example below the unused interrupt vectors point to a fault management routine label filled with a simple ?return from interrupt? instruction. 2.5 removing illegal and crit ical bytes from your code 2.5.1 critical bytes a critical byte is an instruction switching mc u in low power modes which is decoded by the microcontroller and forces it to stop executing any further instructions. when the pc is corrupted it often becomes desynchronized (as most of the instructions have several bytes), and as a result it may read and decode critical bytes. to check and minimize the occu rrence of these critical bytes you can check the program ".list" file. very often critical bytes are generated by the compiler as label address bytes. in this case, if you simply insert one or seve ral nop instructions, all the l abel addresses will shift and this will change the critical byte value to another value. 2.5.2 iilegal bytes illegal bytes are defined as any byte value whic h is not part of the instruction set. they will either be executed as a nop in struction or (on some mcus) a re set is generated if an illegal
preventive techniques AN1015 10/19 docid5833 rev 2 byte is encountered. in this case, use the tech niques described above (for critical bytes) to remove illegal bytes from your code. 2.6 averaging the a/d converter results if you are performing a/d conversion, you can repeat conversions several times, store the results in the ram and then average them (or select the most frequently occurring values) to obtain accurate results in spite of any potential noise errors. 2.7 register reprogrammi ng and regular checking it rarely happens that emc disturbances alter the content of the regi sters. generally the registers concerned are clock control registers or i/o configuration and data registers because they are close to the chip output pads. in such cases a good security measure is to refresh these registers frequently. table 1. summary of preventive techniques software quality preventive techniques advantage disadvantage implementation watchdog (hardware or software) control is cpu- independent avoids mcu lock needs to be carefully handled if lp mode is used easy but the activation and refresh instructions must be carefully placed in the code for maximum efficiency force a watchdog reset in unused program memory more direct and quicker than waiting for a watchdog timeout loss of previous context clear the wdg reset bit (see device spec.) fill unused program memory with software interrupt instructions more direct and quicker than waiting for a wdg timeout. none fill unused area with "trap" or svc ? op-code and manage the failure in the corresponding interrupt routine. a/d converter averaging ensure the adc performance in a noisy surrounding. processing time perform an iterative loop for adc acquisitions and averaging. removal of illegal or critical opcode avoid mcu locks due to unexpected readings of wfet or wfi opcodes none, except restriction on using these opcodes string search in the ".list" file (see section 2.5 ). input filtering data acquisition stability processing time repeat measurement several times and perform a statistical choice between "0" or "1".
docid5833 rev 2 11/19 AN1015 preventive techniques 18 2.8 redundant data storage and exchange all the data stored in the internal or external memory can be subject to corruption due to electromagnetic disturbanc e in extreme conditions. the preventive technique of st oring doubled complementary values at nonadjacent memory areas, storing and checking the parity bits or ecc are all advanced methods which help to identify and/or correct the data corruption. refer to an4435 or safety manuals for more details on techniques improving software robustness available at st.com. unused interrupt management avoid runaways due to unexpected interrupts none very easy (see section 2.4 ) refreshing of critical registers safe running uses mcu resources refresh critical registers in frequently- executed loops table 1. summary of preventive techniques (continued) software quality preventive techniques advantage disadvantage implementation
auto-recovery techniques AN1015 12/19 docid5833 rev 2 3 auto-recovery techniques this section gives some techniques for quickly recovering your application context after an emc failure. unexpected resets, program counter jumps and parasitic interrupts are the most common emc failures observed in the mcu whatever the source of the disturbance. in any of these cases the ram (or eeprom data memory when available) remains unchanged and can be used as very efficien t way to save the application context and parameters. note that the ram will lose its contents if the device is power ed-off. the eeprom data keeps its content at power-off but the write time is much longer. 3.1 saving your context in ram figure 3 shows an example of a software auto-recovery implementation: the critical software sequences (door open or close commands, high speed motor controls) are memorized in a ram byte ("ram(seq)"). this allows us on the one hand to recover the context if an emc event leads to an mcu reset, and on the other hand we can check the source before a executing a critical subroutine. in this case the high speed motor activation is allowed only if ram(seq)=03). the application parameters (t1&t2 timing values) are also stored in ram when they are changed. this means if a software runaway event occurred or the mcu is reset (by the lvd or the watchdog), the recovery routine (crr) will restore the last door command, relo ad the timing parameters and resume the program execut ion without any external intervention.
docid5833 rev 2 13/19 AN1015 auto-recovery techniques 18 figure 3. example of auto-recovery software 3.2 using the watchdo g for local control very often programmers consider the watchdog timer more or less just as a time bomb and only refresh it to its maximum value to have the widest possible margin without any direct relation to the expected program execution time.
auto-recovery techniques AN1015 14/19 docid5833 rev 2 this is a poor approach, a far better method is to use the watchdog timer register to check the execution times of individual software rout ines and in case of an abnormality to react promptly before the watchdog end of count and ei ther perform an immediate reset or go into a software recovery routine. figure 4. local control by the watchdog 3.3 using the reset flags to identify the reset source there are several possible internal reset sources: lvd (low voltage detector) or watchdog reset, por (power on reset), hot reset (parasitic or external reset following a low state of the reset pin). the reset source is flagged in a ?reset register ? and this information is kept as long as the mcu's power supply is on. figure 5 shows how you can test the reset register at the beginning of your program and then branch to a context recovery routine (depending to the detected reset source) instead of restarting the "power on reset" initialization routine wh ich is often complex and time consuming. it is very important to detect and manage parasitic resets as they are the most usual cause of microcontroller emc failures. 069 7lphsurfhvvlqj f\fohv 0dlqsurjudp 5hdg:dwfkgrj 5hjlvwhu&doo6xeurxwlqh 3hulrg 5hvhw &rqwlqxhsurfhvvlqj 5hfryhu\ idlovdih 6xeurxwlqh uxqqlqj63 <hv 1r
docid5833 rev 2 15/19 AN1015 auto-recovery techniques 18 figure 5. identify reset sources 3.4 saving data into non-volatile memory the time needed to stor e data in the non-vola tile memory (data eeprom) is significantly longer compared with that needed for storing data into ram. during this programming time table 2. summary of auto-recovery techniques software quality auto-recovery techniques advantage disadvantage implementation local control by the watchdog process control of critical sequential blocks need to calculate an accurate time window check the sequence execution time using the wdg timer register identify reset sources fast recovery from unexpected reset failures none use the mcu "reset register" or the ram to detect various reset sources. application context save in ram, flash or eeprom save application parameters, ensure critical task execution resume in case of mcu failures. uses mcu resources store software critical phases and parameters in ram, flash or eeprom. use data in ram, flash or eeprom to recover the last context before failure. 069 ,17 5hdg5hvhw vwdwxviodjv 3rzhurq5hvhw rffxuuhg +rw5hvhw rffxuuhg &55 &rqwh[wuhfryhu\ urxwlqh &55 &rqwh[wuhfryhu\ urxwlqh :'*/9'5hvhw rffxuuhg ,1,7 ,1,7 :dlwiru'rru&0' 0dlq
auto-recovery techniques AN1015 16/19 docid5833 rev 2 the system may be compromised by emc dist urbances which results in system reset terminating the programming process, resulting in the data corruption. to prevent such situation the data should be stored in a redundant container keeping its consistency by using, among others, validation marks. the validity of content in this data containe r needs to be checked after each system start before actually using it.
docid5833 rev 2 17/19 AN1015 which results can be achieved? 18 4 which results can be achieved? st microcontrollers are designed, tested and op timized to remain fully functional with esd voltages (according en1000-4-2 standard) directly applied on any pin with voltage levels stated in their datasheets. although this perfor mance is good enough in most cases, it can be improved by using software techniques and at the same moment ensure an correct reaction of the system on emc level which is sometimes above 4kv. the properly designed system which is able to detect a corruption caused by emc disturbance, initiate and successfully comple te the auto recovery procedure resulting in system reset or reinitialization is always bett er then the system which does not detect any problem do not initiate an auto recovery mechanism and stay partially corrupted but without any visible change.
revision history AN1015 18/19 docid5833 rev 2 5 revision history table 3. document revision history date revision changes 02-jul-2001 1 initial release. 24-jun-2014 2 revised introduction , section 2 , section 2.1 , section 2.2 , section 2.3 , section 2.4 , section 2.5 , section 3.2 and section 4 added section 1: related documents , section 2.8: redundant data storage and exchange and section 3.4: saving data into non-volatile memory . updated figure 3 and figure 4 . updated table 1: summary of preventive techniques and table 2: summary of auto-recovery techniques .
docid5833 rev 2 19/19 AN1015 19 ? 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. st products are not designed or authorized for use in: (a) safety critical applications such as life supporting, active implanted devices or systems wi th product functional safety requirements; (b) aeronautic applications; (c) automotive applications or environments, and/or (d) aerospace applications or environments. where st products are not designed for such use, the purchaser shall use products at purchaser?s sole risk, even if st has been informed in writing of such usage, unless a product is expressly designated by st as being intended for ?automotive, automotive safety or medical? industry domains according to st product design specifications. products formally escc, qml or jan qualified are deemed suitable for use in aerospace by the corresponding governmental agency. 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. ? 2014 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 AN1015

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