My New Hack for Debugging
With Lab 4 bringing about a switch in focus to our other hardware unit – the Microcontroller Unit (MCU) – I’ve been running into unfamiliar bugs. More than unfamiliar, some of the SEGGER error messages are downright unhelpful. On the other hand, I’ve grown quite fond of SystemVerilog and Lattice Radiant’s error messages. Sure, their line number is usually a couple off from the problem, but the error messages are descriptive and get the job done. I feel in control of SystemVerilog errors, and know almost instantly when one is going to require special attention. Now, in the land of the MCU, SEGGER, and C, I feel a bit lost with each new error message.
I think of each debugging journey like a scavenger hunt. A SystemVerilog scavenger hunt might have a first clue that sends you to the third drawer of the old hutch in the attic. Inside, you find a spot the difference puzzle that reveals your final answer. Sure, the clues may be a mild challenge to locate, but the solution is typically straightforward and satisfying.
On the other hand, in a C scavenger hunt the first clue you get is to find ‘something round’ in a forest of identical trees. After wandering around for a while, you find a note taped on a branch which reads “the second clue is written in invisible ink on the back of a squirrel.” Good luck.
Now, in all fairness, give me a couple of weeks and I’m sure I’ll be able to tell you which squirrel to look for. After all, I haven’t brushed up on my C skills in nearly a year. However, the learning curve has proved to be steep.
However, that isn’t the point of this post. I’m here to share what has gone well in the face of these seemingly intractable errors. I’ve found one particular technique that has helped me debug more efficiently and effectively, and it has the side benefit of building up my writing skills.
For those who don’t know, our class has a Discord channel started by our professor. It has discussion sections for each of the labs, where students can post questions and (hopefully) get help from the professor and peers. People don’t post as much as I would have imagined – some labs have no discussion threads, while others have just one or two. I know that I haven’t posted in the past largely because it just hadn’t been used before. I always had a classmate around to ask if I really needed, or knew when the next office hours was to get help in person. However, as I drove off with my friends for October break, my most recent bug lingered in my mind. I had tried googling and parsing through my code, but had no good answer. I had decided that the next best step was to make dramatic changes in the structure of my code. In a last ditch attempt to avoid this, I figured that I might as well post my question in the discussion thread first. To my surprise, a classmate responded within 5 minutes and the professor responded before lunch. They both gave me some helpful keywords to use as I searched to understand and find a fix (turned out, “include guards” was half the problem).
This emboldened me. After returning from break, I ran into a bug on Thursday night that stopped me in my tracks. After an hour spent trying to fix it, I got nowhere, and the same problematic lines of code were as broken as ever. Knowing that I wouldn’t be able to attend office hours until after the weekend, and knowing that I couldn’t afford to pause the work for 4 days, I went to craft a discussion thread to ask my peers and professor for help.
The first time I tried to write the message, I quickly jotted down my thoughts in the span of a couple minutes. I hovered my mouse over the little arrow that meant “send”, then paused. Had I really tried everything I could think of to answer my own question? My brain flashed through the possible responses my peers could send… Have you checked the _____ section of the reference manual? Have you tried messing around with the lines of code directly before everything broke? The honest answer to many of these was – no. I had done some of the work myself, but I hadn’t yet exhausted every possible resource.
As I realized this, my mission pivoted. I wanted to write the most bulletproof, well-reasoned explanation of my bug that I possibly could. I figured that throughout this process, I would either solve the problem on my own or come up with the an extremely well-documented bug report. The problem would either solve itself, or be worthy of a new post.
Why has this idea only now come to my mind? As the semester has drawn on, I find it more challenging to work near my peers. Different classes consume us at different times, and several of my closest friends have makeshift laboratory setups in their own rooms. That is to say, I am more and more often working alone in the Digital Lab. This is why writing out discussion posts has been so valuable to me – it has reminded me the value of considering a fresh perspective, challenging my assumptions, and bouncing ideas off of a peer. It lets me go through that process without needing to wait until my next work block with Ket or office hours after the weekend.
This is my new challenge to myself – I want to be more active in the class Discord discussion threads. Although there aren’t a plethora of other student posts, I want to make a more active effort to respond to them. More importantly, however, I want to commit to writing out my own questions more often. I want to commit to only sending them once I’m well and truly convinced that I have exhausted my own reserve of possibilities. I figure that if I adhere to this, I will become a better problem solver while I practice writing effective problem reports.