Home >

Live Q&A - How to Detect Anomalies in RTOS Applications

Dr. Johan Kraft - Watch Now - Duration: 17:45

Live Q&A - How to Detect Anomalies in RTOS Applications
Dr. Johan Kraft
Live Q&A with Dr. Johan Kraft for the talk titled How to Detect Anomalies in RTOS Applications
M↓ MARKDOWN HELP
italicssurround text with
*asterisks*
boldsurround text with
**two asterisks**
hyperlink
[hyperlink](https://example.com)
or just a bare URL
code
surround text with
`backticks`
strikethroughsurround text with
~~two tilde characters~~
quote
prefix with
>

moredatalesscenter
Score: 0 | 2 months ago | 1 reply

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?

JohanKraftSpeaker
Score: 0 | 2 months ago | no reply

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:

Andreas-J
Score: 0 | 2 months ago | 1 reply

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

JohanKraftSpeaker
Score: 0 | 2 months ago | no reply

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.

OUR SPONSORS