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

DescriptionIEC 60730 is a safety standard for household appliances that address many aspects of both product design andoperation. 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 as safe to operate.

This application note is a guide to compliance with Annex H of the standard. Annex H deals with requirements forelectronic controls. A certified firmware library and usage examples for IAR Embedded Workbench® and AVR® GCCare supplied. The firmware library is designed to cover the most general parts of the standard. How the tests are run,when, and what additional tests might be needed, depends on both the application and implementation choices. Ingeneral, a Fault in any part should not cause a hazard.

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

© 2019 Microchip Technology Inc. Application Note DS00002632D-page 1

Table of Contents

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

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

1. Definitions in Annex H of IEC 60730.......................................................................................................4

1.1. Software Classes......................................................................................................................... 41.2. Control Structures........................................................................................................................ 4

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

3. Component Tests.................................................................................................................................... 6

3.1. CPU Registers – Component 1.1.................................................................................................63.2. Program Counter – Component 1.3............................................................................................. 63.3. Interrupts – Component 2.............................................................................................................63.4. Clock – Component 3...................................................................................................................63.5. Static RAM – Components 4.2, 4.3, and 5...................................................................................73.6. Flash and EEPROM – Components 4.1.......................................................................................73.7. External Communication – Component 6.....................................................................................73.8. Input/Output Peripheral – Component 7.......................................................................................8

4. Class B Library for tinyAVR® 1-series.....................................................................................................9

4.1. Error Handling.............................................................................................................................. 94.2. Source Files................................................................................................................................. 9

5. Registers............................................................................................................................................... 11

6. Program Counter...................................................................................................................................12

6.1. How the Self-Diagnostic Routine Can Be Tested.......................................................................15

7. Interrupt Handling..................................................................................................................................16

8. System Clock........................................................................................................................................ 18

9. Memory................................................................................................................................................. 19

9.1. Invariable Memory......................................................................................................................199.2. Variable Memory........................................................................................................................ 209.3. Further Coverage....................................................................................................................... 21

10. Analog I/O............................................................................................................................................. 22

11. Additional Safety Features in the tinyAVR 1-series...............................................................................23

12. Appendix - Terms and Abbreviations.................................................................................................... 24

13. Acknowledgements............................................................................................................................... 25

14. References and Suggested Literature.................................................................................................. 26

15. Revision History.................................................................................................................................... 27

The Microchip Website.................................................................................................................................28

AN2632


Product Change Notification Service............................................................................................................28

Customer Support........................................................................................................................................ 28

Microchip Devices Code Protection Feature................................................................................................ 28

Legal Notice................................................................................................................................................. 28

Trademarks.................................................................................................................................................. 29

Quality Management System....................................................................................................................... 29

Worldwide Sales and Service.......................................................................................................................30

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 software Fault, occurs

in the appliance (H.2.21.2).• Class C – Software that includes code intended to prevent hazards without the use of other protective devices

(H.2.21.3).

Software used in protective control functions are either Class B or Class C. This application note deals with Class Bcontrols, 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 to the functionalunit prior to its operation (H.2.16.5).

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

• Dual channel without comparison – A structure which contains two mutually independent functional means toexecute specified operations (H.2.16.1).

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

A single channel structure with functional test means that the system is tested at the point of manufacture only. Thisstructure can only be used if the appliance does not use any components that require periodic testing. Periodictesting is a safer option because this allows for faults to be detected during operation of the product. The time intervalbetween the tests must typically be shorter than the time it takes for a Fault in the relevant component to cause ahazard.

Dual channel without comparison is essentially a structure in which two MCUs operate independently with differenttasks and either MCU can check that the other is operating correctly. One approach is to use one MCU strictly forsupervision, rather than sharing control tasks between the two. In this case, a lower cost device can often be used asthe 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 handle the faultsspecified for the system components in Table 2-1. In addition to these tests and Fault detections, the software mustbe properly documented to pass a certification. This includes the program sequence, 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 dynamic functionalspecifications

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 is required to doplausibility checking of the input/output signals. This, in turn, depends on both the 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 Table 2-1, that arerelevant 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 listed underacceptable 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 is impossiblewith faulty registers.

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

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. The programcounter cannot be tested directly for stuck bits since any such test will rely on the program counter to functioncorrectly in the first place.

