guide to iec 60730 class b compliance with tinyavr®...

AN2632 Guide to IEC 60730 Class B Compliance with tinyAVR® 1-

series

Features

• List of Class B component test requirements• Firmware library for general Class B tests

Description

IEC 60730 is a safety standard for household appliances that address many aspects of both productdesign and operation. This standard is also referred to by other standards for safety-critical devices, e.g.IEC 60335. System-wide compliance with this standard is necessary for an appliance to be certified assafe to operate.

This application note is a guide to compliance with Annex H of the standard. Annex H deals withrequirements for electronic controls. A certified firmware library and usage examples for IAR EmbeddedWorkbench® and AVR® GCC are supplied. The firmware library is designed to cover the most generalparts of the standard. How the tests are run, when, and what additional tests might be needed, dependson both the application and implementation choices. In general, a Fault in any part should not cause ahazard.

The 1. Definitions in Annex H of IEC 60730 chapter presents some definitions from the IEC 60730standard. The 2. Class B Requirements and 3. Component Tests chapters describe the requirements forClass B software. 4. Class B Library for tinyAVR 1-series introduces the Class B library and the filesincluded for the tinyAVR® 1-series. The 5. Registers, 6. Program Counter, 7. Interrupt Handling, 8. System Clock, 9. Memory, and 10. Analog I/O chapters describe in detail the embedded self-tests in thelibrary. 11. Additional Safety Features in the tinyAVR 1-Series presents other safety features included inthe tinyAVR® 1-series.

© 2018 Microchip Technology Inc. Application Note DS-00002632B-page 1

Table of Contents

Features.......................................................................................................................... 1

Description.......................................................................................................................1

1. Definitions in Annex H of IEC 60730......................................................................... 41.1. Software Classes......................................................................................................................... 41.2. Control Structures........................................................................................................................ 4

2. Class B Requirements...............................................................................................5

3. Component Tests.......................................................................................................73.1. CPU Registers – Component 1.1.................................................................................................73.2. Program Counter – Component 1.3............................................................................................. 73.3. Interrupts – Component 2.............................................................................................................73.4. Clock – Component 3...................................................................................................................83.5. Static RAM – Components 4.2, 4.3, and 5...................................................................................83.6. Flash and EEPROM – Components 4.1.......................................................................................83.7. External Communication – Component 6.....................................................................................93.8. Input/Output Peripheral – Component 7.......................................................................................9

4. Class B Library for tinyAVR® 1-series......................................................................104.1. Error Handling............................................................................................................................ 104.2. Source Files................................................................................................................................11

5. Registers................................................................................................................. 13

6. Program Counter..................................................................................................... 156.1. How the Self-Diagnostic Routine Can Be Tested.......................................................................18

7. Interrupt Handling.................................................................................................... 19

8. System Clock...........................................................................................................21

9. Memory....................................................................................................................229.1. Invariable Memory......................................................................................................................229.2. Variable Memory........................................................................................................................ 239.3. Further Coverage....................................................................................................................... 24

10. Analog I/O................................................................................................................25

11. Additional Safety Features in the tinyAVR 1-Series.................................................26

12. Appendix - Terms and Abbreviations.......................................................................27

13. Acknowledgements................................................................................................. 28

AN2632


14. References and Suggested Literature.....................................................................29

15. Revision History.......................................................................................................30

The Microchip Web Site................................................................................................ 31

Customer Change Notification Service..........................................................................31

Customer Support......................................................................................................... 31

Microchip Devices Code Protection Feature................................................................. 31

Legal Notice...................................................................................................................32

Trademarks................................................................................................................... 32

Quality Management System Certified by DNV.............................................................33

Worldwide Sales and Service........................................................................................34

AN2632


1. Definitions in Annex H of IEC 60730

1.1 Software ClassesAnnex H of the IEC 60730 safety standard defines three classes of control software for appliances:

• Class A – Control functions which are not intended to be relied upon for the safety of the equipment(H.2.21.1).

• Class B – Software that includes code intended to prevent hazards if a Fault, other than a softwareFault, occurs in the appliance (H.2.21.2).

• Class C – Software that includes code intended to prevent hazards without the use of otherprotective devices (H.2.21.3).

Software used in protective control functions are either Class B or Class C. This application note dealswith Class B controls, which applies to most household appliances.

1.2 Control StructuresClass B controls can be designed according to one of three defined structures (H.11.12.2):

• Single channel with functional test – A single channel structure in which test data is introduced tothe functional unit prior to its operation (H.2.16.5).

• Single channel with periodic self-test – A single channel structure in which components of thecontrol are periodically tested during operation (H.2.16.6).

• Dual channel without comparison – A structure which contains two mutually independent functionalmeans to execute specified operations (H.2.16.1).

The term channel refers to the number of MCUs in the appliance. The single channel structure tends tobe the preferred structure since it has the lowest cost.

A single channel structure with functional test means that the system is tested at the point of manufactureonly. This structure can only be used if the appliance does not use any components that require periodictesting. Periodic testing is a safer option because this allows for faults to be detected during operation ofthe product. The time interval between the tests must typically be shorter than the time it takes for a Faultin the relevant component to cause a hazard.

Dual channel without comparison is essentially a structure in which two MCUs operate independently withdifferent tasks and either MCU can check that the other is operating correctly. One approach is to use oneMCU strictly for supervision, rather than sharing control tasks between the two. In this case, a lower costdevice can often be used as the supervisor.

This application note focuses on the single channel structure.

AN2632Definitions in Annex H of IEC 60730


2. Class B RequirementsFor an appliance to comply with the Class B requirements, the control software must detect and handlethe faults specified for the system components in Table 2-1. In addition to these tests and Faultdetections, the software must be properly documented to pass a certification. This includes the programsequence, control and data flow, timing, Fault tree, and general design philosophy.

Table 2-1. Short Overview of Components and Faults/Errors for Test (Table H.11.12.7)

Component Component to Test Typical Error Detected by Tests

1 CPU -

1.1 Registers Stuck at

1.3 Program counter Stuck at

2 Interrupt handling and execution No/too frequent interrupts

3 Clock Wrong frequency

4 Memory(1) -

4.1 Invariable memory All single bit faults

4.2 Variable memory DC Fault

4.3 Addressing Stuck at

5 Internal data path(1) -

5.1 Data Stuck at

5.2 Addressing Wrong address

6 External communication -

6.1 Data Too long Hamming distance

6.3 Timing Wrong point in time

7 I/O peripherals -

7.1 Digital I/O Fault conditions specified in H.27.1(2)

7.2.1 A/D- and D/A-converter Fault conditions specified in H.27.1(2)

7.2.2 Analog multiplexer Wrong addressing

9 Custom chips (ASIC, GAL, Gate array,etc.)

Any output outside static and dynamicfunctional specifications

Note: 1. These are essentially the same for AVRs since SRAM, Flash, and EEPROM are all internal.2. This table lists various external components and indicates whether a short and/or open Fault must

be detected.

Several of these tests are inevitably application dependent. As an example, for I/O peripherals it isrequired to do plausibility checking of the input/output signals. This, in turn, depends on both the

AN2632Class B Requirements


application and its implementation. The firmware library supplied with this application note, therefore,cannot cover all of the requirements in Table 2-1.

AN2632Class B Requirements


3. Component TestsAcceptable Fault detection measures and considerations for some of the individual components in Table2-1, that are relevant to the tinyAVR® 1-series, are described in this chapter.Note: The single channel structure with a functional test cannot be used if functional test is not listedunder acceptable measures for the components used in the appliance.

