QEMU Debugging and TIL

This week was busy.

I helped co-teach an improv rehearsal while my coach was away, spontaneously went to see a movie with friends, finished some good books (Debugging by David Agans and How to Read A Book by Mortimer J. Adler), and wrote the entirety of a rough program in a day that converted numbers between base 2, 10, and 16, or as their familiar names are called, binary, decimal, and hexadecimal. I wrote it for the purpose of re-familiarizing myself with the Forth language, since I haven’t written a program with Forth in a while. About a quarter of the way through, the program turned out to be a funny talk-show-like system with cheesy jokes and puns. You can check it out on GitHub.
Forth is an awesome interactive language, you can check it out here with the official online book by Leo Brodie, Starting Forth. I’ll write a bigger post on Forth later, today I’m sharing my debugging issues and talking about a system emulator called QEMU.

Once I finished my Forth conversion program, I took a break, but eventually gravitated  towards finishing an old assembly program I wrote a while back that converted an array of fahrenheit values to celsius. I had finished it, but unfortunately, lost all my work when I accidentally wiped the contents of my computer (which is a story for another time). I used QEMU to debug it at the time, but I lost my debugging log along with the wipe, sadly.

QEMU is a downloadable, open source, full system emulator. You can use it to emulate types of processor cores/CPUs, machines, or OSs all without having to own the actual device. It’s handy when you don’t have the money to buy an actual microcontroller, and you can run it straight from your terminal.

I finished rewriting my program in ARM assembly and geared up to debug my messy, night-time written code, until the qemu commands I had recovered suddenly failed. I was executing:
qemu-system-arm -machine raspi2 -cpu cortex-m3 -s -S -nographic -kernel -gdb tcp::1234 f-c2.elf

First I got the error:

qemu-system-arm: -kernel -gdb: Unknown protocol 'tcp'
WARNING: Image format was not specified for 'f-c2.elf' and probing guessed raw.
Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
qemu: could not load kernel '-gdb'

I added -raw, but all I got back with that command was a terminal prompt. I consulted my friend uelen (way-len) who knows more about QEMU than I do (something I hope to change in the future).

He shared that -s did the same thing as -gdb tcp::1234 so that was all redundant. I ended up deleting -raw as well.
I reformulated my qemu execution to end up with:
qemu-system-arm -machine raspi2 -cpu cortex-m3 -s -S -nographic -kernel f-c2.elf

And it worked!
I ran that in a terminal, and in another, I connected the trusty GDB debugger to my emulated system with target remote localhost:1234.
GDB has been a bit of a stinker since then, and I haven’t been able to debug my code because it’s been sending random addresses to the program counter and jumping to pieces of code that don’t even exist (I guess this code exists, though, must’ve come from the 4th dimension or something). I spent most of today working on it, but only got so far with hardly any leads.

Somehow my program’s first instruction, mov r0, #16, loads #12 into the link register, and random addresses are put into the program counter. I made sure that there were no addresses in r0 when the program started, so there’s no way I could somehow be moving anything into the PC or LR. I made sure it failed like that multiple times so I can accurately state that. But as David Agans says in his amazing book, Debugging, even “that” can happen, when you know it can’t.

All that to say, debugging is long and challenging, especially with things you’re not horribly familiar with yet. After spending much of my day attempting to find out gdb’s mysteries, I am retiring to my happy place, reading books and working with some Forth.

But before I leave, TIL! (Today I Learned)

TIL to really apply the concepts I learned in Debugging by David Agans, from changing one thing at a time, to keeping an audit trail, to quit thinking and just looking (I think I used that rule the most).

I learned that when you get an error for the 504th time, it’s not the end of the world.

TIL that sharing source code is really fun and really freaky at the same time, because on one end you’re thinking, “oh my goodness griefcious they’re totally going to judge my code and think I’m stupid for writing it this way instead of that way!” while on the other hand, you’re thinking “LOOK AT THIS LITTLE BABY PROGRAM I MADE ISN’T IT GREAT?” When in reality no one intensively looks at it and only tries to help figure out your problem. (those who do judge your code are either trying to help you but are unintentionally coming off as stand-offish, or they are just deciding to be turd blossoms.)

I learned that sometimes, it’s okay to pause from figuring out a problem to eat some chips and fruit while you ponder your existence and if it’s really worth it to figure this problem out.

I learned that it’s good to ask for help when you have no idea where to start looking to find out why your system emulator is being finicky (QEMU User Documentation, I’m looking at you).

And finally, TIL that making sure you recompile your altered code before running it again is a really good idea.

Until next time, folks!

Spaced Repetition Learning Systems