Acceptable measures for Fault detection are functional test, periodic self-test, independent time-slot monitoring, orlogical monitoring of program sequence.

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

After the watchdog has been tested, it should be enabled in window mode at all times. The closed period should beat 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 these occur at thetime they are expected and are handled accordingly.

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

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 be verified to bewithin specification.

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

AN2632Component Tests


The tinyAVR® 1-series event system allows for timer/counter captures to be triggered by an external clock signal orthe RTC (Real-Time Counter), allowing for frequency comparison between a reference clock 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 any addressingproblems.

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

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

If the entire SRAM cannot be tested in one go, the tested memory sections must have some overlap to allow fordetection 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 memory can be usedfor e.g., device-specific settings and constants. For the device to operate safely, these non-volatile memories must bechecked for corruption.

Acceptable measures for Fault detection are periodic self-test using a single or multiple checksums and/or single-bitdata redundancy, e.g., parity check in hardware. Multiple checksums are the recommended option since this allowsfor one section of Flash or EEPROM to be checked at a time. The method is then to compute a checksum for thetarget memory range, followed by a comparison of the result with a reference checksum that is stored elsewhere innon-volatile memory.

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

If self-programming is absolutely necessary, it is recommended to do this in a bootloader that is protected by lock bitsso accidental self-overwrites are impossible. The bootloader should, in this case, run a CRC check of the applicationsection 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 and timing.

Communication with external devices is an important part of many applications. This represents a potential source offaults since communication is susceptible to noise, and either end of the communication line may be operatingincorrectly. Consequently, steps must be taken to ensure that noise or faulty operation in one device does not causefaulty operation in another.

Acceptable measures for detecting faults in transferred data are multi-bit data redundancy such as repetition, CRC orHamming codes, or protocol tests. Acceptable measures for detecting faults in communication timing are time-slotmonitoring or scheduled transmissions. Acceptable measures for detecting faults in communication sequence are thesame as those for timing but also include logical monitoring.

In short, a state machine based communications driver with time-outs, scheduling, and transfer redundancy shouldbe 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 either theperipherals or in the MCU itself.

The acceptable measure for Fault detection is plausibility checking, which means that the software verifies that it isgetting 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-seriesmicrocontrollers. Further, this library has been certified to simplify the design and certification processes for ourcustomers.

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

The library code supports the AVR GCC compiler and IAR™. A number of examples have been included in order toshow 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 of peripherals thatmay be different from how they will be set to run in the application. Not all these configurations will be reset after thetests are complete. In some of the tests, a function has been added to reset any changed registers. This is notnecessary to use, but it can serve as an overview of which registers are left altered after a test.

The test examples are compiled and tested on the ATTINY817 Xplained PRO with an OLED1 Xplained connected tothe 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 be configured by theuser have been defined. Errors have been divided into critical and non-critical and have a default value for the errorhandlers.

Critical errors are those that cannot be handled, e.g., when the register that should return the result of the registerself-diagnostic routine has a stuck bit. Critical errors hang the CPU by default, leaving it executing an infinite loop.This should lead to a watchdog reset and the actions to take, after a system reset 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 be handled bythe program. E.g., if the analog test fails, the program could still take some actions to put the system in a safe state.Non-critical errors set a global error flag by default. This flag is called classb_error and it can be used by the mainapplication to put the system in a safe state. This is the approach 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 has been found.The error flag is assigned the NO_INIT attribute, which prevents the memory it uses in SRAM to be overwritten with adefault value at start-up. As long as the device does not lose power the value will be maintained.

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

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.

AN2632Class B Library for ...


http://www.doxygen.orghttp://www.doxygen.orghttps://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en604502

• 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.

Note: Some of the *.h files contain function definitions. The reason for this is that GCC is then capable of optimizingthe code more easily. This is especially the case with inline functions. When done this way it allows GCC to producecode optimization comparable to what the -flto optimization flag would give. One difference is that the -flto option willcurrently not preserve debug information. The -flto option will still give better code size in many cases. The -flto optioncombined with -Os gives size optimization that is in some cases comparable to IAR.

