Since October 2007, all new household appliances have to comply with the IEC60335 norm, which is intended to prevent any dangerous malfunction in case of a fault condition. The 4th edition of the standard has garnered attention from designers of electronic controls for home appliances, and more specifically software developers for such controls, with the introduction of software inspection and the notion of software classes. Depending on the class (A/B/C), a list of MCU components (such as CPU registers or memories) have to be tested at power on and monitored during run-time, similar to what is done in industrial or medical segments for safety critical applications, those evaluated according to SIL2/SIL3 levels, IEC61508, or UL1998 standards.

For designers of home appliances, it is important to understand how to fulfill Class B requirements and how a microcontroller manufacturer can help minimize development cost overhead and get their application certified. For example, the STMicroelectronics Cortex-M3-based STM32 32-bit MCU is considered a Class B ready device that can reduce the time and expense associated with complying with the new standard.

The standard distinguishes three software classes, depending on how dangerous a piece of equipment is in case of failure. If the safety of the appliance does not rely on software, it falls into Class A. This class would include such things as room thermostats or lighting controls. On the opposite end of the class spectrum, if the software is intended to prevent special hazards, such as an explosion in electronically-fired gas burners, it will be evaluated as Class C. However, the vast majority of household appliances whose electronic controls must prevent unsafe operation belong to the Class B category. Examples include clothes washers with electronically controlled door locks or dishwasher pump drives with motor over-temperature detection.

For the Class B checklist, the IEC60335 standard refers to another norm, the IEC60730, which covers electronic controls in general. The table H.11.12.7 in Annex H lists the microcontroller components to be tested, the faults to be detected, and the acceptable measures, for both software Class B and C. It includes the CPU (registers and program counter), interrupts (handling and execution), clock frequency monitoring, checks on variable memory (RAM) and invariable memory (Flash, EEPROM), external communications and peripherals, and a few others besides these main ones.

Enlarge this picture Fig. 1. STM32’s failsafe clock circuitry and dual watchdog system.

These tests can be carried out directly with the microcontroller internal hardware or indirectly by software means. The STM32 has built-in hardware features to monitor CPU’s program counter stuck-at faults, abnormal clock frequency, and Flash memory content integrity.

The norm proposes an “independent time-slot monitoring” to prevent any CPU run-away in case of a PC malfunction: this is the duty of the watchdog timer, which is embedded in most MCUs. Nonetheless, the norm states that it must be independent. For this reason, the STM32 has two watchdogs: a regular window watchdog running on the main clock source, and a second watchdog, using an independent internal oscillator and started with an option byte located in Flash memory. This ensures that at least one watchdog will be active in case of crystal failure and whatever the clock circuitry configuration.

Fig. 1 shows an overview of the STM32 clock circuitry, which shows the various clock sources and their connections to the rest of the chip. This diagram shows that the real-time clock can be supplied by the LSI (Low Speed Internal) RC oscillator. This provides a means to monitor the external clock by comparing the expected external frequency with an internal one, as requested for the clock component. At the system level, this saves the cost of a 50/60 Hz mains zero-crossing detection circuitry, unless this is requested by the application to fire a triac.

Finally, the STM32 embeds a 32-bit hardware CRC calculation unit, which significantly speeds-up flash content integrity check and reduces the related CPU load (spent during run-time) to a negligible value.

Enlarge this picture Fig. 2. Run-time transparent RAM test.

Most of the other tests require a non-negligible silicon area to be implemented by hardware. This is the case for single-bit fault detection in RAM, for instance, which implies an addition of a parity bit on all data words. This option was discarded because it would have impacted the cost-effectiveness of the controller, and it can easily be implemented by software. For this reason, STMicroelectronics freely provides a self-diagnostic firmware library, which contains C modules for the following tests:

• CPU registers test.
• Clock monitoring.
• RAM functional check.
• ROM checksum integrity check.
• Watchdog self-test and stack overflow monitoring. (Even if not explicitly asked by the norm, this improves overall fault coverage).

Looking at one of these modules, the RAM functional test, will help with understanding Class B software constraints. The standard asks to periodically test the RAM for DC faults, such as stuck-at or coupling faults. The March C- algorithm was chosen for its ability to detect all these faults, with a limited number of passes. However, to be efficient, it requires taking into account the physical implementation of the memory. In the STM32, there is a logical vs. physical address scrambling. The large register set of the Cortex-M3 core allows the descrambling to be included in the algorithm without using RAM memory cells (the test is destructive and must verify the whole memory array).