lá maith, good day!

Spaced Repetition Systems…what are those? SRS for short, Spaced Repetition Systems are tools to help you memorize anything you wish to have embedded in your brain for a good long while. Be it the nouns and verbs of a new language, definitions of terms from a class you are taking, mathematical equations, or the periodic table of elements, this is a great way to get started memorizing all those details.

When taking a new class and learning all of this new material, you take notes and mentally exclaim, “I am totally going to remember all this!”
Yet, three days later, you’ve forgotten most of that new knowledge (if you haven’t made an effort to retain it). While people say there’s a big learning curve to new subjects, there’s also a large forgetting curve that happens 24-36 hours after you have been presented with new information.

Spaced Repetition Systems take the efficiency of memorizing via flashcards and spread the memorization out effectively over shortened periods of time, allowing the information to seep into your brain at a non-overwhelming speed and increase the rate of retention.

I use the Leitner System, a simple implementation of the SRS concept. I wanted to get down and dirty with the project, so I built my own system out of cardboard and decked it out with washi tape when I finished, to make it look happy.


Not too shabby, eh?

It’s pretty shabby.

In case you don’t like the idea of making your own Leitner system, there is an online version by the name of Anki that works just as well.

As you can see, I marked each compartment with a “c1, c2, c3, …cN”, giving me seven mini-boxes. In a Spaced Repetition System, you start out with all your flash cards in the first compartment. Those cards you review every day. When you get a definition or concept right, you’re allowed to move that flashcard to the next compartment, where you review those card every three days. If and when you get them right again, you move those cards to the next section, where you review them every five days. If you get a concept or definition wrong, though, you have to move the card back to the previous compartment.
When you finally get to the end of the compartments and have reviewed those cards at least 5 times, they can be put into the retired deck to be reviewed once a month.

Here’s a visual:


I initially began using the Leitner System for simple definitions and words with a one sentence answer. As I began to realize its efficiency, I added more complicated subjects onto my flashcards; concepts that required me to explain them out loud like I was teaching this new idea to a five year old. This extended my ability not only to remember the concepts, but pushed me to create new ways to explain and understand what information I was conveying.

I have successfully memorized over 400 definitions, concepts, and programming instructions with the Leitner System. It only takes me, at most, five to ten minutes a day to complete. This is extremely useful when you’re venturing into a new and daunting field that requires you to remember hundreds of definitions on the spot, such as biology or engineering. The Leitner System and SRSs are an incredible tool to help learn a new language, memorize some babe’s phone number, self-teach programming concepts or terms, remember dates for history finals, teach yourself guitar chords, there are no limits. Anything can be put into this, and, if you put in enough effort, you’ll have a bunch of neat things embedded in your mind for any situation you find yourself in.

Happy learning!

thallia’s tree; a branch of knowledge

céad míle fáilte,  a hundred thousand welcomes!

I am thallia, a young and aspiring engineer. Electrical engineering and computer engineering have been my focus for almost a year now, alongside programming, mathematics, science, and a little dabble of natural medicine.

Soon I will be shipped off to college to pursue my career in electrical engineering–with that I want to further the research and technology to aid in naturopathic and other natural medical care.

The reason I chose to start a blog is due partially from influence of my mentor. I am a part of a team called Under the Wire, a small group of individuals with a passion for learning and, hopefully someday, we want to reinvent technology.

One of the concepts provided to us by our mentor is called infinity learning. A bit dramatic, I know, that’s what makes it fun. The concept of infinity learning is, ideally, where you are able to train yourself to remember the majority of anything you ever learn. A tool helpful to accomplish this is a blog.

The blogging format gives you a place to, “review, clarify, and document your experiences and learnings” (fouric, 2017). As you learn concepts, run into problems, or discover new things, a skilled way of making sure you understand it completely and correctly is to teach it to someone else; in this case, write it out and explain it to others reading the blog. When you have a limited understanding of a concept, sharing it with someone else requires you to have a fuller knowledge of whatever you’re trying to teach them, therefore pushing you to understand a concept to its full potential.

Using a blog format also gives you a copy of what you know, a frame of reference for if you forget a concept or piece of knowledge in the future.

With that in mind, this blog is where I’ll be posting things that I learn, projects that I’m working on, or problems I run into in the process of learning. I hope some of these posts will teach you a thing or two, provide you with things to think on, or serve as entertainment in general.

If you ever have any questions or comments, feel free to contact me! There’s a form you can fill out in the menu, located in the top left corner of this blog. If you want to read more about who I am and how I got interested in these subjects, you can go here!

Thank you for stopping by!