AN2632Class B Library for ...


5. RegistersIn this self-diagnostic routine, the CPU registers are tested for stuck bits and coupling faults between each of the bitsinside the individual registers but not between registers. The basic algorithm works as follows: The content of theregister is pushed to stack so it will be possible to restore the register after the test. The register is set to a knownvalue 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 is done theregister is restored with the original value pushed to the stack. Two types of registers will be tested: register fileregisters (R0-R31) and I/O registers. These are located in separate memory spaces and are accessed with differentinstructions.

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 in theseregisters, the device will by default stay executing an infinite loop. However, it is possible to call the error handlerinstead.

In the last steps, the rest of the register file are tested. If there is an error, the self-diagnostic routine will call the errorhandler and return the value of the test. It is, however, recommended to configure the same behavior as with thecritical registers, such that the device will hang in a loop if there is an error in any register. 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 assembler code.

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

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

In order to simulate an error, breakpoints can be set in the self-diagnostic routine. After the application stops at abreakpoint, the content of a register can be modified to simulate a stuck bit. The execution can then be resumed, andthe self-diagnostic routine will detect the error.

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

AN2632Registers


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

The WDT is a system function for monitoring correct program operation that allows recovering from error situationssuch as runaway or deadlocked code. The WDT is a timer clocked independently from the CPU. It is configured to apredefined timeout period and is constantly running when enabled.

If the WDT is not reset within the timeout period, it will issue a system reset. Resetting the WDT is done by executingthe WDT reset instruction (WDR) from the application code. In addition, the WDT in the tinyAVR® 1-series has awindow mode. This makes it possible to define a time slot or window inside the total timeout period during which theWDT must be reset. If the WDT is reset outside this window, either too early (window is closed) or too late, a systemreset will be issued. Compared to the normal mode, this can also catch situations where an error causes constantexecution of the WDT reset instruction. Therefore, it is required that the Class B software uses the window mode andthat the closed period is at 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 clocks fail.

There is a configuration change protection mechanism in the tinyAVR® 1-series that ensures that WDT settingscannot 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, the WDT no longersatisfy 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 tests this module innormal and window mode has been designed. These tests are executed after reset in the pre-init section of theapplication, before the main function. A flow diagram of the test is shown in Figure 6-1.

AN2632Program Counter


Figure 6-1. Watchdog Test

USER CONFIGURABLE

WDT Test

Reset cause?

Test State?

USER CONFIGURABLE

Brownout orSoftware

WDT_OK

Setup WDT

WDT_4Can WDT issue

system reset?

Can WDTbe reset?

WDT workingcorrectly in

Window mode?

Set State WDT_1

Set State WDT_FAILURE

Set State WDT_2

Set State WDT_3

Set State WDT_4

Set State WDT_OK

Error

System Reset by WDT

WDT Test Finished

WDT do system reset if no WDR in Window

mode?

WDT

WDT_1Yes

Power on,External or PDI

Yes

WDT_3

Yes

Yes

WDT_2

No

No

Other

No

No



The self-diagnostic routine verifies that:

• System reset is issued after WDT timeout in both normal and window mode• WDT can be reset using the WDR instruction in both normal and window mode• 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 SRAM variable and thereset flags of the device are used by the self-diagnostic routine to keep track of the test phase. The user canconfigure what to do in the event of brown-out or software reset, or how to process a reset caused by the watchdogwhen 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 aclock source independent of the WDT clock. TCA is used to estimate the period of the WDT, and the program checksthat this estimate is within the interval (T/2, T3/2), where T is the nominal period of the WDT. The TCA is clocked fromthe system clock. The system clock is typically the internal 20 MHz clock. This clock is more stable over temperatureand 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 TCA and WDT ismore 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 letthe 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' and issue a reset when thewindow is closed. This should result in a system reset.

4. Set test state to 'WDT_4' and let the system be reset by a WDT timeout while configured in window mode.5. Set up WDT according to application settings. Set test state to 'WDT_OK' and continue to the main function.