As an additional requirement, this test must be done periodically. If the application is systematically powered up before being used for a relatively short period, the tests done after the boot can be considered as periodic. On the other hand, if the application remains powered, the tests must be repeated during run-time also, and things become even more complicated: the RAM test must be transparent since it applies to memory cells being used by the application software. The principle of operation is presented in Fig. 2.

A different set of C functions is provided for run-time tests. They have to be executed inside the highest priority interrupt routine, and several options are provided to avoid consuming too much CPU load or deteriorate the real-time responsiveness. The algorithm can be selected, either March C- or March X, which is slightly faster for a limited loss in terms of coverage. The number of memory cells being tested at once can also be parameterized in a header file, so that the duration of the interrupt routine can be finely adjusted down to few microseconds.

Enlarge this picture Fig. 3. Control flow monitoring principle.

This example shows how beneficial such a firmware library can be, as regarding development time. Similarly, some tests must be developed in assembly (typically the CPU tests - the C language hardly allows dealing directly with the core registers and flags); the assembly optimized routines provided with the library prevents the customer from having to learn the Cortex-M3 instruction set.

Besides these individual tests, the self-diagnostic firmware also provides a reference Class B software framework when starting a new project, including workspaces for development tools, modified vector tables, and custom linker script files for handling Class A and Class B variables. Executed right after the reset vector fetch, a boot sequence implements all required tests before the application start (CPU, Watchdog, clock monitoring, RAM and FLASH tests), and can be re-used as is. Once completed, this safe boot returns to the compiler’s C start-up entry point, so that all initial tests are completely transparent from the development tool’s point of view (RAM is verified before the automatic data initialization). The program sequence itself is monitored using a counter method, to verify that all tests are executed. Fig. 3 shows the principle of operation, based on inverse redundant variable storage and landmarking with prime numbers. Unexpected counter values or non-consistent redundant values at the end of the sequence will indicate an error and will result in an MCU reset before proceeding with the MCU and peripherals initialization.

The firmware library does not include all tests listed in the table H.11.12.7. Some are relevant only for systems having external memories (Section 5 for internal data path) or ASIC/gate arrays (Section 9 for custom chips). Some others checks are application dependent: Section 6 on external communication, Section 2 on interruptions, and Section 7 on I/O periphery.

There are several things to consider for interrupts and I/Os. When it is necessary to monitor the interrupt rate and detect “no interrupt or too frequent interrupt,” one solution is to cross-check several independent time bases. For instance, in a system where there is a 10 ms heartbeat interrupt and a PWM update event every 500 microseconds, each interrupt can detect a malfunction with simple software counters. In the 10 ms ISR, one must read a PWM ISR counter between 19 and 21 (20 x 0.5 ms giving 10 ms). Conversely, after 100 PWM interrupts, one must verify that there was between 4 and 6 heartbeat ISRs (100 x 0.5 ms = 50 ms = 5 x 10 ms); any other value outside these boundaries indicates an error to be handled. This method is rather simple and easy to implement, but it must be tailored case-by-case, depending on the number of ISRs to be served and on their frequency. For this reason, it is not included in the library.

For the I/O periphery, Class B software must detect any malfunction on digital I/Os and on analog channels. This is covered by plausibility checks. For example, consider a heating element controlled with a triac and regulated with a NTC resistor connected to the A/D converter. If the temperature does not rise when the triac is switched ON, it indicates that the digital output or the triac is damaged, or that the ADC is not working properly. In any case, Class B software has to handle these error conditions and react accordingly.

The firmware library is supported by documentation and a useful RS-232 based verbose mode. It has been proof-checked in real-conditions by one of the leading European test institutes, the VDE, which approved it. The STM32 is the first 32-bit MCU having IEC60335-1 certified self-diagnostic routines. Providing that these modules are used unchanged and according to STMicroelectronics integration guidelines, they will not be re-evaluated in-depth, which eases the process and reduces the time and cost necessary to have an end-application certified.

With safety-related features and extensive Class B compliance support material, the STM32 is an ideal candidate for medium/high-end appliance platforms, where it can drastically reduce the time-to-market overhead to comply with the new standard. In addition, the STM8 8-bit microcontroller product line, which targets the household appliances market, also embeds a dual watchdog and failsafe clock circuitry, and is supported by self-test routines approved by the VDE in February 2008. These developments will help appliance designers bring new, electronically controlled appliances to market more quickly while meeting safety standards.

For more information, visit: www.st.com/mcu