3.1 CPU Registers – Component 1.1Purpose of the test: Detect stuck bits in the registers.

The CPU registers are the most vital part of the MCU and must be tested since the correct operation isimpossible with faulty registers.

Acceptable measures for Fault detection are functional test and/or periodic self-test using static memorytesting or word protection with a parity check. In the included library static memory testing has beenchosen because the parity check would require a hardware implementation, which is not an option withthe tinyAVR® 1-series. The static memory test can be executed either as a functional test or as a periodicself-test depending on the application requirements.

3.2 Program Counter – Component 1.3Purpose of the test: Detect stuck bits in the program counter.

A correctly functioning program counter is important for any software to successfully run on an MCU. Theprogram counter cannot be tested directly for stuck bits since any such test will rely on the programcounter to function correctly in the first place.

Acceptable measures for Fault detection are functional test, periodic self-test, independent time-slotmonitoring, or logical monitoring of program sequence.

The preferred solution is to use the watchdog for indirect time-slot monitoring of the application. If aprogram counter Fault occurs, the watchdog timer will either be reset at the wrong time or not reset at all,eventually causing a device reset. Since it is an integral safety feature, the tinyAVR® 1-series watchdogmust be tested for proper operation in both regular and window mode before it can be relied on forcatching program counter faults.

After the watchdog has been tested, it should be enabled in window mode at all times. The closed periodshould be at least as long as the open period, that is, at least 50% of the total period.

3.3 Interrupts – Component 2Purpose of the test: Verify that interrupts occur and are handled at the expected rate.

Most applications rely on interrupts for their operation and it is therefore important to verify that theseoccur at the time they are expected and are handled accordingly.

Acceptable measures for Fault detection include functional testing and/or time-slot monitoring of theinterrupts. Time-slot monitoring is recommended since this will help detect faulty operation once theappliance is in use. Any interrupt testing will also indirectly test the interrupt controller.

AN2632Component Tests


3.4 Clock – Component 3Purpose of the test: Detect unexpected deviations in system clock frequency.

For the MCU to operate correctly and with correct timing, the frequency of the system clock must beverified to be within specification.

Acceptable measures for Fault detection are frequency or time-slot monitoring. The requirement is todetect that it is not oscillating at a frequency that will cause problems for proper application execution.

The AVR tinyAVR® 1-series event system allows for timer/counter captures to be triggered by an externalclock signal or the RTC (Real-Time Counter), allowing for frequency comparison between a referenceclock and the system clock.

3.5 Static RAM – Components 4.2, 4.3, and 5Purpose of the test: Detect stuck bits and coupling faults in SRAM and on the data bus, as well as anyaddressing problems.

The internal SRAM is used for volatile storage of data and any faults related to this can be catastrophicfor the appliance control.

Acceptable measures for Fault detection include periodic testing and/or data redundancy, e.g. parity bits.The latter is cumbersome without hardware implementation specific for this purpose, leaving periodictesting with, e.g. March algorithms as the best choice.

If the entire SRAM cannot be tested in one go, the tested memory sections must have some overlap toallow for detection of coupling faults.

3.6 Flash and EEPROM – Components 4.1Purpose of the test: Detect all single bit faults in non-volatile memory.

In all AVR microcontrollers, the application software is stored in Flash memory, while EEPROM memorycan be used for e.g., device-specific settings and constants. For the device to operate safely, these non-volatile memories must be checked for corruption.

Acceptable measures for Fault detection are periodic self-test using a single or multiple checksumsand/or single-bit data redundancy, e.g., parity check in hardware. Multiple checksums are therecommended option since this allows for one section of Flash or EEPROM to be checked at a time. Themethod is then to compute a checksum for the target memory range, followed by a comparison of theresult with a reference checksum that is stored elsewhere in non-volatile memory.

3.6.1 Note on Self-ProgrammingIt is not recommended to perform self-programming of the Flash in harsh environments as incidents suchas power failure during writing will risk corrupting Flash.

If self-programming is absolutely necessary, it is recommended to do this in a bootloader that is protectedby lock bits so accidental self-overwrites are impossible. The bootloader should, in this case, run a CRCcheck of the application section of Flash before any code in it is executed.

All tinyAVR® 1-series devices feature a bootloader section in the Flash memory.



3.7 External Communication – Component 6Purpose of the test: Verify correctness of transferred data, as well as communication sequence andtiming.

Communication with external devices is an important part of many applications. This represents apotential source of faults since communication is susceptible to noise, and either end of thecommunication line may be operating incorrectly. Consequently, steps must be taken to ensure that noiseor faulty operation in one device does not cause faulty operation in another.

Acceptable measures for detecting faults in transferred data are multi-bit data redundancy such asrepetition, CRC or Hamming codes, or protocol tests. Acceptable measures for detecting faults incommunication timing are time-slot monitoring or scheduled transmissions. Acceptable measures fordetecting faults in communication sequence are the same as those for timing but also include logicalmonitoring.

In short, a state machine based communications driver with time-outs, scheduling, and transferredundancy should be used.

3.8 Input/Output Peripheral – Component 7Purpose of the test: Verify that input/output is as expected and that signals are correctly routed.

Analog and/or digital I/O is needed in all applications and can be used to detect faulty operation in eitherthe peripherals or in the MCU itself.

The acceptable measure for Fault detection is plausibility checking, which means that the softwareverifies that it is getting the expected input and giving the desired output at any given time.



4. Class B Library for tinyAVR® 1-seriesThe purpose of the library is to simplify the design of safe and reliable applications based on the tinyAVR®

1-series microcontrollers. Further, this library has been certified to simplify the design and certificationprocesses for our customers.

The library has been developed to be flexible enough to embed the self-test modules in many differentapplications. The user is responsible to configure and use it so that the application complies with IEC60730 Class B standard.

The library code supports the AVR GCC compiler and IAR™. A number of examples have been includedin order to show how the self-diagnostic routines can be embedded in a user application.