The first step is to make sure that the WDT can issue a system reset. This is done by setting up the WDT and waituntil it issues a system reset. In addition, the TCA is used to estimate the watchdog period, which is required in laterphases of the test. This is done by configuring the TCA with a small period (approx. 1 ms) and counting the numberof TCA-periods until a system reset. If the program is left waiting for the system reset for longer than the theoreticalmaximum 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. The error state isset. The test state will be in the error state until this step of the test is done. A check is performed to see that theestimated WDT period is higher or equal to the theoretical minimum. Checking that the difference in frequencybetween the WDT and TCA is within an interval provides confidence that both modules are working as expected.Next, the WDT is set up, and TCA is set to wait for approximately ¾ of the WDT period - WDT synchronization delay.This checks that the WDT does not expire earlier than expected. Then the WDT is reset and the program, onceagain, waits ¾ of the period to issue a new WDT reset. The reason for this is that if there was any problem in themechanism that resets the WDT, there would be a system reset while the program is waiting for the second time. Anearly system reset would leave the test in the error state. After the WDT reset is verified, the test state is set to'WDT_2' and the program waits for the WDT to time out and issue a system reset. An error is issued if TCA is leftcounting too long.

The third step checks that the WDT works correctly in window mode. This consists of configuring the WDT in windowmode and wait until the WDT is in the open window before issuing a WDT reset. If the WDT were in the open windowonly, the WDT will be reset and not the entire device. If the device was reset at this point, it will be detected when itstarts back up. The program continues, and the WDT is now back in the closed window after WDT reset. The teststate is set to 'WDT_3', and a reset of the WDT is performed while in the closed window. When the window is closed,the WDT should issue a system reset. If a system reset does not occur, the error state is set.

In the fourth step, the WDT is again configured in window mode and left running. If the WDT operates as expected, itwill get a timeout after passing the closed and open window and perform a system reset. If a system reset does notoccur within a reasonable time, an error state is set.

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



If the test sets the error state, a user-configurable error handler can be called. By default, the device will stayexecuting an infinite loop. This is considered to be the safest option as a working WDT is crucial for a reliablesoftware application.

The counter and the test state variables are declared so that the compiler does not initialize them after reset. Thisway, they can be used across resets. The tinyAVR® 1-series has a register that stores the reset cause, which is usedto 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 where the WDT isreset as long as the variable classb_error is not set. If this variable is set, then the LED is turned OFF, and theapplication ends.

When the button is pressed, the program stops resetting the WDT, which leads to a WDT timeout and, therefore, asystem reset. This ‘unexpected’ system reset should be caught by the self-diagnostic routine, which in this demo isconfigured to set the variable classb_error, set up the WDT, and continue to the main application. After pressingthe button, the LED will be switched OFF, and the application will not be responsive until a power-on reset, orexternal 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. A problem in theWDT that prevents it from being able to issue system resets could be replicated simply by not starting the WDT. Theerror 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 a breakpoint andmodifying the value of the tc_count variable so that it is outside the interval of confidence.Failure in the WDT reset mechanism could be simulated by removing the line of code where the WDT is reset. Giventhe structure of the program, the second step in the self-diagnostic routine will set the error state unless the WDTfollows the time constraints that are imposed.

Failure in the WDT window mode could be simulated by removing the setup of that mode. The code would then resetthe WDT and wait for ¼ of the WDT period. At that point, the WDT period would be greater or equal to the estimatedWDT period (the total timeout period is the sum of the open and closed periods). The device will not be reset beforesetting the error state.

The configured actions for a system reset issued by the WDT can be tested through the demo application. Pressingthe button will lead to the WDT expiring. Then the self-diagnostic routine would execute the configured actions, whichin this case is to set up the WDT, and set the variable classb_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. Embeddedapplications use interrupts, e.g. to respond to events in real-time. It is, therefore, important that a system can detecterrors in the interrupt functionality. Specifically, Class B applications should be able to detect whether an interrupt isnot 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 the CPUclock). In short, any interrupt to be monitored has to increase a counter every time it is executed. The RTC generatesan interrupt periodically where the interrupt counters are checked. If any counter is outside an interrupt-specificconfigurable range, the error handler is called.

