Smart Self-Check Process to Optimize Power-Up for Embedded Systems

I’ve been obsessed with morning routines ever since I started sending my son to kindergarten in the morning. From making breakfast to ensuring that his schoolbag is properly packed, I rarely mess up, except for a rare occasion where I forgot to place his water bottle in his bag.

Despite the rarity of that occurrence, my son wasn’t impressed with my forgetfulness even though I promised it wouldn’t happen again. Now, when checking through his schoolbag, I employ the same zeal and thoroughness that I use when employing a self-check procedure for embedded systems. I haven’t forgotten a single water bottle since my initial mistake.

Why Power-Up Self Check is Important

In a typical embedded system, a microcontroller is connected to various components on the PCB. It relies on memory chips to store critical parameters or historical records. Every single bit of the parameters may affect the outcome of the functional algorithm.

Embedded systems that automate industrial equipment also rely on inputs to activate certain valves or electric motors. In most occasions, the inputs are analog signals derived from sensors that are connected to the PCB. It’s important to ensure the sensors are behaving normally when the system powers up.

As the world embraces IoT, embedded systems can communicate with each other with a broader range of technologies. Regardless of the interface, traditional activities like a basic handshaking protocol or a simple status check are still vital to ensure that the system powers up on the right foot.

Of course, one would argue that reliable firmware would ensure that the proper inputs or parameters are evaluated before an algorithm is executed. So, why should you undergo the hassle of performing a series of self-checks?

Best time to act on systems fault is during a power-up.

In the majority of applications, embedded systems are powered up by technical personnel who are within the close vicinity of the devices. Any anomalies discovered during startup can be immediately acted upon compared to those that are discovered prior to the execution of certain logic, which can be days or weeks later.

Besides that, embedded systems that are interrupted by a power failure may not have the chance to complete their last operations. They may have partially stored a transaction record before losing power. In some cases, the embedded systems are simply not prepared to handle such situations after the power resumes.

Helpful Self-Check Procedures for Embedded Systems

Just as embedded systems can vary in design, the self-check procedures required may vary too. From my experience in developing embedded systems for commercial and industrial applications, here are some of the most self-checks to perform during power-up:

1. Memory Check

Embedded systems usually store parameters or historical logs on memories like Flash, Ferromagnetic Random Access Memory (FRAM), and Static Random Access Memory (SRAM). These memory chips are usually connected to the microcontroller with Inter-Integrated Circuit (I2C) or Serial Peripheral Interface (SPI) protocol.

The problem with SPI when executing a read command is that you may receive an invalid 0xFF hexadecimal value, even when the respective memory chip is faulty. This can lead to the microcontroller executing the incorrect algorithm.

It is then prudent to ensure that each of the memory chips used in the PCB is functional during the startup process. For example, allocate a dummy byte in FRAM and SRAM to compare the ‘read’ and ‘write’ values or retrieve the device ID from the Flash memory.

Ensure all memory chips are functioning during startup with a quick self-check.

2. Database Check

In embedded systems where the historical log is critical to applications, it is a great practice to ensure the database is in good health before any records are stored after a power reset. The database in embedded systems is rather primitive compared to their SQL counterparts in software applications.

Embedded systems database are usually custom-built and there may be latent bugs that escape testing. Basic check on the record pointers is needed to ensure they are within their designated sectors. This prevents database corruptions caused by overwriting of sectors between different data types.

3. Input Check

Embedded systems that are used for industrial automation rely greatly on both digital and analog inputs to execute associated functions. It’s a good practice for the microcontroller to ensure that digital inputs connected safety switches are providing the right value before launching the main algorithm.

In applications where 4-20 mA analog sensors are used, the microcontroller can perform a quick check on whether the sensor is properly connected. An equivalent analog value of less than 4 mA indicates that the sensor is faulty and technical personnel should be alerted immediately.

4. Communications Check

There are some cases where an embedded system is connected to other devices through wired or wireless communications. Getting the microcontroller to initiate a status check on these devices is a good way to identify any faulty devices before the system commences operations.

While we optimistically expect third-party devices to be perfect, my experience has proven otherwise. I’ve had industrial barcode printers that would sometimes refuse to boot up correctly. With a quick poll during startup, I can ensure that any pressing issues are addressed immediately and no angry customers are breathing down my neck.

Of course, performing self-check only makes sense when your embedded system is properly designed in the first place. Personally, I’ve used Altium Designer^®  to help me manage my design and ensure that the best design practices are adhered by using the intuitive DRC.

Are you missing a critical self-check procedure for your embedded system? Talk to an expert at Altium today.