PIC Microcontrollers for Safety Critical Applications

by Chris Francis

Microchip recently announced some microcontrollers for “safety critical applications”. I was interested to see what the difference was and how they might compare with other manufacturers’ microcontrollers aimed at similar applications. The first thing I found out was that there don’t seem to be many microcontrollers aimed at safety critical applications. The Texas Instruments “Hercules” TMS470M/TMS570M and RM4x microcontrollers are 16/32 bit, high pincount devices which are presumably targeting a different market to the low pincount 8 bit devices offered by Microchip. They are also quite a bit more expensive than the PICs.

PIC12/16F1612/3

At the moment there are very few Microchip devices in this new category for “safety critical applications”. The PIC12F1612 and the PIC16F1613 (plus LF versions of both) seem to be the only ones for now. They really seem to be targeted at specific applications because they also include new features not seen on PICs before but which are nothing to do with safety. For example, they have hardware zero crossing detection which could be very useful in applications such as TRIAC control or measuring mains frequency but are nothing to do with “safety critical applications”. They also have 24 bit “Signal Measurement Timers”. Most of the new features seemed to be aimed at anything with a motor in it, either domestic appliances or small industrial products.

The new features which are aimed at safety critical applications are:

• Cyclic Redundancy Check with Memory Scan (CRC/SCAN)
• Windowed Watchdog Timer (WWDT)
• Hardware Limit Timer (HLT)

The hardware limit timer operation is an extension to the normal timer operation and allows, for example, the timer to be reset based on an external signal which can include the new zero-crossing detector output. The reset could also be from an analog signal because the analog comparator output can be used to reset the timer. There are several HLTs in the PICs depending on the version – they are normal timers with extended functionality.

The CRC with memory scan is a software-configurable, hardware-implemented CRC checksum generator. The CRC can be software driven but in memory scan mode it can be set up automatically scan the FLASH memory looking for corruption, with the range of interest under user control. There is still some software interaction required as when the CRC has been computed (by the hardware) it will generate an interrupt for the software to read the value. Except for “PEEK mode” which reads the memory when it isn’t being used, all other modes of memory CRC calculation halt or stall the processor so the mode of operation needs careful thought if you are going to use the CRC memory check. Peek mode could take a very long time to complete a scan as there are limited times when the flash memory is not being accessed. The mostly likely use I could envisage is the burst mode on startup – effectively checking the integrity of the program before the program is run, rather than trying to detect flash memory corruption on-the-fly although peek mode could be used after startup as a secondary check. Concurrent mode alternates CRC flash memory access with the CPU so that could be used at the expense of processing speed.

The windowed watchdog timer is a welcome addition to watchdog timers which don’t seem to have changed much since they were introduced many years ago. It is not very complicated but whereas a normal watchdog timer simply times out if it hasn’t been cleared within the time-out period (causing a processor reset), the windowed version will also reset the processor if the watchdog timer is cleared too soon. The window size if 12.5% to 100% of the watchdog period time. At 100% the watchdog is simply “normal”.

If the watchdog timer is set at 16ms and the window is set at say 25% then the watchdog must be cleared between 12ms and 16ms. If it is cleared before 12ms then the watchdog timer will reset the processor. I am not sure how realistic such a narrow window is though. The watchdog timer is a very poor tolerance – 16ms could be somewhere between 10ms and 27ms. So, if the triggering of the watchdog is from an unrelated (and most likely, accurate) clock, then you could not guarantee to hit the 25% window. Even a 50% window would only just be guaranteed to be usable. Nevertheless, a wider window should still allow you to set it up to catch software struck in a loop where it is repeatedly clearing the watchdog timer at a rapid rate which would fool a normal watchdog timer.