The interrupt monitor checks the frequency of those interrupts that are both registered and activated. Registering aninterrupt means to give the interrupt monitor the following information on the interrupt to check: identifier, expectedfrequency, and deviation tolerance. The interrupt monitor creates a data structure with this information. Activating aninterrupt means to tell the monitor that it should start checking a registered interrupt to be monitored: The interruptmonitor can be turned ON and OFF for individual interrupts using a state variable for each registered interrupt. Thepossible transitions between states 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 the frequency ofthe interrupt. The state of the interrupt should be set to ENABLE when the main application wants the monitor to startchecking the interrupt frequency. The next time the interrupt monitor is executed, it will then change the interrupt stateto ON. This ensures that the interrupt counter is synchronized with the interrupt monitor. The interrupt counter startsbeing increased exactly after a single period of the interrupt monitor. Similarly, if the main application decides that aninterrupt should not be monitored anymore, the interrupt state should be set to DISABLE. The interrupt monitor willchange the state 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 main application. Thefirst one is an interrupt counter that increases only if the interrupt is ON, and therefore the counter should be zerowhile an interrupt is OFF. This is checked by the interrupt counter for all registered interrupts. Otherwise, the errorhandler is called. The second feature is that enabling an interrupt that is ON or disabling an interrupt that is OFF willcall the error handler if the constant CLASSB_STRICT is defined.

The RTC calls the interrupt monitor function periodically. All registered interrupts are processed according to theirstate. Active interrupts are checked for their frequency. If there is no error, the interrupt monitor resets the counter. Ifan error is found the error handler is called and the monitor ends immediately (this is configurable). The counter ofinactive interrupts is compared to zero for coherence. If the main application has requested to activate an interrupt, itsstate is set to ON and vice versa. Note that when the state is OFF 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 the interrupt.2. The main application has to register the interrupt by calling classb_intmon_reg_int(). A structure is then

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

AN2632Interrupt Handling


4. The interrupts that have to be monitored should call classb_intmon_increase() on each execution.5. The main application has to request that the monitor starts checking the interrupt. This is done by changing 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 the state to

DISABLE.

In the example application, a Timer/Counter (TC) is set up to generate an overflow interrupt periodically, which ischecked by the monitor. In addition, the application sets up two button interrupts. The first one changes the frequencyof the TC interrupt. The second one deactivates the interrupt in the monitor. An LED is switched ON to show that theapplication is working correctly. The application stays in a loop with the LED ON as long as the buttons are notpressed. If the first button is pressed, the frequency of the TC interrupt will change, and the monitor should set theerror flag. The main application will then leave the loop and switch the LED OFF. The second button can be pressedin order to deactivate the TC interrupt in the monitor. In this case, pressing the first button still leads to a change inthe frequency of the interrupt but 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 is checked inthe related software modules. It can, therefore, be assumed that there is no failure in the RTC. In order to increasethe reliability of the application, registered interrupts could have a maximum value of the counter, which could betested within the interrupt. If the counter reaches this value, it can then be assumed that the interrupt monitor is notworking.

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 isimplemented in the example application.

• The counter of an interrupt could be modified while debugging. This could be done both for active and inactiveinterrupts.

• If the symbol CLASSB_STRICT is defined, the program could activate or deactivate an interrupt twice, whichshould 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). ATC has been chosen because this peripheral has the same clock domain as the CPU. The RTC can, however, beclocked from an independent clock source. E.g., the CPU could be clocked from the internal 20 MHz oscillator andthe 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 overflow counter iscompared to its expected value, and if it is within a given configurable range, the counter value is 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 a software countervalue is that the TC will in most cases run at a much higher frequency than the RTC. The TC will overflow muchquicker than the RTC. The error handler is called if the overflow counter is higher than a configurable threshold.Given that the overflow counter is cleared in the RTC interrupt, an overflow count higher than the threshold wouldmean that there is a mismatch between the frequency of the 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 and the TC clocks give acorrect ratio of their frequencies.

