Home > On-Demand Archives > Talks >
How to Detect Anomalies in RTOS Applications
Dr. Johan Kraft - Watch Now - Duration: 35:38
If you work with embedded software, you have probably encountered many anomalies over the years. Unexpected deviations in the software behavior, big or small, that may indicate elusive software issues, malfunctioning hardware or even cybersecurity attacks. Such anomalies may cause major problems if not detected and resolved quickly.
Join this webinar to learn best practices for detecting anomalies in RTOS application behavior. You will also gain insight how anomaly detection can be deployed to provide diagnostic data for remote analysis and debugging, both during system testing and in deployment at scale.
Great talk and Q&A, thanks! I've tried defining different fault handlers but they don't seem to give any more information than IAR does when it gets to the hardfault handler, or is the benefit that the register values can be logged in production when there is no access to debugger?
I've also tried using Tracealyzer and found it tricky to setup with uC/OS-III and then "hard to see the woods from the trees" when trying to see what's going on in my application (over 20 tasks). Any advice?
Yes, hardfault handlers doesn't allow for any additional information compared to a debugger. My point was to enable detection and reporting in production, when no debugger is connected.
Regarding Tracealyzer, if you would like more guidance on how to leverage Tracealyzer, I suggest you contact support@percepio.com and book a free session with our senior FAE, Kristoffer. There is also plenty of material to read and watch at these links:
- https://percepio.com/runtime-insights-recordings/ (webinar recordings)
- https://percepio.com/rtos-debug-portal/, especially these:
-- https://percepio.com/2018/09/04/analyzing-unknown-software-stack/
-- https://percepio.com/2018/10/23/understanding-your-application-with-user-events/
-- https://percepio.com/2018/12/03/digging-deeper-into-state-machines-visualization/
-- https://percepio.com/2019/01/16/hands-on-using-view-fields/
Hi Johan - Wow, thanks for this amazing talk packed with tons of valuable insights! I cannot wait to translate those into benefits on my current project - even though that will be some time down the line, since I surely need some time to process all the input :-)
There is one more lingering open question that is haunting me since your talk and that of Kristoffer:
I would really like to repeatedly trace/profile a module which is part of a greater system used on different targets (varying MCU/RTOS/..) in order to ensure that critical parameters are and stay within tolerable limits - Basically every single data-piece from your talk :-). It could even be, that this module is implemented several times separately. It goes along the theme we just heard a presentation today from Tyler "Essential Device and Firmware Metrics"
I would really appreciate to get some ideas/thoughts on this!
Thanks again for this marvelous Talk Johan!
Andreas
Hi Andreas. Thanks for positive review! Perhaps we could schedule a call to discuss this further? Contact me at johan.kraft@percepio.com and propose a time.
Hello Johan,
do you know any techniques, how to create core log file for gdb analysis in STM32F7 MCU? It should be done in hard fault and store call stack. Gdb allow to show local variables and member class variables too, but i know it from linux. In this case should have to do analysis in linux too with any cross gdb. Thank you.
Well, I found this thing on github recently. I have not tried it myself though. https://github.com/adamgreen/CrashDebug
It is perfect, thank you very much for valuable source, i add it to our TODO list.
Does DevAlert only stores and handles errors / issues detected on the devices or does it also handles more metrics-like data (eg: storing battery percentage at regular interval to detect if the battery gets drained too quickly) ?
How are DevAlert and Traceanalyzer linked ? Is it possible to use one without the other ?
Support for metrics is planned. But you can always handle it in application code and use DevAlert for reporting and diagnostics.
DevAlert uses Tracealyzer for diagnostics, but Tracealyzer can also be used on its own.
I know this post is old but just to add. I think the tool from Memfault can track battery state for IoT devices and Crash dumps from ARM
https://docs.memfault.com/docs/best-practices/metrics-for-battery-life/
Excellent talk. Very well done.
Thanks Jean!
Thank you, as usual a useful and clear presentation!