Back in the day, we could code up the firmware for a micro controller and store all of the device initialization and application code in ROM. Naturally, we’d transfer the code to RAM for speed-of-execution. However, today’s SoCs bring many more capabilities than a humble micro controller ever could, and SoCs consume less power every day. So, the burden placed on software developers has been turned up a notch.
Software tasks are becoming more complex, requiring not only hardware initialization but also power management and application initialization. And the days of the “simple” real-time applications are fading fast. Don’t get me wrong, real-time applications are still very prevalent; they’re just no longer simple. Now, many of the designs with complex SoC often require a RTOS. Increasingly, designers are selecting ThreadX from Express Logic as their choice for a RTOS because of its configurability, small footprint and real-time responsiveness.
But here’s the rub – without enough visibility into the multi-threaded context switching and OS resources, integrating an RTOS into the design can become much more work to identify the software bug that might jeopardizes the product’s on-time delivery to the market. SourcePoint™ has now added support for ThreadX to provide that extra visibility when required to examine the task stacks and thread status so product debug is much clearer.
SourcePoint allows the user to select OS resource views of threads, timers, queues, semaphores, mutexes (mutual exclusions) and other components of the operating system. The SourcePoint debugger can display a view of the currently running thread at the point where it was stopped or another thread that is preparing to run. The program counter for the thread is displayed where the software was interrupted. The stack frame as well as the variables for the thread will also be displayed. Selecting one of SourcePoint’s resource tabs will show the engineer the state of each thread in the program as well as the condition the thread needs to continue execution.
Check out this SourcePoint screen capture. It shows the ThreadX resources for an active software thread.
We’re seeing more often these days that debugging software must encompasses a system approach. Pure debugging of software and hardware isolated from a system view is fraught with pitfalls. SourcePoint certainly helps to accelerate code debug and then many of the other tools on ASSET’s ScanWorks® platform can help with the rest of system validation.
Embedded developers might also be interested in a recent eBook we’ve published on how to capitalize on the capabilities of ARM’s System Trace Macrocell (STM). Check it out here.