The example application is similar to previous examples. By default, the tinyAVR 1-series of devices run from aninternal 20 MHz oscillator prescaled down to 3.3 MHz, which is the system frequency that is considered when settingup the parameters of the self-diagnostic routine. The TC period is changed if the button is pressed. This will make thetest 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. Note that differentRTC setups will be compatible with the self-diagnostic routine as long as the clock source is independent of the CPU-clock and the constant RTC_INTERUP_PERIOD_TIME is defined according to the RTC settings. It is also possible toconfigure the TC module, the prescaler, the tolerance for the test (in percent), and the system frequency. The latterhas to correspond to the actual system frequency set by the main application. The self-diagnostic routine will notchange the clock system according to that setting.

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 have beenimplemented. Section 9.1 Invariable Memory refers to invariable memories; internal Flash and EEPROM in thetinyAVR® 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 error detectiontechnique used to find accidental errors in data. This method is commonly used to determine the correctness of datatransmissions 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 canbe 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 is computed on thesame data and compared with the previous one. If they are different, there is an error.

• Compute a checksum of the data and append it to the data section. The checksum computed of the data plusthe included CRC checksum should result in a constant CRC value. If the new checksum is not the correctvalue, 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 not longer than nbits and will detect the fraction 1/(1-2-n) of all longer error bursts. If there is an error in the data, the application shouldtake some corrective action.

Self-diagnostic modules based on hardware and software are available. Two commonly used CRC standards aresupported:

• 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 reads the data andcomputes the CRC checksum. It is possible to choose between two software implementations:

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

• Direct computation: This calculates the checksum for each byte using a polynomial division. This versionoccupies 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 CRC polynomialused is 0x1021, with 0x0000 as initial remainder. In this case, the checksum is neither bit reversed norcomplemented.

The hardware implementation in the tinyAVR® 1-series can only check the content of Flash, not the EEPROM orSRAM. The CRC computed is 16 bits wide, and the CRC mechanism relies on the CRC checksum to be present atthe last part of Flash being checked. Failure can either be signaled through an ISR, or a status flag needs to bechecked after the CRC is complete. The CRC module has full access to Flash, and the CPU does not run at thesame time. The CRC can also be made to run before the CPU is started at start-up through a fuse setting, it isrecommended to do so.

The CRC scan time depends on how much Flash is scanned and the main clock frequency. The scan will process 16bits of data in three main clock cycles. In addition, there is a small overhead for starting and stopping roughly 20 mainclock cycles. If testing Flash during the operation of the application is needed it has to be done when the applicationcan handle the microcontroller not responding for however long the Flash 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 in classb_crc_hw.h.

AN2632Memory


Note: The hardware and software implementations have been configured, so that equivalent CRC algorithmsproduce 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. The CPU doesnot run while the test is being performed. A button is configured so that when pressed it writes to a page in Flash.When this is done the CRC scan will fail, and the activated non-maskable interrupt (NMI) will execute and turn OFFan LED.Note: The NMI cannot be deactivated. Once an error is found, it will stay active constantly, and the code of the ISRwill 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 canbe accomplished by adding a post-build command in Studio. This command and how to add it can 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 computations lead to thesame checksum, it is possible to call them and compare the results. Note that the algorithm for the softwareimplementation (lookup or direct computation) is chosen by a setting in the corresponding header file and only onealgorithm can be called during one execution. Since choosing one algorithm or the other will modify the content inFlash, the checksums across different executions for EEPROM should be compared instead.

