IEC/UL60730 safety compliance and MCUs

Using MCU features and self-test can simplify EC/UL60730 compliance

BY SANDHYA MALLIKARJUN
Manager, Applications Engineering
Fujitsu America
www.fujitsu.com/us/

The IEC60730 standard for safety is an established testing specification for electrical, electronic, mechanical, EMC, and other features of ac appliances. Applying the IEC/UL 60730 standard to the design of appliances improves safety for consumers, so most companies that develop home and consumer appliances and motor-controlled applications comply with the standard. To simplify compliance, these manufacturers require components that can be certified as compatible or compliant to IEC60730.

The International Electrotechnical Commission (IEC) prepares and publishes International Standards for all electrical, electronic, and related technologies. The IEC is one of three global sister organizations (IEC, ISO, ITU). In IEC terminology, safety is defined as an acceptable level of risk, which is consistent with the Underwriters’ Laboratories goal of reducing the chance that a consumer product will catch fire, deliver a shock, or injure a person. Appliances incorporating electronic circuits are subject to component failure tests; the appliance should remain safe even if an MCU or other component fails. Safe appliances are those that can remain functional following a hardware failure, or a single hardware component failure, or if the MCU fails to operate. If the software can affect product safety, the software is taken into account with the second applied failure.

Compliance

The compliance of application-specific parts depends on a customer’s application structure and must be defined and developed by the user based on factors such as communications, I/O control, interrupts, analog inputs, and analog outputs. However, compliance of MCU-specific parts depends solely on the MCU’s structure, and compliance methods can be the same for any application. The methods involved in MCU compliance include core self-diagnostics, volatile and NV memory integrity checking, and clock system tests. This is a vital set of variables because the newest generations of MCUs can tell if a product is functioning incorrectly. Many companies have now developed MCU hardware and software that can be considered optimal for achieving IEC60730 compliance, simplifying the process through self-test routines and other capabilities.

Table 1: MCU parts that must be tested for class b compliance

Table 1 lists the MCU and ASSP features that can be tested. Table 2 lists specific requirements for IEC 60730 compliance, along with the applicability of hardware and/or software to attain compliance.

Table 2: Requirements for IEC 60730 compliance.

Tests 5 and 6 are not relevant to MCU self-tests; memory in a custom device or other kind of component external to the MCU usually performs the functions. While there are several choices for addressing the testing, using the single channel test option cuts costs and improves performance.

Swr/hdwr considerations

Software test libraries can significantly reduce compliance efforts as long as the routines can be integrated without impacting other operations. System designers must write code in assembly language for testing registers, the program counter, and RAM, while C code is used to test clock, interrupts, ROM, GPIO, and ADC. A well-designed self-test library supports assembly and C mixed coding on the IAR and Keil Compiler IDE platforms.

For compliance purposes, it is an advantage to build as much functionality as possible into a controller, adding enough on-chip memory, for example, so there are fewer “external” tests required. Using a single MCU with a watchdog timer also is recommended, as are devices that integrate accurate, high-resolution, on-chip RC oscillators. These MCUs also integrate hardware and software watchdog timers, high-density on-chip memory, and failure-detect functions such as low-voltage detect/brown-out reset, a clock supervisor, hardware memory CRC, and ECC features for flash memory integrity checks. On-chip supervisory circuits such as brownout reset and power-on reset preserve the operational integrity of the MCU and the surrounding system. In the case of motor control applications, a fast PWM shutdown feature protects the expensive IGBTs or MOSFETs in the system’s power converter.

Example MCU for appliances

Fujitsu is one of a number of companies with MCUs that easily comply with the standard because they integrate maximum functionality and reduce the external testing requirements. The FM3 ARM Cortex family is an excellent example. All members of family use the standard ARM CPU core, tools and features, so future programming can build on a steady foundation. This also offers easier migration of code across product lines and from one generation to the next. The family incorporates important advances in code development. The Fujitsu libraries enable immediate use of the controller’s on-chip safety features in place of expensive external devices.

In a variable-frequency air-conditioning unit, for example, a single MB9BF500 series MCU (see Fig. 1 ) can precisely control two three-phase motors and calculate power factor corrections.

Fig.1: Fujitsu Cortex M3 MB9BF500 series.

Hardware enhancements are matched on the software side with a new version of the firmware library.

IEC60730 self-test library structure

Fujitsu's self-test library (STL) for the FM3 Family covers the IEC60730 and IEC60335 requirements. These libraries use a standard API between the system hardware and the application software (see Fig. 2 ).

Fig.2. Fujitsu self-test library API.

To use the library, the application software executes a function call to the appropriate self-test module. Each module returns a value representing either the test result or a test value (as in CRC tests). The application software then issues a pass or fail, or checks the resulting CRC value.

Figures 3a and 3b show the self-test library solution structure. Class B routines are divided into two main processes — start-up and periodic runtime (POST and BIST):

• Pre-operation self-test (POST): These tests, which cover items such as the CPU, RAM/ROM, and I/O peripherals, should be implemented at system startup. The POST CPU register tests do not retain register data, and it is mandatory to execute these tests before any other application or system initialization. Preferably the tests should be executed prior to branch to main. All tests are executed in one routine, which allows the quickest test completion.

• Built-in self-test (BIST): To decrease the test time and use of CPU resources, the CPU register BIST testing is divided into five separate tests. The first three test the general-purpose registers, while the fourth tests the stack pointer. To prevent the system from crashing, all interrupts and exceptions are disabled while running this part of the CPU register BIST. The fifth BIST test checks the other special registers. Two example projects are provided, for the IAR or the Keil compiler.

Fig.3a:. Fujitsu – FM3 self-test library solution structure.

Fig. 3b: Fujitsu FM3 Self-test lLibrary – project structure.

As shown in Fig. 2b, seven test items are provided: CPU, clock, interrupt, flash memory, RAM, GPIO, and ADC peripheral. CPU test and RAM test are in assembly and all other tests are coded in C. IEC60730_demo.c provides an example project for self-test library calls and an interface for user application software.

For more information, visit www.fujitsu.com/us/ser vices/edevices/microelectronics/microcontrollers/whitepa per/wp_fm3.html ■

*Involves tests external to MCUs