Home >

Adventures in Debugging

Alvaro Prieto - Watch Now - Duration: 42:19

Adventures in Debugging
Alvaro Prieto

Have you ever had tricky, hard-to-find bugs in your hardware/firmware? Me too!

Join me while we go through some past troubleshooting and debugging adventures and learn various techniques and tools in the process!

Some topics might include:

  • GDB and python
  • Various signal probing techniques
  • Simple tracing (without additional hardware!)
  • Debugging remote devices
  • Useful (and not-so-useful logs!)
  • Fatfs performance lessons
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
>

RaulPando
Score: 1 | 4 weeks ago | 1 reply

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
Alvaro
Score: 0 | 4 weeks ago | no reply

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!

moredatalesscenter
Score: 1 | 4 weeks ago | no reply

Thankyou, that was very informative and well presented!

Davide.Ferrari
Score: 1 | 4 weeks ago | no reply

Such a cool presentation! Thanks a lot for sharing, almost 100% of similar situations happened in my career too..

Phil_Kasiecki
Score: 0 | 4 weeks ago | no reply

Great presentation. The lessons learned with the SD logging are interesting, especially since a couple of them have parallels elsewhere in software.

bill.tilman
Score: 0 | 1 month ago | no reply

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.

LeroyL
Score: 0 | 1 month ago | no reply

Great debugging stories,. thanks

Joe_Hopper
Score: 0 | 1 month ago | no reply

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!

OUR SPONSORS