Home > On-Demand Archives > Theatre Talks >
Troubleshooting Embedded Applications with Runtime Visualizations
Kristoffer Martinsson - Percepio - Watch Now - Duration: 32:50
Using an RTOS often increases the complexity of embedded applications. For example, there could be timing issues that only happen in certain situations that are difficult to replicate and debug. Normal debug techniques such as breakpoints often fail to isolate the problem.
Join this presentation to learn how visualization of runtime behavior can ease debugging and help you quickly identify the root cause of an issue, using a hands-on example.
You can use a tool like Tracealyzer to analyze runtime of the ISR. You would be able to see nesting and could analyze execution time, time interrupted by higher priority ISR etc.
Of course this could also be done using instruction trace (ETM).
Great Talk Kristoffer!
Hearing all the interesting questions in the Q&A, brought up another question on my side: For the use case of porting an application from on Target/Rtos/... to another: How generic is the instrumentation of the code?
Is it possible to instrument once and then use Tracelyzer in any setup? If not- How complicated is the adoption to different Target-Set-Ups?
Thanks,
Andreas
Thanks. In the application code there is normally just a few types of instrumentation. It is for ISR tracing and what we call user events. The API for these is generic for all RTOS that we provide a trace recorder library for. So no porting should be necessary because of tracing if you use FreeRTOS, Azure RTOS ThreadX, Zephyr or SafeRTOS.
Most of the instrumentation is done in the RTOS kernel and this is done ?automatically? when adding our trace recorder library to the project.
There is not nearly enough emphasis put on the benefit of visualization tools in understanding the behavior of your system better, and of RTOSs in general. To that point, I can see Tracealyzer being a great educational tool. Computer engineering students learn about task scheduling by drawing it out; I can see a huge benefit in incorporating this tool after they have base knowledge of scheduling and are now ready to see it for a real system.
Amazing presentation and demos, thank you for this very valuable content! :)
Hi Kristoffer... Amazing talk... Of course the Percepio tools are the best to find and analyze strange situations... I have used the tool with the debugger connected to obtain the real data from the device... I have a question... There is a way to save the Percepio information for example in Flash memory to obtain real issues in the field? I have had strange issues to analyze but in the real field... not in development environment... Is possible save that details and after analyze the situations recover the information from the Flash memory? BTW: My favorite technique to track issues is Application Logging
Thanks for the comment. It is possible to store traces in flash so that you can read them later. Getting feedback from the field is an interesting topic and I would suggest that you take a look at our DevAlert product:
https://percepio.com/devalert/
Also check the presentation by our CEO on this topic:
https://embeddedonlineconference.com/session/How_to_Detect_Anomalies_in_RTOS_Applications
Thanks Kristoffer... Of course I will be
Great multi-queue blocking demo, thanks
Thanks for the comment.
Thanks for this nice presentation along with the demos. I'm using Tracealyzer now for rughly 3 years and it helped a lot to understand the timing of our application. I truely agree that it is much easier to analyze and understand what's causing a problem if you have a visual view on it.
It is also very useful to see if you have any bottlenecks in your software and see where starting to optimize is beneficial.
Some more capabilities to do automated measuring and analysis would be fine.
Thanks for the comment. Automation is interesting, especially in testing. We see more requests on these types of features.
Great presentation and great tool, I'm learning every day more features. Some improvements in the usability would be needed, e.g. while measuring the distance between events (one must select the time span on the trace, it would be also nice to have the possibility to select two events in the log or on the events name in the trace and get immediately the time difference).
Thanks for the comment. We really appreciate ideas for improving usability in Tracealyzer.
Hi
As i deduct from the talk this only works if you have a "real" OS?
Most of the systems I come across only have what we call a "Camshaft OS", meaning interrupts is the only threadding available. In other words: 1 task == 1 ISR
Can this tool (realistically) be used for those systems?
One example is that i often use an I/O pin to visualize how often and for how long an ISR is running, By simply putting a pin_high, and pin_low, at the beginning and end of the ISR, then connectiong a osciloscope to that pin (or pins)
This however has several limitations, for one it does not tell me anything of the timing overhead in shifting in and out of that interrupt, as the pin high/low happens inside the IRQ. Also I have to manually measure and compenstae if this is not the higest level IRQ, thus it itself can be interruptet. Not to say if it interrups itself....
I don't know if this information is present in the ETM. But also could this tool help ilustrating this?