Home > On-Demand Archives > Q&A Sessions >
Live Q&A - How to Detect Anomalies in RTOS Applications
Dr. Johan Kraft - Watch Now - Duration: 17:45
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!
12:44:32 From Jean Labrosse : What are the latest features in Tracalyzer? It looks like the product evolved. 12:44:46 From Leandro Pérez : I have noted the trend of the SMP microcontrollers… the Tracealyzer for FreeRTOS license permits debug this architecture with more tan 1 core? 12:49:51 From Jay Cosper : In release mode, we would log assert versus trapping 12:50:54 From Quantum Leaps : Assertions are your last line of defense against bugs... 12:51:55 From Gillian Minnehan : That makes sense, thank Aaron 12:51:57 From Gillian Minnehan : *thanks 12:52:59 From Keith J : Re Miro - some would consider asserts to be the first line of defense against bugs (other than not creating them) 12:53:00 From Jean Labrosse : I agree with Miro, assertions is your last line of defense 12:53:29 From Keith J : (not my opinion just one I've heard) 12:54:40 From Quantum Leaps : Great point: you need to *test* your assertion handler under many conditions, including stack overflow and others. 12:55:23 From Gillian Minnehan : Test your tests! 12:55:59 From Jacob Beningo : Lol how many layers of tests is too many? 12:56:11 From Leandro Pérez : Inception… lol 12:56:12 From Jacob Beningo : (Thinking of layers of indirection with poitners) 12:56:40 From Quantum Leaps : I'd say: test your assertions, meaning that you should intentionally inject errors and see if your assertions catch them 12:57:35 From Gillian Minnehan : @Quantum Leaps Agreed. Sanity check like that seems sufficient 12:57:45 From Tim Michals : It is hard to get customers to provide log information, they are worried the logs can be used to reverse engineer the way the product is used. 12:57:54 From Jean Labrosse : … assertions are fine if you can test all of them during development/test. After that, they could become dangerous to have, especially if you leave them in deployed code. However, a lot depends on the application and whether it's safety critical or not 12:58:23 From Jean Labrosse : Great talk Johan! 12:58:32 From Leandro Pérez : Thanks Johan 12:58:38 From Gillian Minnehan : @Tim Good point 12:58:41 From Aaron Fontaine : Great talk Johan. Thank you! 12:58:53 From Gillian Minnehan : Thank you Johan! 12:59:03 From Jay Cosper : thank for the talk! 12:59:06 From Keith J : Thank you Johan 12:59:19 From Stephane : Website seems to be working better now 12:59:23 From Phil Kasiecki : Thank you Johan. I enjoyed the session, and having started my career working on real-time trace systems in their infancy, seeing Tracealyzer shows how far things have come.
Thank you, as usual a useful and clear presentation!