How to Perform Memory Testing in Embedded Systems

As I get older I find I have more and more memory problems. I walk into a room only to forget why I went in there, several times. I’ve even started to forget the city streets in my hometown and have to use a GPS to get me places. As annoying as normal memory problems are, memory issues in embedded systems can be much worse. Memory leaks, fragmentation, and even crosstalk can affect your memory units. If you’re not prepared this could lead to individual system failures or even cascading failures. That’s why it’s important to test your memory and catch these faults, both in the testing process and during operation.

The Importance of Testing

As an engineer you know that an untested system is an unreliable system. When it comes to cars with advanced driver assistance systems (ADAS), instability is unacceptable. Things like automatic lane changing and automatic braking have no room for failure. When it comes to storage, a memory protection unit (MPU) can help prevent cascading failures, but memory issues can still cause individual systems to fail. In-house testing can help ensure that your code doesn’t cause any memory complications. As well, self-testing in the field will verify that your ADAS enabled vehicle is working properly before it starts driving.

Everyone does debugging during the development process and testing before deployment. The only way to perform these checks is with the right tools. A standalone debugger can speed up your work, and a static analyzer can help you check if your MPU is working properly. When it comes to memory you’ll need tools that can detect things like memory leaks and fragmentation. Without these tools, it’s unlikely you’ll find memory problems while building your program.

After your product leaves your office your work still isn’t complete. Using self-testing systems to check and see if your memory is working in the field will help you nip problems in the bud and reduce the risk of failure. You don’t want to find out that your memory wasn’t working from technical forensics at a crash site. Self-testing will let you catch a problem in the parking lot where it’s a nuisance before it gets on the highway where it’s dangerous.

It’s important to test your software and hardware both in the office and in the field.

Common Memory Problems and Solutions

System storage has several different failure modes, some of which are not preventable. The ones we can deal with and will look at are memory leaks, memory fragmentation, stuck bits, and crosstalk.

• Memory Leaks - A memory leak occurs when your program doesn’t free up memory that is used. Eventually, your memory will fill up and your program and system will fail. Coding with best practices will help you avoid memory leaks, but they’re a fairly insidious kind of memory failure. Often they won’t show up during testing and will happen after your product is in the field. That’s why it’s important to use a memory leak detection tool before deployment. These tools can help you find issues before they actually manifest and cause havoc.

• Memory Fragmentation - Fragmentation occurs as your program carves out blocks of memory to use. Oftentimes this won’t be a problem as systems can operate in a pattern where they don’t need large unfragmented pieces of storage. However, when they do it can become a big problem. Similar to memory leaks you’ll need a special tool to detect this problem. You can get a memory mapping program that shows you memory usage as your system runs. Then you can make changes in your code to reduce fragmentation to an acceptable level.

• Stuck Bits - Sometimes specific bits in memory modules can get stuck to a 1 or 0. This is obviously a problem as when the memory needs to write the opposite to that space, it won’t change. Testing for this can be done easily in the field. On startup, you can simply tell your program to write all bits of your memory to 1 and then to 0, then check them. This testing will help verify that your memory is operating correctly but will add more time to your startup.

• Crosstalk - We’re not talking about the crosstalk associated with electromagnetic interference here, well, not exactly. This kind of crosstalk occurs when changing one bit changes another unintentionally. To test for this you can write all 0’s to your memory (like in the previous test) then change each bit to 1 and back to 0 individually. You can also do it the other way, from 1 to 0 and back. This kind of test will also take time, but it’s worth it. It can also be done during operation as well as at startup. You obviously won’t be able to test every bit as some will be in use, but you can check idle bits to ensure that your memory is working well the whole time it’s being used.

Make sure your car’s memory is working before your user puts it in drive.

When it comes to my personal memory, failure is sometimes an option. It doesn’t really matter if I forgot I went to the kitchen because I wanted to eat a cookie. It matters a lot more when your memory is functioning in a system hurtling down a highway. Testing during development and operation will help you make sure that failures are caught before your user gets up to speed. You can test for memory leaks and fragmentation with specialized tools while building your program. Once you’ve released it into the wild you can use self-testing methods in your program to ensure that your memory continues to work as it should.

Software development for vehicles is a complex and difficult job. Just like when testing for memory fragmentation or leakage it’s important to use all the right tools. TASKING has developed a wide range of tools specifically made to help engineers like you develop code for cars. That way you can be sure that the product you produce is safe and the best it can be.

Have more questions about memory testing? Call an expert at TASKING.