Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Controls/MCUs

STM32: a Class B ready MCU platform

Posted: 17 Nov 2008 ?? ?Print Version ?Bookmark and Share

Keywords:32bit MCU? microcontroller? Class B device?

By Vincent Onde
STMicroelectronics NV

Home appliances have to comply with IEC60335, which is intended to prevent malfunction in case of fault condition. The 4th edition of the standard has garnered attention from white goods' electronic control designers, and more specifically software developers, with the introduction of software inspection and the notion of software classes. Depending on the class (A/B/C), MCU components have to be tested at power on and monitored during run-time for safety critical applications.

So, just what is Class B? What must be done to fulfill the norm requirements? How can a microcontroller manufacturer help its customers minimize development cost overhead, and to some extent, help them get their application certified? Why can we consider STMicroelectronics' latest 32bit MCU, the Cortex-M3 based STM32, as a Class B ready device? We'll address these points and give a few practical examples within this article.

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. Room thermostats or lighting controls, for instance, are in this class. 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. This last will not be discussed, first because it could require systems with redundant MCUs, which exceeds the scope of this paper, and secondly because the vast majority of household appliances whose electronic controls must prevent unsafe operation belongs to the Class B category.

This is typically the case for washing machines with electronically-controlled door locks or dishwasher pump drives with motor over-temperature detection, just to mention a couple of examples.

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

These tests can be carried out directly with the MCU 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, it is stated 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.

Figure 1 shows an overview of the STM32's clock circuitry, which shows the various clock sources and their connections to the rest of the chip.

Figure 1: This shows STM32's failsafe clock circuitry and dual watchdog system.

Notice on this diagram 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 system level, this saves the cost of a 50/60Hz mains zero-crossing detection circuitry, unless this is requested by the application to fire a triac.

Finally, the STM32 embeds a 32bit 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.

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; it would have impacted the cost-effectiveness of the controller, and it can easily be implemented by software. For this reason, ST 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)

Let's consider now one of these modules, the RAM functional test, which helps with understanding class B software constraints. The standard asks to test periodically the RAM for DC faults (e.g. 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 contrary, if the application remains powered, the tests must be repeated during run-time also, and things are 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 on Figure 2.

Figure 2: This shows the control flow monitoring principle.

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 ?s.

This example shows how beneficial such a firmware library can be, as regards 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.

Figure 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. Let's quickly review what to do 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 we have a 10ms heartbeat interrupt and a pulse-width modulation (PWM) update event every 500?s, each interrupt can detect a malfunction with simple software counters. In the 10ms ISR, one must read a PWM ISR counter between 19 and 21 (20ms x 0.5ms giving 10ms). Vice versa, after 100 PWM interrupts, we must verify that there was between 4 and 6 heartbeat ISRs (100ms x 0.5ms = 50ms = 5ms x 10ms); 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.

Figure 3: This shows a run-time transparent RAM test.

For the I/O periphery a software Class B must detect any malfunction on digital I/Os and on analog channels. This is covered by plausibility checks. For instance, we can consider a heating element controlled with a triac and regulated with a NTC resistor connected to the ADC. 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 very 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 32bit MCU having IEC60335-1 certified self-diagnostic routines. Providing these modules are used unchanged and according to ST's integration guidelines, they will not be re-evaluated in-depth, thus easing the process and reducing time and cost 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 appliances platform, where it can drastically reduce the time-to-market overhead to comply with the new standard. Finally, the newly announced STM8 8bit MCU product line, which also targets the household appliances market, embeds as well a dual watchdog and failsafe clock circuitry, and is supported by self-test routines approved by the VDE in February 2008.

Article Comments - STM32: a Class B ready MCU platform
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top