The source code of the library has been prepared for automatic documentation generation with Doxygen(http://www.doxygen.org). This documentation complements the information provided in this document.

The source code does not rely on Atmel START code. Some of the code requires configuration ofperipherals that may be different from how they will be set to run in the application. Not all theseconfigurations will be reset after the tests are complete. In some of the tests, a function has been addedto reset any changed registers. This is not necessary to use, but it can serve as an overview of whichregisters are left altered after a test.

The test examples are compiled and tested on the ATTINY817 Xplained PRO with an OLED1 Xplainedconnected to the EXT1 header, to provide buttons and status LEDs.

4.1 Error HandlingIn order for the test modules to be as general as possible, a number of error handlers that can beconfigured by the user have been defined. Errors have been divided into critical and non-critical and havea default value for the error handlers.

Critical errors are those that cannot be handled, e.g., when the register that should return the result of theregister self-diagnostic routine has a stuck bit. Critical errors hang the CPU by default, leaving itexecuting an infinite loop. This should lead to a watchdog reset and the actions to take, after a systemreset issued by the watchdog timer (hereafter referred to as WDT), can be configured as well.

Non-critical errors are those that, even if they prevent the application from working correctly, still can behandled by the program. E.g., if the analog test fails, the program could still take some actions to put thesystem in a safe state. Non-critical errors set a global error flag by default. This flag is calledclassb_error and it can be used by the main application to put the system in a safe state. This is theapproach followed in the examples.

In all the tests the classb_error flag is zero when there is no error and non-zero when an error hasbeen found. The error flag is assigned the NO_INIT attribute, which prevents the memory it uses inSRAM to be overwritten with a default value at start-up. As long as the device does not lose power thevalue will be maintained.

The classb_error flag is in this library written to 1 when an error is found. This can be changed so thatthe error variable also contains information on what error has been found. The logic for doing so has notbeen implemented in the included tests as most error handling will be application dependent.

AN2632Class B Library for ...


http://www.doxygen.org

4.2 Source FilesThe source files are available through www.microchip.com.

The projects contain the following files:

• Common files:– oled1_xpro_attiny817.h - Defines, and code to configure buttons and LEDs for the examples.– classb_error_handler.h - Error handler variable and error handler functions.– classb_compiler.h - Code to make Class B library work in both IAR and GCC.

• Analog test:– classb_analog.h - Test of ADC, DAC, and Vref.– main_analog.c - Example code for the analog tests.

• CRC test:– main_crc.c - Demo application for the CRC tests.– classb_crc.h - Defines for CRC test.– classb_crc_hw.h - Simple interface for the HW CRCSCAN module.– CRC_16bit_alg.h - Code for algorithm-based 16-bit CRC scan.– CRC_16bit_lookup.h - Code for 16-bit CRC scan performed by using a lookup-table.– CRC_32bit_alg.h - Code for algorithm-based 32-bit CRC scan.– CRC_32bit_lookup.h - Code for 32-bit CRC scan performed by using a lookup-table.

• Frequency test:– classb_freq.h - Code for frequency test.– classb_rtc - RTC config code– main_frequency.c - Example code.

• Interrupt monitor:– classb_interrupt_monitor.h. Code for interrupt monitor test.– main_interrupts.c - Example code.

• Register test:– classb_cpu.h - Macros used for register test.– classb_cpu_gcc.c - Test code used when compiled by GCC.– classb_cpu_gcc_asm.s - Assembly code for GCC register tests.– classb_cpu_iar.c - Test code used when compiled by IAR.– classb_cpu_iar_asm.s - Assembly code for IAR register tests.– main_registers.c - Example code.

• SRAM test:– classb_sram.c - MarchX test code.– classb_sram.h - Defines.– main_sram.c - Example code.

• WDT test:– classb_wdt_test.c - WDT test function.– classb_wdt_test.h - Defines and attributes used to make the test run before initialization and

before entering main.– main_wdt.c - Example code.



https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en604502

Note: Some of the *.h files contain function definitions. The reason for this is that GCC is then capableof optimizing the code more easily. This is especially the case with inline functions. When done this way itallows GCC to produce code optimization comparable to what the -flto optimization flag would give. Onedifference is that the -flto option will currently not preserve debug information. The -flto option will still givebetter code size in many cases. The -flto option combined with -Os gives size optimization that is in somecases comparable to IAR.



5. RegistersIn this self-diagnostic routine, the CPU registers are tested for stuck bits and coupling faults betweeneach of the bits inside the individual registers but not between registers. The basic algorithm works asfollows: The content of the register is pushed to stack so it will be possible to restore the register after thetest. The register is set to a known value and verified. Then the register bits are forced to change state,and the register content is verified once more.

If the content of the register is incorrect after either verification, the error flag is raised. When the test isdone the register is restored with the original value pushed to the stack. Two types of registers will betested: register file registers (R0-R31) and I/O registers. These are located in separate memory spacesand are accessed with different instructions.

The registers are tested in the following order (GCC compiler implementation):

1. Return value registers: R24, R25.2. Auxiliary registers: R31, R30.3. Stack pointer: SPL, SPH.4. Status register: SREG (except interrupt flag).5. Registers: R0 to R23 and R25 to R29.

In the first three steps tests are performed on the registers that are critical for the self-diagnostic routine:

• Return value register: Used to deliver the result of this self-test.• Auxiliary register 1, 2: Used to store the value of the registers that must be preserved.• Stack pointer: Necessary to return to the main program.• Status register: Flags used by CPU instructions.

The auxiliary registers are critical because they are required to test the stack pointer. If there is an error inthese registers, the device will by default stay executing an infinite loop. However, it is possible to call theerror handler instead.

In the last steps, the rest of the register file are tested. If there is an error, the self-diagnostic routine willcall the error handler and return the value of the test. It is, however, recommended to configure the samebehavior as with the critical registers, such that the device will hang in a loop if there is an error in anyregister. If any registers fail the test, continued code execution is in most cases not recommended.

The self-diagnostic code is written with assembler as it is simpler to do register manipulation in assemblercode.

The example application turns LED 1 ON. The main program is an infinite loop running the test multipletimes until an error is found. If an error is found the loop exit condition will be met and LED 1 will beturned OFF except if the error is in auxiliary registers.

Note: This behavior is not recommended in a real-life application. The test should be run at start-up, andif an error is found no functions should be activated. Typically, if registers fail the WDT will reset thedevice as it is unlikely that the device will reset the WDT.

In order to simulate an error, breakpoints can be set in the self-diagnostic routine. After the applicationstops at a breakpoint, the content of a register can be modified to simulate a stuck bit. The execution canthen be resumed, and the self-diagnostic routine will detect the error.

AN2632Registers


Depending on the register that is modified, the CPU enters straight into an endless loop inside the self-diagnostic routine or the global error variable is set to one, which leads to switching the LED OFF andthen entering an endless loop.

AN2632Registers


6. Program CounterThe program counter is tested using the watchdog timer (WDT) for indirect time-slot monitoring of theapplication.

The WDT is a system function for monitoring correct program operation that allows recovering from errorsituations such as runaway or deadlocked code. The WDT is a timer clocked independently from theCPU. It is configured to a predefined timeout period and is constantly running when enabled.

If the WDT is not reset within the timeout period, it will issue a microcontroller reset. Resetting the WDT isdone by executing the WDT reset instruction from the application code. In addition, the WDT in thetinyAVR® 1-series has a window mode. This makes it possible to define a time slot or window inside thetotal timeout period during which the WDT must be reset. If the WDT is reset outside this window, eithertoo early (window is closed) or too late, a system reset will be issued. Compared to the normal mode, thiscan also catch situations where an error causes constant execution of the WDT reset instruction.Therefore, it is required that the Class B software uses this windowed mode and that the closed period isat least 50% of the total period.

The WDT will run in active mode and all sleep modes if enabled. It is asynchronous, running from a CPU-independent clock source, and it will continue to operate and issue a system reset even if the main clocksfail.

There is a configuration change protection mechanism in the tinyAVR® 1-series that ensures that WDTsettings cannot be changed by accident.

Note: It is possible to use the same 32 kHz clock for the WDT and the main clock. If this is done, theWDT no longer satisfy CLASS B requirements for time slot monitoring or frequency monitoring.

Since the WDT is an integral safety feature in the tinyAVR® 1-series, a self-diagnostic routine that teststhis module in normal and window mode, has been designed. This is executed after reset in the pre-initsection of the application, before the main function. A flow diagram of the test is shown in Figure 6-1.

AN2632Program Counter


Figure 6-1. Watchdog Test

WDT Tes t

Reset cause? USER CONFIGURABLE

Brownout or Software

Power on, Externa l or PDI.

Can WDT is sue

sys tem rese t?

Reset by WDT WDT Tes t Finished

Error

Se t Sta te WDT_FAILURE

WDT_2 WDT_1

Other

WDT

WDT_OK

Yes

No

USER CONFIGURABLE

Se tup WDT

Se t Sta te WDT_OK

WDT working correctly in

window mode?

Yes

No

Se t Sta te WDT_3

Tes t Sta te? WDT_3

Can WDT be rese t?

Se t Sta te WDT_2

Yes

No

Se t Sta te WDT_1

The self-diagnostic routine verifies that:

• System reset is issued after WDT timeout.



• WDT can be reset.• The device is reset upon untimely WDT reset in window mode.

The flow diagram shows that the device is reset a number of times during the WDT test. An SRAMvariable and the reset flags of the device are used by the self-diagnostic routine to keep track of the testphase. The user can configure what to do in the event of brown-out or software reset, or how to process areset caused by the watchdog when the test is in the 'WDT_OK' state.

The self-diagnostic routine uses Timer Counter A (TCA) in order to check the timing of the WDT oscillator.TCA has a clock source independent of the WDT clock. TCA is used to estimate the period of the WDTand the program checks that this estimate is within the interval (T/2, T3/2), where T is the nominal periodof the WDT. The TCA is clocked from the system clock. The system clock is typically the internal 20 MHzclock. This clock is more stable over temperature and voltage drift than the clock used by the WDT.

Note: TCA is implicitly tested by this self-diagnostic routine; if the difference in frequency between TCAand WDT is more than 50%, the error state is set.

The expected (error-free) execution flow is as follows:

1. After power-on or external reset, check that WDT can issue a system reset: Set test state to'WDT_1' and let the system be reset by a WDT timeout.

2. Check that WDT can be reset: Set the test state to 'WDT_2' and reset the WDT before it times out.3. Check that window mode works correctly: Change the WDT to window mode. First, wait for the

window to be open and reset the WDT before timeout. Then, change the state to 'WDT_3' andissue a reset when the window is closed. This should result in a system reset.

4. Set up WDT according to application settings. Set test state to 'WDT_OK' and continue to the mainfunction.

The first step is to make sure that the WDT can issue a system reset. This is done by setting up the WDTand wait until it issues a system reset. In addition, the TCA is used to estimate the watchdog period,which is required in later phases of the test. This is done by configuring the TCA with a small period(approx. 1 ms) and counting the number of TCA-periods until a system reset. If the program is left waitingfor the system reset for longer than a configurable maximum timeout period, the error state is set.

The second step is to make sure that the WDT can be reset, and to check the timing of the WDT. Theerror state is set. The test state will be in the error state until this step of the test is done. A check isperformed to see that the estimated WDT period is higher than a minimum. Checking that the differencein frequency between the WDT and TCA is within an interval provides confidence that both modules areworking as expected. Next, the WDT is set up and TCA is set to wait for approximately ¾ of the WDTperiod. This checks that the WDT does not expire earlier than expected. Then the WDT is reset and theprogram, once again, waits ¾ of the period to issue a new WDT reset. The reason for this is that if therewas any problem in the mechanism that resets the WDT, there would be a system reset while theprogram is waiting for the second time. An early system reset would leave the test in the error state. Afterthe WDT reset is verified the test state is the set to 'WDT_2' and the program waits for the WDT to issuea system reset. An error is issued if TCA is left continuing too long.

The third step checks that the WDT works correctly in window mode. This consists of configuring theWDT in window mode, the test state is set to 'WDT_3', and then an early reset of the WDT is performed.When the window is closed the WDT should issue a system reset. If a system reset does not occur, theerror state is set. After this step, a check is performed to see that the WDT reset works when the WDTwindow is open.



In the fourth and final step, the program simply sets up the WDT in window mode and sets the 'WDT_OK'state. Note that after this the main application is responsible for resetting the WDT according to theconfigured settings.

If the test sets the error state, a user-configurable error handler can be called. By default, the device willstay executing an infinite loop. This is considered to be the safest option as a working WDT is crucial fora reliable software application.

The counter and the test state variables are declared so that the compiler does not initialize them afterreset. This way they can be used across resets. The tinyAVR® 1-series has a register that stores the resetcause, which is used to decide whether it is the first iteration of the test.

The demo application sets up an interrupt for a button, switches an LED ON, and stays in a loop wherethe WDT is reset as long as the variable classb_error is not set. If this variable is set, then the LED isturned OFF and the application ends.

When the button is pressed, the program stops resetting the WDT, which leads to a WDT timeout and,therefore, a system reset. This 'unexpected' system reset should be caught by the self-diagnostic routine,which in this demo is configured to set the variable classb_error, set up the WDT, and continue to themain application. After pressing the button, the LED will be switched OFF and the application will not beresponsive until a power-on reset, or external reset.

6.1 How the Self-Diagnostic Routine Can Be TestedThe first step of the self-diagnostic routine will set the error state unless there is a system reset. Aproblem in the WDT that prevents it from being able to issue system resets could be replicated simply bynot starting the WDT. The error state would be set and the device would hang.

Frequency failure of the oscillator for the WDT or the Timer/Counter could be simulated by setting abreakpoint and modifying the value of the tc_count variable so that it is outside the interval ofconfidence.

Failure in the WDT reset mechanism could be simulated by removing the line of code where the WDT isreset. Given the structure of the program, the second step in the self-diagnostic routine will set the errorstate unless the WDT follows the time constraints that are imposed.

Failure in the WDT window mode could be simulated by removing the setup of that mode. The codewould then reset the WDT and wait for ¼ of the WDT period. At that point, the WDT period would begreater or equal to the estimated WDT period (the total timeout period is the sum of the open and closedperiods). The device will not be reset before setting the error state.

The configured actions for a system reset issued by the WDT can be tested through the demoapplication. Pressing the button will lead to the WDT expiring. Then the self-diagnostic routine wouldexecute the configured actions, which in this case is to set up the WDT, and set the variableclassb_error, and turn the LED OFF.



7. Interrupt HandlingAn interrupt signals a change of state in peripherals and can be used to alter program execution.Embedded applications use interrupts, e.g. to respond to events in real-time. It is, therefore, importantthat a system can detect errors in the interrupt functionality. Specifically, Class B applications should beable to detect whether an interrupt is not being executed as often as expected (or not at all).

The chosen method is time-slot monitoring with the Real-Time Counter (RTC, clock independent from theCPU clock). In short, any interrupt to be monitored has to increase a counter every time it is executed.The RTC generates an interrupt periodically where the interrupt counters are checked. If any counter isoutside an interrupt-specific configurable range, the error handler is called.

The interrupt monitor checks the frequency of those interrupts that are both registered and activated.Registering an interrupt means to give the interrupt monitor the following information on the interrupt tocheck: identifier, expected frequency, and deviation tolerance. The interrupt monitor creates a datastructure with this information. Activating an interrupt means to tell the monitor that it should startchecking a registered interrupt to be monitored: The interrupt monitor can be turned ON and OFF forindividual interrupts using a state variable for each registered interrupt. The possible transitions betweenstates are shown in Figure 7-1.Figure 7-1. Interrupt States

DISABLE

OFFOFF ON

ENABLE

The default state, for any interrupt, is OFF and in this state, the interrupt manager does not check thefrequency of the interrupt. The state of the interrupt should be set to ENABLE when the main applicationwants the monitor to start checking the interrupt frequency. The next time the interrupt monitor isexecuted, it will then change the interrupt state to ON. This ensures that the interrupt counter issynchronized with the interrupt monitor. The interrupt counter starts being increased exactly after a singleperiod of the interrupt monitor. Similarly, if the main application decides that an interrupt should not bemonitored anymore, the interrupt state should be set to DISABLE. The interrupt monitor will change thestate to OFF the next time it is executed.Note: There should only be one enable/disable request per RTC period.

The implemented interrupt monitor has two features that further increase the robustness of the mainapplication. The first one is an interrupt counter that increases only if the interrupt is ON, and thereforethe counter should be zero while an interrupt is OFF. This is checked by the interrupt counter for allregistered interrupts. Otherwise, the error handler is called. The second feature is that enabling aninterrupt that is ON or disabling an interrupt that is OFF will call the error handler if the constantCLASSB_STRICT is defined.

The RTC calls the interrupt monitor function periodically. All registered interrupts are processed accordingto their state. Active interrupts are checked for their frequency. If there is no error, the interrupt monitor

AN2632Interrupt Handling


resets the counter. If an error is found the error handler is called and the monitor ends immediately (this isconfigurable). The counter of inactive interrupts is compared to zero for coherence. If the main applicationhas requested to activate an interrupt, its state is set to ON and vice versa. Note that when the state isOFF the interrupt counter is set to zero.

In order to monitor an interrupt the following steps should be followed:

1. The interrupt should be declared in classb_int_identifiers by providing an identifier to theinterrupt.

2. The main application has to register the interrupt by calling classb_intmon_reg_int(). Astructure is then created for the interrupt.

3. The RTC has to be set up to generate an interrupt periodically and to call back the interruptmonitor.

4. The interrupts that have to be monitored should call classb_intmon_increase() on eachexecution.

5. The main application has to request that the monitor starts checking the interrupt. This is done bychanging the interrupt state to ENABLE with classb_intmon_set_state().

6. If at some point an interrupt should not be monitored anymore, the main application can change thestate to DISABLE.

In the example application, a Timer/Counter (TC) is set up to generate an overflow interrupt periodically,which is checked by the monitor. In addition, the application sets up two button interrupts. The first onechanges the frequency of the TC interrupt. The second one deactivates the interrupt in the monitor. AnLED is switched ON to show that the application is working correctly. The application stays in a loop withthe LED ON as long as the buttons are not pressed. If the first button is pressed, the frequency of the TCinterrupt will change, and the monitor should set the error flag. The main application will then leave theloop and switch the LED OFF. The second button can be pressed in order to deactivate the TC interruptin the monitor. In this case, pressing the first button still leads to a change in the frequency of the interruptbut the monitor will not generate an error.

The interrupt monitor relies on a working RTC. The RTC also supports the CPU frequency tests and it ischecked in the related software modules. It can, therefore, be assumed that there is no failure in the RTC.In order to increase the reliability of the application, registered interrupts could have a maximum value ofthe counter, which could be tested within the interrupt. If the counter reaches this value, it can then beassumed that the interrupt monitor is not working.

The monitor can be tested in different ways.

• An interrupt could be set up and then its frequency could be modified in order to generate an error.This is implemented in the example application.

• The counter of an interrupt could be modified while debugging. This could be done both for activeand inactive interrupts.

• If the symbol CLASSB_STRICT is defined, the program could activate or deactivate an interrupttwice, which should lead to an error.

AN2632Interrupt Handling


8. System ClockThe self-diagnostic routine has been implemented using the Real-Time Counter (RTC) and a Timer/Counter (TC). A TC has been chosen because this peripheral has the same clock domain as the CPU.The RTC can, however, be clocked from an independent clock source. E.g., the CPU could be clockedfrom the internal 20 MHz oscillator and the RTC from the internal 32 kHz oscillator.

The RTC is set up to generate an interrupt periodically. In this interrupt, a software 16-bit TC overflowcounter is compared to its expected value, and if it is within a given configurable range, the counter valueis cleared. Otherwise, the error handler will be called.

In the TC overflow interrupt the 16-bit overflow counter variable is increased. The reason for using asoftware counter value is that the TC will in most cases run at a much higher frequency than the RTC.The TC will overflow much quicker than the RTC. The error handler is called if the overflow counter ishigher than a configurable threshold. Given that the overflow counter is cleared in the RTC interrupt, anoverflow count higher than the threshold would mean that there is a mismatch between the frequency ofthe RTC compared to the frequency of the TC.

The self-test module will detect a failure in either the system clock, the internal 32 kHz oscillator, the RTC,or the TC. The risk of an undetected error is reduced to a scenario in which failures in both the RTC andthe TC clocks give a correct ratio of their frequencies.

The example application is similar to previous examples. By default, the tinyAVR 1-series of devices runfrom an internal 20 MHz oscillator prescaled down to 3.3 MHz, which is the system frequency that isconsidered when setting up the parameters of the self-diagnostic routine. The TC period is changed if thebutton is pressed. This will make the test fail, and the LED will be turned OFF.

The RTC frequency and the RTC interrupt period can be configured in the files related to the RTC. Notethat different RTC setups will be compatible with the self-diagnostic routine as long as the clock source isindependent of the CPU-clock and the constant RTC_INTERUP_PERIOD_TIME is defined according tothe RTC settings. It is also possible to configure the TC module, the prescaler, the tolerance for the test(in percent), and the system frequency. The latter has to correspond to the actual system frequency setby the main application. The self-diagnostic routine will not change the clock system according to thatsetting.

There are a number of methods to test this self-diagnostic routine.

• The example application could change the system frequency after pushing the button.• The system frequency constant F_CPU could be modified so that it does not match the real system

frequency. This can be combined with modification of the tolerance value.• In order to simulate problems in the RTC or the TC, the setup functions could be commented out.

AN2632System Clock


9. MemoryThis chapter describes the standard requirements for memories and the self-diagnostic tests that havebeen implemented. Section 9.1 Invariable Memory refers to invariable memories; internal Flash andEEPROM in the tinyAVR® 1-series. Section 9.2 Variable Memory refers to variable memory, i.e. SRAM.

9.1 Invariable MemoryA cyclic redundancy check (CRC) has been implemented to test the invariable memory. This is an errordetection technique used to find accidental errors in data. This method is commonly used to determinethe correctness of data transmissions and data present in data and program memories.

The CRC algorithm processes an input data stream or block of data and generates an output checksum,which can be used to detect errors later. Two common methods to do this consist of the following:

• Compute a checksum of the data and store it. In order to detect errors, a new checksum iscomputed on the same data and compared with the previous one. If they are different, there is anerror.

• Compute a checksum of the data and append it to the data section. The checksum computed of thedata plus the included CRC checksum should result in a constant CRC value. If the new checksumis not the correct value, the data has changed, and there is an error.

An n-bit CRC applied to a data block of arbitrary length will typically detect any single error burst notlonger than n bits and will detect the fraction 1/(1-2-n) of all longer error bursts. If there is an error in thedata, the application should take some corrective action.

Self-diagnostic modules based on hardware and software are available. Two commonly used CRCstandards are supported:

• 16-bit CRC CCITT• 32-bit CRC IEEE® 802.3

The software implementation can be used by all tinyAVR® 1-series devices. In this case, the CPU readsthe data and computes the CRC checksum. It is possible to choose between two softwareimplementations:

• Lookup table: This uses a CRC lookup table to speed up the computations. The lookup tablerequires 512 (for 16-bit) or 1024 (for 32-bit) bytes of Flash memory.

• Direct computation: This calculates the checksum for each byte using a polynomial division. Thisversion occupies no space in the Flash memory but is slower than the lookup table method.

In the software implementations, the 32-bit CRC polynomial used is 0xEDB88320, the initial remainder is0xFFFFFFFF, and the generated checksum is bit-reversed and complemented. The CCITT 16-bit CRCpolynomial used is 0x1021, with 0x0000 as initial remainder. In this case, the checksum is neither bitreversed nor complemented.

The hardware implementation in the tinyAVR® 1-series can only check the content of Flash, not theEEPROM or SRAM. The CRC computed is 16 bits wide, and the CRC mechanism relies on the CRCchecksum to be present at the last part of Flash being checked. Failure can either be signaled through anISR, or a status flag needs to be checked after the CRC is complete. The CRC module has full access toFlash, and the CPU does not run at the same time. The CRC can also be made to run before the CPU isstarted at start-up through a fuse setting, it is recommended to do so.

AN2632Memory


The CRC scan time depends on how much Flash is scanned and the main clock frequency. The scan willprocess 16 bits of data in three main clock cycles. In addition, there is a small overhead for starting andstopping roughly 20 main clock cycles. If testing Flash during the operation of the application is needed ithas to be done when the application can handle the microcontroller not responding for however long theFlash takes to scan.

The following functions are available to compute checksums for data stored in the EEPROM:• CLASSB_CRC16_EEPROM_SW• CLASSB_CRC32_EEPROM_SW

To compute CRC of Flash content the HW module is used. The driver for this can be found inclassb_crc_hw.h.

Note: The hardware and software implementations have been configured, so that equivalent CRCalgorithms produce the same checksum. There are, however, significant differences in processing time.

The example application uses the CRCSCAN module on the device to check the integrity of Flash. TheCPU does not run while the test is being performed. A button is configured so that when pressed it writesto a page in Flash. When this is done the CRC scan will fail, and the activated non-maskable interrupt(NMI) will execute and turn OFF an LED.Note: The NMI cannot be deactivated. Once an error is found, it will stay active constantly, and the codeof the ISR will be reentered right after the ISR is exited until the WDT triggers and resets the device.

Note: In order for the CRC not to fail the CRC checksum needs to be calculated and appended to Flash.This can be accomplished by adding a post-build command in Studio. This command and how to add itcan be found in AN2521 'CRCSCAN on Devices in the tinyAVR® 1-Series'.

Pressing the button once more will have no effect. In order to check that all equivalent CRC computationslead to the same checksum, it is possible to call them and compare the results. Note that the algorithm forthe software implementation (lookup or direct computation) is chosen by a setting in the correspondingheader file and only one algorithm can be called during one execution. Since choosing one algorithm orthe other will modify the content in Flash, the checksums across different executions for EEPROM shouldbe compared instead.

9.2 Variable MemoryA March algorithm has been selected for testing the variable memory. The specific March algorithmimplemented is known as March X test, which can be described as follows:

⇕(w0);⇑(r0,,w1);⇓(r1,w0);⇕(r0)The first phase is to write a 0 to all memory locations, in any order. The second phase consists of threeoperations that are performed on each bit, starting with the lowest address:

• Read a bit and verify that it is 0. If it is 1, a Fault has occurred.• Write 1 to its location• Repeat for the next bit

The third phase also consists of three operations that are done in the opposite order of addresses (withrespect to the second phase):

• Read a bit and verify that it is 1. If it is 0, a Fault has occurred.• Write 0 to its location• Repeat for the next bit

AN2632Memory


http://www.microchip.com/wwwappnotes/appnotes.aspx?appnote=en599876

The fourth and final phase consists of verifying that all bits are 0, in any order. Note that the actualaddress order used in phases two and three does not matter as long as they are done in the exactreverse order. This test is equivalent to the more common March C test where steps 3 and 4 are skipped.

March X can detect the following faults:

• Address decoder faults• Single cell faults: stuck-at, transition, or data retention faults• Faults between memory cells: Some, but not all, possible coupling faults (CFs).

Note: Detecting all possible coupling faults is very hard to do in a timely fashion. There are severalreasons for this, one of them comes from the partitioning of SRAM. As the test needs to operate onpartitions of the SRAM, the test will not have access to check if there are some CFs between partitions.Even if partitions do overlap, this is still no guarantee. It just reduces the risk of CFs going undetected.

The March test that has been described is defined for bit-oriented memories (BOMs). The SRAM in AVRsis a word-oriented memory (WOM). Replacing r0, r1, w0, and w1 by, respectively, rD, rD, wD, and wD,where D can be any data background, the BOM March test is converted to WOM March test that coversinter-word CFs. In our implementation, the data background D=0x00 has been chosen.

It is important to consider the physical location of bits in a row of the memory cell array. The proposedself-diagnostic routine can be configured to append an additional March element with the backgroundsequence {0x55, 0xAA, 0x33, 0xCC, 0x0F, 0xF0}. This will add coverage for the intra-word state CFsconsidered in the unrestricted intra-word CFs model.

In order to make it possible to run the test even with application data in SRAM, the memory is divided intoa configurable number of sections that are tested in turn. The simplest behavior of the test is when thereis no overlap between memory sections. In this case, all sections have the same size, except possibly thelast one. The first memory section (referred to as the buffer) is reserved. It is used by the test to store thecontent of the other sections while they are being tested. This is necessary given that the implementedMarch test is destructive.

Given that the March X algorithm is run on one memory section at a time, there is a user-configurableoverlap between memory sections that will decrease the probability that inter-word CFs is undetected.Every time a memory section is tested, a part of the previous section is tested as well. Note that this doesnot apply to the buffer since it is the first section. The size of the buffer needs to be expanded withrespect to the previous case (the size of the second section is decreased correspondingly).

An example application, that shows how the memory test can be embedded in an application is included.An LED that signals correct behavior of the system is ON, and then the program stays in a loop where theSRAM memory is tested as long as there are no errors.

The self-diagnostic routine can be tested as follows:

• Set a number of breakpoints in the function that implement the March X algorithm• Modify the content of some memory locations to model different types of inter-word coupling faults

The test module will then set the error flag, which leads to the application exiting the main loop and theLED is switched OFF.

9.3 Further CoverageConsidering that SRAM, Flash, and EEPROM are internal memories in the tinyAVR® 1-series, thepreviously described self-diagnostic routines cover the specifications of the standard for memoryaddressing and internal data path (subcomponent 4.3 and component 5 in Table H.11.12.7).

AN2632Memory


10. Analog I/OThe analog tests available in the library are performed on internal signals only. Two different test functionsare available in the library:

1. ADC reading of a level generated by the DAC routed internally on the device. The referencevoltage for each peripheral is generated from the bandgap voltage.

2. Similar to above, but with VDD as ADC reference voltage.

All tests are not required to run in order to be class B compliant.

Test one and two are very similar, but if the device is running with a stable VDD, test two will givesomewhat more coverage as this has a somewhat larger chance of finding deviations in the bandgapvoltage. Since test two requires a higher degree of accuracy on VDD, it should not be used for batteryapplications or applications where VDD is likely to be very noisy during testing. If VDD is noisy, or there ismuch variation from one circuit to another, it may also be necessary to have a higher acceptable range ofconversion values from the ADC.

Test one is somewhat simpler than test two and three. As both the DAC and the ADC get the referencefrom the bandgap voltage, it cannot detect if the bandgap is wrong. It can detect if the two separatereference generators sourced by the bandgap are different or wrong.

All tests will test the DAC, ADC, and reference voltage system, however, if the test fails it cannot tellwhich of these have failed. If e.g., the test is used to validate correct ADC behavior in case this is the onlycomponent being used an error present in the DAC or the reference generator to the DAC can cause thetests to fail. This could then lead to the application not being executed even when this would be safe.

The example code executes test 1 and 2 in a continuous loop, with two LEDs respectfully indicating teststatus. If a test fails, it will turn the corresponding LED OFF.

The test routine can be verified in different ways:• The ADC clock can be changed to be faster• The acceptable conversion range can be adjusted so that the test fails• The reference voltage to either the DAC or the ADC can be changed

In the example, BUTTON1 interrupt changes the reference voltage to the ADC to 1.1V (test1), whileBUTTON2 changes both ADC and DAC references to 1.1V (test2). This will cause the ADC conversionresult to be outside the expected limits, and the test should fail.

AN2632Analog I/O


11. Additional Safety Features in the tinyAVR 1-SeriesThe tinyAVR® 1-series has some additional features that can be used for increased safety, but do notdirectly address any of the Class B requirements:

• Configuration Change Protection (CCP) prevents changes of certain I/O registers and writing/reading to non-volatile memory if a timed code sequence is not followed.

• Fuses can easily be read and verified by the application software.• Brown-Out Detection (BOD), programmable Voltage Level Monitor (VLM) with Interrupt and Power-

On Reset (POR) to keep the device from operating below safe voltages.• The internal temperature sensor can be used to detect operating conditions beyond the device

speck.• The clock system checks for oscillator stability before switching clock sources.

AN2632Additional Safety Features in the tinyAVR 1-Seri...


12. Appendix - Terms and Abbreviations• Hamming Distance - For binary numbers, it can be expressed as the number of ones in the result of

A XOR B.• Static Memory Testing - Test of nonvolatile memory.• Time-slot monitoring - Some continuous test of events happening within a set time period.• March algorithms - Algorithms that goes sequentially over RAM writing and later verifying content in

RAM in multiple stages.• Coupling faults (CFs) - A connection between different memory units causing both to change when

only one should.

AN2632Appendix - Terms and Abbreviations


13. AcknowledgementsIn this document “IEC 60730 standard” and all other definitions and sections from this standard refer to:IEC 60730-1 ed.3.2, copyright© 2007 IEC Geneva, Switzerland, www.iec.ch.

The author thanks the International Electrotechnical Commission (IEC) for permission to reproduceinformation from its International Publication IEC 60730-1 ed.3.2 (2007).

All such extracts are copyright of IEC, Geneva, Switzerland. All rights reserved. Further information onthe IEC is available from www.iec.ch.

IEC has no responsibility for the placement and context in which the extracts and contents arereproduced by the author, nor is IEC in any way responsible for the other content or accuracy therein.

AN2632Acknowledgements


http://www.iec.chhttp://www.iec.ch

14. References and Suggested Literature• “IEC 60730-1: Automatic Electrical Controls for Household and Similar Use”, International

Electrotechnical Commission, Ed. 3.2, 2007-03.• “Essentials of Electronic Testing for Digital, Memory and Mixed-Signal VLSI” by Michael Lee

Bushnell and Vishwani D. Agrawal.• “A Designer’s Guide to Built-In Self-Test”, C. E. Stroud, Kluwer Academic Publishers, 2002.• AVR040: EMC Design Considerations.• AVR042: AVR Hardware Design Considerations.• AN2521 'CRCSCAN on Devices in the tinyAVR® 1-Series'.

AN2632References and Suggested Literature


http://www.microchip.com/wwwappnotes/appnotes.aspx?appnote=en590907http://www.microchip.com//wwwAppNotes/AppNotes.aspx?appnote=en604409http://www.microchip.com/wwwappnotes/appnotes.aspx?appnote=en599876

15. Revision HistoryDoc. Rev. Date Comment

B 10/2018 Removed links to START and added link to microchip.com. VLM isadded in chapter “Additional Safety Features in the tinyAVR 1-Series”.

A 02/2018 Initial document release

AN2632Revision History


The Microchip Web Site

Microchip provides online support via our web site at http://www.microchip.com/. This web site is used asa means to make files and information easily available to customers. Accessible by using your favoriteInternet browser, the web site contains the following information:

• Product Support – Data sheets and errata, application notes and sample programs, designresources, user’s guides and hardware support documents, latest software releases and archivedsoftware

• General Technical Support – Frequently Asked Questions (FAQ), technical support requests,online discussion groups, Microchip consultant program member listing

• Business of Microchip – Product selector and ordering guides, latest Microchip press releases,listing of seminars and events, listings of Microchip sales offices, distributors and factoryrepresentatives

Customer Change Notification Service

Microchip’s customer notification service helps keep customers current on Microchip products.Subscribers will receive e-mail notification whenever there are changes, updates, revisions or erratarelated to a specified product family or development tool of interest.

To register, access the Microchip web site at http://www.microchip.com/. Under “Support”, click on“Customer Change Notification” and follow the registration instructions.

Customer Support

Users of Microchip products can receive assistance through several channels:

• Distributor or Representative• Local Sales Office• Field Application Engineer (FAE)• Technical Support

Customers should contact their distributor, representative or Field Application Engineer (FAE) for support.Local sales offices are also available to help customers. A listing of sales offices and locations is includedin the back of this document.

Technical support is available through the web site at: http://www.microchip.com/support

Microchip Devices Code Protection Feature

Note the following details of the code protection feature on Microchip devices:

• Microchip products meet the specification contained in their particular Microchip Data Sheet.• Microchip believes that its family of products is one of the most secure families of its kind on the

market today, when used in the intended manner and under normal conditions.• There are dishonest and possibly illegal methods used to breach the code protection feature. All of

these methods, to our knowledge, require using the Microchip products in a manner outside theoperating specifications contained in Microchip’s Data Sheets. Most likely, the person doing so isengaged in theft of intellectual property.

• Microchip is willing to work with the customer who is concerned about the integrity of their code.

AN2632


http://www.microchip.com/http://www.microchip.com/http://www.microchip.com/support

• Neither Microchip nor any other semiconductor manufacturer can guarantee the security of theircode. Code protection does not mean that we are guaranteeing the product as “unbreakable.”

Code protection is constantly evolving. We at Microchip are committed to continuously improving thecode protection features of our products. Attempts to break Microchip’s code protection feature may be aviolation of the Digital Millennium Copyright Act. If such acts allow unauthorized access to your softwareor other copyrighted work, you may have a right to sue for relief under that Act.

Legal Notice

Information contained in this publication regarding device applications and the like is provided only foryour convenience and may be superseded by updates. It is your responsibility to ensure that yourapplication meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS ORWARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORYOR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITSCONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE.Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in lifesupport and/or safety applications is entirely at the buyer’s risk, and the buyer agrees to defend,indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resultingfrom such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectualproperty rights unless otherwise stated.

Trademarks

The Microchip name and logo, the Microchip logo, AnyRate, AVR, AVR logo, AVR Freaks, BitCloud,chipKIT, chipKIT logo, CryptoMemory, CryptoRF, dsPIC, FlashFlex, flexPWR, Heldo, JukeBlox, KeeLoq,Kleer, LANCheck, LINK MD, maXStylus, maXTouch, MediaLB, megaAVR, MOST, MOST logo, MPLAB,OptoLyzer, PIC, picoPower, PICSTART, PIC32 logo, Prochip Designer, QTouch, SAM-BA, SpyNIC, SST,SST Logo, SuperFlash, tinyAVR, UNI/O, and XMEGA are registered trademarks of Microchip TechnologyIncorporated in the U.S.A. and other countries.

ClockWorks, The Embedded Control Solutions Company, EtherSynch, Hyper Speed Control, HyperLightLoad, IntelliMOS, mTouch, Precision Edge, and Quiet-Wire are registered trademarks of MicrochipTechnology Incorporated in the U.S.A.

Adjacent Key Suppression, AKS, Analog-for-the-Digital Age, Any Capacitor, AnyIn, AnyOut, BodyCom,CodeGuard, CryptoAuthentication, CryptoAutomotive, CryptoCompanion, CryptoController, dsPICDEM,dsPICDEM.net, Dynamic Average Matching, DAM, ECAN, EtherGREEN, In-Circuit Serial Programming,ICSP, INICnet, Inter-Chip Connectivity, JitterBlocker, KleerNet, KleerNet logo, memBrain, Mindi, MiWi,motorBench, MPASM, MPF, MPLAB Certified logo, MPLIB, MPLINK, MultiTRAK, NetDetach, OmniscientCode Generation, PICDEM, PICDEM.net, PICkit, PICtail, PowerSmart, PureSilicon, QMatrix, REAL ICE,Ripple Blocker, SAM-ICE, Serial Quad I/O, SMART-I.S., SQI, SuperSwitcher, SuperSwitcher II, TotalEndurance, TSHARC, USBCheck, VariSense, ViewSpan, WiperLock, Wireless DNA, and ZENA aretrademarks of Microchip Technology Incorporated in the U.S.A. and other countries.

SQTP is a service mark of Microchip Technology Incorporated in the U.S.A.

Silicon Storage Technology is a registered trademark of Microchip Technology Inc. in other countries.

GestIC is a registered trademark of Microchip Technology Germany II GmbH & Co. KG, a subsidiary ofMicrochip Technology Inc., in other countries.

All other trademarks mentioned herein are property of their respective companies.

AN2632


© 2018, Microchip Technology Incorporated, Printed in the U.S.A., All Rights Reserved.

ISBN: 978-1-5224-3734-5

Quality Management System Certified by DNV

ISO/TS 16949Microchip received ISO/TS-16949:2009 certification for its worldwide headquarters, design and waferfabrication facilities in Chandler and Tempe, Arizona; Gresham, Oregon and design centers in Californiaand India. The Company’s quality system processes and procedures are for its PIC® MCUs and dsPIC®

DSCs, KEELOQ® code hopping devices, Serial EEPROMs, microperipherals, nonvolatile memory andanalog products. In addition, Microchip’s quality system for the design and manufacture of developmentsystems is ISO 9001:2000 certified.

AN2632


AMERICAS ASIA/PACIFIC ASIA/PACIFIC EUROPECorporate Office2355 West Chandler Blvd.Chandler, AZ 85224-6199Tel: 480-792-7200Fax: 480-792-7277Technical Support:http://www.microchip.com/supportWeb Address:www.microchip.comAtlantaDuluth, GATel: 678-957-9614Fax: 678-957-1455Austin, TXTel: 512-257-3370BostonWestborough, MATel: 774-760-0087Fax: 774-760-0088ChicagoItasca, ILTel: 630-285-0071Fax: 630-285-0075DallasAddison, TXTel: 972-818-7423Fax: 972-818-2924DetroitNovi, MITel: 248-848-4000Houston, TXTel: 281-894-5983IndianapolisNoblesville, INTel: 317-773-8323Fax: 317-773-5453Tel: 317-536-2380Los AngelesMission Viejo, CATel: 949-462-9523Fax: 949-462-9608Tel: 951-273-7800Raleigh, NCTel: 919-844-7510New York, NYTel: 631-435-6000San Jose, CATel: 408-735-9110Tel: 408-436-4270Canada - TorontoTel: 905-695-1980Fax: 905-695-2078

Australia - SydneyTel: 61-2-9868-6733China - BeijingTel: 86-10-8569-7000China - ChengduTel: 86-28-8665-5511China - ChongqingTel: 86-23-8980-9588China - DongguanTel: 86-769-8702-9880China - GuangzhouTel: 86-20-8755-8029China - HangzhouTel: 86-571-8792-8115China - Hong Kong SARTel: 852-2943-5100China - NanjingTel: 86-25-8473-2460China - QingdaoTel: 86-532-8502-7355China - ShanghaiTel: 86-21-3326-8000China - ShenyangTel: 86-24-2334-2829China - ShenzhenTel: 86-755-8864-2200China - SuzhouTel: 86-186-6233-1526China - WuhanTel: 86-27-5980-5300China - XianTel: 86-29-8833-7252China - XiamenTel: 86-592-2388138China - ZhuhaiTel: 86-756-3210040

India - BangaloreTel: 91-80-3090-4444India - New DelhiTel: 91-11-4160-8631India - PuneTel: 91-20-4121-0141Japan - OsakaTel: 81-6-6152-7160Japan - TokyoTel: 81-3-6880- 3770Korea - DaeguTel: 82-53-744-4301Korea - SeoulTel: 82-2-554-7200Malaysia - Kuala LumpurTel: 60-3-7651-7906Malaysia - PenangTel: 60-4-227-8870Philippines - ManilaTel: 63-2-634-9065SingaporeTel: 65-6334-8870Taiwan - Hsin ChuTel: 886-3-577-8366Taiwan - KaohsiungTel: 886-7-213-7830Taiwan - TaipeiTel: 886-2-2508-8600Thailand - BangkokTel: 66-2-694-1351Vietnam - Ho Chi MinhTel: 84-28-5448-2100

Austria - WelsTel: 43-7242-2244-39Fax: 43-7242-2244-393Denmark - CopenhagenTel: 45-4450-2828Fax: 45-4485-2829Finland - EspooTel: 358-9-4520-820France - ParisTel: 33-1-69-53-63-20Fax: 33-1-69-30-90-79Germany - GarchingTel: 49-8931-9700Germany - HaanTel: 49-2129-3766400Germany - HeilbronnTel: 49-7131-67-3636Germany - KarlsruheTel: 49-721-625370Germany - MunichTel: 49-89-627-144-0Fax: 49-89-627-144-44Germany - RosenheimTel: 49-8031-354-560Israel - Ra’ananaTel: 972-9-744-7705Italy - MilanTel: 39-0331-742611Fax: 39-0331-466781Italy - PadovaTel: 39-049-7625286Netherlands - DrunenTel: 31-416-690399Fax: 31-416-690340Norway - TrondheimTel: 47-72884388Poland - WarsawTel: 48-22-3325737Romania - BucharestTel: 40-21-407-87-50Spain - MadridTel: 34-91-708-08-90Fax: 34-91-708-08-91Sweden - GothenbergTel: 46-31-704-60-40Sweden - StockholmTel: 46-8-5090-4654UK - WokinghamTel: 44-118-921-5800Fax: 44-118-921-5820

Worldwide Sales and Service


FeaturesDescriptionTable of Contents1. Definitions in Annex H of IEC 607301.1. Software Classes1.2. Control Structures

2. Class B Requirements3. Component Tests3.1. CPU Registers – Component 1.13.2. Program Counter – Component 1.33.3. Interrupts – Component 23.4. Clock – Component 33.5. Static RAM – Components 4.2, 4.3, and 53.6. Flash and EEPROM – Components 4.13.6.1. Note on Self-Programming

3.7. External Communication – Component 63.8. Input/Output Peripheral – Component 7

4. Class B Library for tinyAVR® 1-series4.1. Error Handling4.2. Source Files

5. Registers6. Program Counter6.1. How the Self-Diagnostic Routine Can Be Tested

7. Interrupt Handling8. System Clock9. Memory9.1. Invariable Memory9.2. Variable Memory9.3. Further Coverage

10. Analog I/O11. Additional Safety Features in the tinyAVR 1-Series12. Appendix - Terms and Abbreviations13. Acknowledgements14. References and Suggested Literature15. Revision HistoryThe Microchip Web SiteCustomer Change Notification ServiceCustomer SupportMicrochip Devices Code Protection FeatureLegal NoticeTrademarksQuality Management System Certified by DNVWorldwide Sales and Service

guide to iec 60730 class b compliance with tinyavr®...

Documents