9.2 Variable MemoryA March algorithm has been selected for testing the variable memory. The specific March algorithm implemented isknown 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 three operationsthat 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 (with respect to thesecond 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

The fourth and final phase consists of verifying that all bits are 0, in any order. Note that the actual address orderused in phases two and three does not matter as long as they are done in the exact reverse order. This test isequivalent 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 several reasons for this,one of them comes from the partitioning of SRAM. As the test needs to operate on partitions of the SRAM, the testwill not have access to check if there are some CFs between partitions. Even if partitions do overlap, this is still noguarantee. 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 AVRs is a word-oriented memory (WOM). Replacing r0, r1, w0, and w1 by, respectively, rD, rD, wD, and wD, where D can be any databackground, the BOM March test is converted to WOM March test that covers inter-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 proposed self-diagnosticroutine can be configured to append an additional March element with the background sequence {0x55, 0xAA, 0x33,

AN2632Memory


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

0xCC, 0x0F, 0xF0}. This will add coverage for the intra-word state CFs considered in the unrestricted intra-word CFsmodel.

In order to make it possible to run the test even with application data in SRAM, the memory is divided into aconfigurable number of sections that are tested in turn. The simplest behavior of the test is when there is no overlapbetween memory sections. In this case, all sections have the same size, except possibly the last one. The firstmemory section (referred to as the buffer) is reserved. It is used by the test to store the content of the other sectionswhile they are being tested. This is necessary given that the implemented March test is destructive.

Given that the March X algorithm is run on one memory section at a time, there is a user-configurable overlapbetween memory sections that will decrease the probability that inter-word CFs is undetected. Every time a memorysection is tested, a part of the previous section is tested as well. Note that this does not apply to the buffer since it isthe first section. The size of the buffer needs to be expanded with respect to the previous case (the size of thesecond section is decreased correspondingly).

An example application, that shows how the memory test can be embedded in an application is included. An LEDthat signals correct behavior of the system is ON, and then the program stays in a loop where the SRAM memory istested 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 the LED isswitched OFF.

9.3 Further CoverageConsidering that SRAM, Flash, and EEPROM are internal memories in the tinyAVR® 1-series, the previouslydescribed self-diagnostic routines cover the specifications of the standard for memory addressing and internal datapath (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 functions areavailable in the library:

1. ADC reading of a level generated by the DAC routed internally on the device. The reference voltage for eachperipheral 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 give somewhat morecoverage as this has a somewhat larger chance of finding deviations in the bandgap voltage. Since test two requiresa higher degree of accuracy on VDD, it should not be used for battery applications or applications where VDD is likelyto be very noisy during testing. If VDD is noisy, or there is much variation from one circuit to another, it may also benecessary to have a higher acceptable range of conversion values from the ADC.

Test one is somewhat simpler than test two and three. As both the DAC and the ADC get the reference from thebandgap voltage, it cannot detect if the bandgap is wrong. It can detect if the two separate reference generatorssourced 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 tell which of thesehave failed. If e.g., the test is used to validate correct ADC behavior in case this is the only component being used anerror present in the DAC or the reference generator to the DAC can cause the tests to fail. This could then lead to theapplication 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 test status. If atest 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), while BUTTON2changes both ADC and DAC references to 1.1V (test2). This will cause the ADC conversion result to be outside theexpected 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 not directlyaddress 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 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-1ed.3.2, copyright© 2007 IEC Geneva, Switzerland, www.iec.ch.

The author thanks the International Electrotechnical Commission (IEC) for permission to reproduce information fromits International Publication IEC 60730-1 ed.3.2 (2007).

All such extracts are copyright of IEC, Geneva, Switzerland. All rights reserved. Further information on the IEC isavailable from www.iec.ch.

IEC has no responsibility for the placement and context in which the extracts and contents are reproduced by theauthor, 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

D 12/2019 Removed “The internal temperature sensor can be used to detectoperating conditions beyond the device spec.” from section 11.

C 07/2019 Updated program counter topic based on customer feedback

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

A 02/2018 Initial document release

AN2632Revision History


The Microchip WebsiteMicrochip provides online support via our website at http://www.microchip.com/. This website is used to make filesand information easily available to customers. Some of the content available includes:

• Product Support – Data sheets and errata, application notes and sample programs, design resources, user’sguides and hardware support documents, latest software releases and archived software

• General Technical Support – Frequently Asked Questions (FAQs), technical support requests, onlinediscussion groups, Microchip design partner program member listing

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

Product Change Notification ServiceMicrochip’s product change notification service helps keep customers current on Microchip products. Subscribers willreceive email notification whenever there are changes, updates, revisions or errata related to a specified productfamily or development tool of interest.

To register, go to http://www.microchip.com/pcn and follow the registration instructions.

Customer SupportUsers of Microchip products can receive assistance through several channels:

• Distributor or Representative• Local Sales Office• Embedded Solutions Engineer (ESE)• Technical Support

Customers should contact their distributor, representative or ESE for support. Local sales offices are also available tohelp customers. A listing of sales offices and locations is included in this document.

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

Microchip Devices Code Protection FeatureNote 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 the operatingspecifications contained in Microchip’s Data Sheets. Most likely, the person doing so is engaged in theft ofintellectual property.

• Microchip is willing to work with the customer who is concerned about the integrity of their code.• Neither Microchip nor any other semiconductor manufacturer can guarantee the security of their code. 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 the code protectionfeatures of our products. Attempts to break Microchip’s code protection feature may be a violation of the DigitalMillennium Copyright Act. If such acts allow unauthorized access to your software or other copyrighted work, youmay have a right to sue for relief under that Act.

Legal NoticeInformation contained in this publication regarding device applications and the like is provided only for yourconvenience and may be superseded by updates. It is your responsibility to ensure that your application meets with

AN2632


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

your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHEREXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION,INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY ORFITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchipdevices in life support 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 resulting from suchuse. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights unlessotherwise stated.

TrademarksThe Microchip name and logo, the Microchip logo, Adaptec, AnyRate, AVR, AVR logo, AVR Freaks, BesTime,BitCloud, chipKIT, chipKIT logo, CryptoMemory, CryptoRF, dsPIC, FlashFlex, flexPWR, HELDO, IGLOO, JukeBlox,KeeLoq, Kleer, LANCheck, LinkMD, maXStylus, maXTouch, MediaLB, megaAVR, Microsemi, Microsemi logo, MOST,MOST logo, MPLAB, OptoLyzer, PackeTime, PIC, picoPower, PICSTART, PIC32 logo, PolarFire, Prochip Designer,QTouch, SAM-BA, SenGenuity, SpyNIC, SST, SST Logo, SuperFlash, Symmetricom, SyncServer, Tachyon,TempTrackr, TimeSource, tinyAVR, UNI/O, Vectron, and XMEGA are registered trademarks of Microchip TechnologyIncorporated in the U.S.A. and other countries.

APT, ClockWorks, The Embedded Control Solutions Company, EtherSynch, FlashTec, Hyper Speed Control,HyperLight Load, IntelliMOS, Libero, motorBench, mTouch, Powermite 3, Precision Edge, ProASIC, ProASIC Plus,ProASIC Plus logo, Quiet-Wire, SmartFusion, SyncWorld, Temux, TimeCesium, TimeHub, TimePictra, TimeProvider,Vite, WinPath, and ZL are registered trademarks of Microchip Technology Incorporated in the U.S.A.

Adjacent Key Suppression, AKS, Analog-for-the-Digital Age, Any Capacitor, AnyIn, AnyOut, BlueSky, 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, MPASM, MPF,MPLAB Certified logo, MPLIB, MPLINK, MultiTRAK, NetDetach, Omniscient Code Generation, PICDEM,PICDEM.net, PICkit, PICtail, PowerSmart, PureSilicon, QMatrix, REAL ICE, Ripple Blocker, SAM-ICE, Serial QuadI/O, SMART-I.S., SQI, SuperSwitcher, SuperSwitcher II, Total Endurance, TSHARC, USBCheck, VariSense,ViewSpan, WiperLock, Wireless DNA, and ZENA are trademarks 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.

The Adaptec logo, Frequency on Demand, Silicon Storage Technology, and Symmcom are registered trademarks ofMicrochip Technology Inc. in other countries.

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

All other trademarks mentioned herein are property of their respective companies.© 2019, Microchip Technology Incorporated, Printed in the U.S.A., All Rights Reserved.

ISBN: 978-1-5224-5270-6

Quality Management SystemFor information regarding Microchip’s Quality Management Systems, please visit http://www.microchip.com/quality.

AN2632


http://www.microchip.com/quality

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:http://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-72400Germany - 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


http://www.microchip.com/supporthttp://www.microchip.com

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 WebsiteProduct Change Notification ServiceCustomer SupportMicrochip Devices Code Protection FeatureLegal NoticeTrademarksQuality Management SystemWorldwide Sales and Service

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

Documents