Microcontroller software bugs squirm under the radar

We hear lots of comment on the slew of bugs found in the products of Microsoft, Sun and Linux, but very little on the bugs that are almost certainly present in microcontrollers, which have over 90 per cent of the installed computer base.

As the capability of these chips expands and the number of applications per chip is expanded, so too will bugs proliferate.

I will start by illustrating what I am certain is a microprocessor bug, with potentially fatal consequences, and then describe a banking bug in an ATM which resulted in severe consequences for the ATM user. There are no doubt dozens of other cases.

I have a Japanese car and, after considerable driving, a sensor light (controlled by a microcontroller) indicated an engine problem. The vendor tried several times to find the problem (each costing dollars) but was unsuccessful. On one occasion, in seeking the problem, they left a loose connection which sprayed gasoline into the engine, turning the car in to a potential time bomb (this cannot be blamed on the sensor but was a consequence of the sensor problem).

The sensor light is now permanently on and I am convinced it is a software bug beyond the vendor’s capability to fix. This same sensor is in hundreds of thousands of cars.

A policeman returned to England from vacation to find that his account had been drained by four withdrawals from an ATM. The bank claimed that their software was bug-free, having been written in assembler language (what uneducated arrogance), and that the policeman was committing fraud by telling lies.

The bank took him to court and won, resulting in the policeman being dismissed. He appealed and, after four years of stress and unemployed anguish, he won an appeal. His lawyer had asked for equal access to the software code, which was refused, and so won the case because the bank involved was reluctant to have anyone examine the software.

I had a similar experience with less severe consequences. Someone accessed my account in Los Angeles at about the same time I withdrew money in London, the timing being such that it was impossible for me to be in both places.

Among other things, I write software in assembler for microcontrollers. While they generally separate data from code they will usually use two types of memory and incorporate some form of encryption and/or biometrics, such as fingerprint scans. Timing is often critical. In particular, initial software development is often done through simulators, transferring to a smart card or embedded environment when you “think” all the bugs are out. There are many opportunities for bugs.

The situation worsens when several microcontrollers are used together, such as in a robot submarine, or in an automobile. If a bug is in one system it can affect all linked units. In one instance, a depth sensor in a robot sub failed and such a failure was not catered to in the other units, resulting in the sub diving to the bottom and requiring rescue.

Added to the problem is the fact that vendors such as Visa and Barclays are creating ubiquitous operating systems and some are also making what I think is the mistake of using Java. Having developed a Java-run system for a smart card microcontroller, I am convinced that it is not the way to go, nor is it necessary to develop operating systems. It only creates an environment for bugs to be introduced, the application developer no longer being in full control of the situation.

Microcontrollers are installed in millions of devices around the world, in appliances, with multi-units in cars, pipelines, airplanes, airplane engines and nuclear power generators. Once in the field, it is extremely difficult to correct, or even identify (can you expect the Maytag man or the auto mechanic to have the ability to know there is a software bug, let alone fix it?)

The consequences of bugs can vary from minor annoyance (such as a light switching itself off), to personal stress as in the policeman case, to potentially lethal circumstances, as in the case I described, assuming that it was a sensor bug, or with the submarine, had it been manned.

We have no statistics, as far as I am aware, of how many accidents might have been caused by microcontroller sensor error. There are likely very few accident investigators who could even look for or identify a microcontroller bug as the cause of the accident, yet I am sure that in many accident cases this could be the cause. Unfortunately, any such conclusion would be fought to the death by companies with the attitude of the aforementioned British bank.

QuickLink 056946

— Hodson is a theoretical physicist, speaker and writer. He can be reached at [email protected].

Would you recommend this article?


Thanks for taking the time to let us know what you think of this article!
We'd love to hear your opinion about this or any other story you read in our publication.

Jim Love, Chief Content Officer, IT World Canada

Featured Download

Featured Articles

Empowering the hybrid workforce: how technology can build a better employee experience

Across the country, employees from organizations of all sizes expect flexibility...

What’s behind the best customer experience: How to make it real for your business

The best customer experience – the kind that builds businesses and...

Overcoming the obstacles to optimized operations

Network-driven optimization is a top priority for many Canadian business leaders...

Thriving amid Canada’s tech talent shortage

With today’s tight labour market, rising customer demands, fast-evolving cyber threats...

Staying protected and compliant in an evolving IT landscape

Canadian businesses have changed remarkably and quickly over the last few...

Related Tech News

Tech Jobs

Our experienced team of journalists and bloggers bring you engaging in-depth interviews, videos and content targeted to IT professionals and line-of-business executives.

Tech Companies Hiring Right Now