Home > On-Demand Archives > Q&A Sessions >
Live Q&A - Adventures in Debugging
Alvaro Prieto - Watch Now - Duration: 20:09
Hi Alvaro,
Very informative presentation, thanks for sharing the details for the ventures with us. The Python bindings for GDB look really cool, I will be checking those out right after this comment :).
Although not directly related to debugging, I am curious about a couple of points.
- What's the main decision behind using dynamic allocation for your application?
- Ignoring the monetary constraints of Iridium comms, do you think it would be technically possible to send a binary image to effectively support OTA or are there inherent limitations imposed by the short burst nature of this bearer?
Thanks
Thanks Raul!
Honestly, the main reason I went with dynamic allocation was development speed and flexibility. We could have done most of what we're aiming for with static allocation or pre-allocated fixed buffers, but that would have taken much more time up front, which we didn't have, unfortunately.
Also, due to the device's configurability, it's nice not having to re-compile when I want to give more resources to a certain task (RAM buffering SD logs was a huge performance win, but I allocate different sized buffers depending on how often we write to the logs). There's also some very high speed operations (I2S microphone sampling) which benefit from huge buffers but only for short bursts of time.
On the Iridium side: Nothing technically stops us from receiving an update image over several days. Monetary constraints aren't the only ones with Iridium SBD though. We are unable to receive a message without first transmitting one, so the power costs are enormous too!
I use CubeMX but also find it clunky with USB in particular, as it doesn't support composite classes. Why would you use GDB over a visual debugger in your IDE? Have you used SystemView or Tracealyzer?
Thankyou, that was very informative and well presented!
Such a cool presentation! Thanks a lot for sharing, almost 100% of similar situations happened in my career too..
Great presentation. The lessons learned with the SD logging are interesting, especially since a couple of them have parallels elsewhere in software.
Debugging is fun and enlightening. Discerning HW vs SW issues is why you do need to have the ability to get into both sides of it to understand the issues that "might" be. Very good show and tell of what you ran into and how to chase them with the many tools that it takes.
Great debugging stories,. thanks
Great presentation, Alvaro! It was very helpful to see you walk through the thought process on how to track down complex issues. Also, I have those same magnetic probes and I tell everyone I can about them - they are fantastic!
17:13:35 From Jay Cosper : Interesting talk! What kind of changes have you made to prevent these from happening again? 17:14:56 From Erin RobotGrrl : Do you keep the CubeMX formatting or just take the functions it generates and put it in your own code? 17:15:32 From enrico perera : I recently discovered Segger RTT ..wow. What is a technique(s) you learned in the last year (or whatever) that really changed how you debug or can debug ? 17:17:36 From enrico perera : yup 17:17:53 From Robert Hancock : You alluded a bit to the challenges in having devices operating in such remote locations - do you have any way to recover or gain access to devices once they are way out in the middle of the ocean? 17:17:55 From Erin RobotGrrl : Very cool to hear how that is done with CubeMX being used professionally! Thanks! 17:19:47 From Vikesh Raghuram Shantha Kumari : In Corrupted serial data issue, was it firmware bug or more of a config error ? because we don't usually miss config conditions while writing unit or system tests 17:20:14 From Alvaro: https://interrupt.memfault.com/blog/automate-debugging-with-gdb-python-api 17:21:03 From Erwin : Thanks for your interresting presentation! The fun fact first regarding your crystal problem: I was facing nearly the same Problem About 6 years ago using an stm32l0 :-) By the way my desk Looks nearly the same (pcbite, saleae) and i live these tools too! 17:22:20 From jackie : q: you use FreeRTOS, is there specific reason over Zephyr and others 17:23:26 From Charles Miller : Task stack overflow errors are intermittent; rule: instrument those stacks--always! 17:25:22 From Max Hughson : Could you compress a complete core dump to save some money? 17:26:46 From Aaron Fontaine : The other thing with Zephyr is you have to learn device trees and Kconfig. 17:29:42 From Stephane : https://embeddedonlineconference.com/theatre/Tools_for_Embedded_Systems_Development 17:31:21 From Gillian Minnehan : Thank you!
Thanks for your presentation, Alvaro. Watching a bit later than everyone else! It's always so interesting to learn about strange behavior and how to debug them, especially in embedded systems, where it's not always clear whether the issue is software, hardware, interfaces, or something else. It's rare to get a glimpse of someone else's experiences and thought processes to learn from them. Thanks for putting it out there!