Home >
Live Q&A - How to Detect Anomalies in RTOS Applications
Dr. Johan Kraft - Watch Now - Duration: 17:45
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.
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.
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?