White Papers
The Top Five Bugs
The 5 Most Common RTOS Development Bugs—And How To Spot Them presents a number of common bugs in RTOS-based embedded applications, and discusses ways to use Percepio Tracealyzer to spot these bugs in your code.
RTOS 101
RTOS 101 explains fundamental RTOS concepts, such as tasks, priority-based scheduling, queues, semaphores and mutexes, and provides examples of how Percepio Tracealyzer can be used to understand such issues.
Stop Guessing – See Inside RTOS Firmware
Stop Guessing – See Inside RTOS Firmware shows how debugging of RTOS-based systems can be dramatically simplified with better insight into their real-time execution.
Real-Time Demands of the IoT
Real-Time Demands of the IoT discusses some of the challenges with running software on battery-powered MCUs, and suggests ways that RTOS-based software can help minimise power consumption.
How to visualize response times in FreeRTOS
How to visualize response times in FreeRTOS describes a customer case where Tracealyzer was used to measure and greatly improve response time for network I/O requests.
Improving the Reliability of the Internet of Things
An average of 6 bugs per 1000 lines of code remain in shipped software, causing delays, failures and frustration when things go wrong. Over-the-air (OTA) updates certainly make it easy to deploy patches to faulty software. But when OTA updates are coupled with software tracing, it becomes a powerful mechanism for improving the quality and reliability of a wide range of embedded IoT systems.
Tracealyzer Hands On
A selection of the Hands On blog posts is available for download as a PDF here.
Tracealyzer – more than a debugging tool
In our new blog series Hands On, which launches today, we will examine many ways that developers can Tracealyzer besides debugging.
Analyzing communication and data flow in an unknown software stack
One of the biggest problems in embedded development today is understanding what a software stack or demo that you didn’t write is doing. In this post, we’ll examine how we can find this out using the Tracealyzer communication flow diagram.
Verifying Task Timing and Scheduling
Quite a few embedded software developers don’t know whether their applications meet their timing requirements. In today's Tracealyzer Hands On post, we will explore how to use Tracealyzer to verify task timing and scheduling.
Identifying Memory Leaks Through Tracing
Have you ever seen your embedded system behave strangely and had that sinking feeling that you might have a memory leak? Tracealyzer offers several different methods to detect memory leaks.
Understanding your Application with User Events
What if you want to visualize some application data in Tracealyzer, measure the time between two events or monitor a state machine? In this post, we will show how you can set up this kind of custom logging.
Analyzing State Machines
In the previous Hands On post we introduced the concept of intervals, which is the time between any two events and can be added to the timeline. In this post, we will take the interval one step further and see how we can use Tracealyzer to monitor state machines.
Analyzing State Machines, Part 2
In this post, we visualise the custom interval and state machine information available in Tracealyzer and explore how we can use it to better understand our application.
Customizing the Trace Visualization
Within Tracealyzer's trace view, tasks, events and state machines are now organized into view fields, collections of tasks, intervals or events. In this post, we are going to examine how you can use those views to simplify working with Tracealyzer.
Looking at Mutex Usage
We have had a few customers asking us if they can use Tracealyzer to detect when a task holds two mutexes at the same time. The answer is yes, there are in fact several ways you can do this.
RTOS Debugging Blog Series
#1: Dealing with timing issues
There is a learning curve when you begin using a real-time operating system in your development. You will work at a higher abstraction level, using parallel tasks that interact with each other, and you will deal with timing issues.
#2: CPU starvation
In embedded systems using multitasking, you may run into a situation where some of your tasks run slowly or not at all. This is called task starvation and it can happen for a number of reasons.
#3: Chasing the jitter bug
When you have a task in your system that is supposed to execute at regular intervals, say every 5 milliseconds, then you have a system that is sensitive to random delays – also known as “jitter”.
#4: Priority inversion
In embedded systems using multitasking, you may run into a situation where some of your tasks run slowly or not at all. This is called task starvation and it can happen for a number of reasons.
#5: Deadlock
A clear indication that you may have a deadlock problem is when multiple tasks suddenly stop executing, although no higher priority tasks are running.