Debugging Embedded Systems With GDB?

can use a standard debugger like gdb on embedded systems let's find out [Music] hey folks welcome back i hope you're doing well welcome back to another embedded systems video i recently posted a video about embedded c and embedded c plus plus and how they are and are not different from normal c and c plus check out that video if you missed it but after that video a lot of you expressed some interest in hearing more about debugging embedded systems and that's a pretty massive topic but i thought i would scratch the service today and talk about a little trick that is super helpful and a lot of people who are new to embedded systems just simply don't know about because it's funny a lot of people when they get into embedded systems it's like they forget all the debugging that they ever learned and they immediately go back to print style debugging basically what they did when they were a freshman in college just getting started and they just start polluting their code with print statements everywhere sending that data over a serial connection usb cable a uart something like that and sometimes you may be able to get by with that but you know on your laptop's desktops and servers just how terrible print style debugging can be and so why would it be any different in our embedded code so if you get nothing else from this video basically the message of this video is before you start down that path you always no matter what platform you're working on you want to take a step back and see what tools are available to you because you might be able to use a real debugger on your code even if you're working on a microcontroller and today i want to show you a quick example of how that can work now before we jump into code i just want to say that as usual all source code for this video and other videos is available through patreon a huge thanks for all of you that support the channel and keep this channel running also i know we all say this but consider giving this video a like if you're enjoying it it really does make a big difference in how the algorithm spreads the word about this channel but all that aside let's jump into it so today i'm working with this msp430fr5994 this is simply just a board that i had on my desk it's one that i use in my lab a lot for a lot of different research projects and so i thought it would be good for today's example right now i've just got it connected over this usb cable to my laptop this uh board that you're looking at of course has more than just the microcontroller on it this is a launchpad which is basically just a development board provided by ti and of course what i'm about to show you works on these launch pads but it could also work on just about any custom device you make now another thing i want to point out about this device is it has two sections so you can see there's sort of this side and this side this side is here really for debugging and testing and programming um this other side is the device itself this is the microcontroller and some of the stuff that's plugged into it and i also want to point out that these jumpers right here these basically allow you to electrically separate these two components so if i have some kind of device that i've developed that isn't this like it's some other msp430 device maybe it's a sensor maybe it's a little robot or whatever i can actually pull these off and i can use this programmer debugger side over here and actually use it on some other device and maybe we'll do that in a future video but i just wanted to point that out in case it's helpful information now as far as code today i'm going to use the adc code right here from my previous adc video that i posted a while back now i could use just about any embedded msp430 program for this example if any of this confuses you please check out that video and my other embedded videos they'll get you up to speed but let's just say we've got a program this one will do for today now this is a simple program that just measures some adc value but let's say that i have a problem with this program i want to debug it it has some issue and i don't really want to start polluting my code with prints so what can i do and it's important to keep in mind that the answer will vary for each different microcontroller that you work with but for this msp430 i have a few different options now the first thing that i'm going to use and you'll remember this from before is msp debug now this is a great program created by daniel bier props to daniel thank you for making this publicly available and for free and you've seen it before on this channel because i've used it to put new code on my microcontroller and it also has a lot of other debugging capabilities so if you look down here you can see let me just expand this a little bit you can come down i mean lots of different options i'm going to kind of skip through those and different drivers different ways that you can connect to these devices but if we come down here you can see there's a bunch of different commands okay so these include things like being able to read and write memory on the microcontroller it can start and stop execution it can gather power statistics somewhere down here i think yeah so there's a bunch of power stuff but the command that i want to focus on today is this one is it can actually help us use gdb on this device and this is going to keep things familiar so we're going to focus on this gdb command today so let's see how this works so first off i just want to look at my rig file really quick this is the rake file i used before nothing special i could use a make file uh just before we get started let's come in here and just make sure we've already compiled and and let's just install the code make sure to put some new code on this device so that i know that i'm working with the latest code notice that i use msp debug in the rank file to actually do this process now before we get too far let's just take a look at a few different things in our rake file here because our compile flags up here are going to be important we need to make sure that we generate a program that msp debug and gdb are going to be able to use now normally when we're using gdb on our local machines typically we just need dash g and that's enough but here we're going to be a little more explicit so there's a few things i just want to point out the first thing that i add here is this o0 that's just turning off optimizations you can turn on optimizations but as always you're going to find that debugging is a little more complicated because the code you wrote and the code that you're actually running may not be the same i'm going to use dash g3 here that's just basically it's like dash g but it basically brings me up to debugging level 3 turns on all the debugging information and then i'm going to use the gdb that specifically generates gdb style debug information and i'm going to tell it to use dwarf ii style debug information okay this is just this is what's expected by gdb for the msp 430 and so this is going to be important also while we're here note that i'm actually using c plus plus here even though i'm not really using classes or templates or any of the c plus fancy features and for this example it doesn't really matter we could use the c compiler as well just for today's example it just shouldn't make a difference but this is what i'm using and i often do because it makes it easy if i ever do want to decide to use classes or something that is c plus plus only then i can usually just add those in now what i'm about to do here you can do in one terminal you notice i've created two and and that's for easy illustration because there's a few different moving parts that we're going to look at so the first one let's come up to here the first thing i'm going to do is we're going to start msp debug so here i'm going to just say msp debug ti lib that's the driver we're using and then i'm going to run the gdp command now when i run this you'll notice that it connects with the msp430 and then it just sits there listening on port 2000 and that's where gdb is going to connect so at this point it's just waiting it's just waiting for us to tell it what to do it says okay i'm in gdb mode i'm ready to work and so then to make it work we're going to jump over into our other terminal and now we actually run gdb and we're going to do that like this msp430l gdb just to make sure we're running the version of gdb that's designed for my msp430 and let's give it the name of our binary mine is adc.elf yours will be whatever you name it so when i run this this basically is going to startup gdb we're used to seeing this assuming you've seen gdb before it's going to load the symbols from our binary you can see that happening right down here but we're still not connected to our microcontroller so to do this we need another command we basically just tell it we want the target the device that we're actually debugging to be a remote device and we connect on localhost 2000. okay so as soon as i run this command now this is going to say gdb please connect to localhost on port 2000 and now we're in business so now if we look over here to our other window you can see that sure enough a client has connected so that's that connection is in place and we cleared our break points and we're reading registers and then here on the gdb side you notice that it's ready to debug and it's currently at underscore underscore crt 0 underscore start okay which i believe is the start routine for the c runtime i haven't actually dug into it but i believe that's what we're looking at here and this is what's eventually going to call my main function and now at this point things go pretty much like we would expect them to do if we were debugging locally we can set a breakpoint in main and you know say i'm interested in some line let's look over at our code here let's say that i'm interested in what's going on here at line 57 i can also just come down and break 57 so we can set a breakpoint there that's really straightforward one difference is that if we were debugging locally we would normally use the run command but that's not going to work here because our code's already running the device has already started we're basically already stopped in it and so instead we're going to use the continue command or c and then that's going to land me at main if i run it again it's going to land me at that line 57 so you can see i'm stopping at my breakpoints it's showing me what code i'm on and at this point i can do things like print out the value of a variable this one's not initialized it's just been it's here but it's so whatever value it is who knows but i can then step over the line 57 and now let's print it out again so you can see okay now the adc value that it actually got what in millivolts was 365 millivolts so okay so that's cool and you can it's not currently connected to anything so again this is still pretty meaningless but if it was connected to something like a sensor then that would tell us something about the sensor value now this all feels very familiar not every microcontroller supports everything that your laptop processor does like you might not have hardware support for watch points for example and i've definitely run into situations where i was stepping through the code and gdb got confused either by an interrupt firing or something else so that's something just to be aware of but this works pretty well and once we're done i can just basically quit here and you notice that it quits both okay so my msp debug session realizes that the client is connected and so it just closes out and disconnects from my device okay now i know at this point you're probably looking at this saying ah there's there are more moving pieces here than i'm used to using when using gdb and so let me show you how we can make this a little more convenient because we can script all this so that we don't have to type it over and over again because that's a lot of typing and we're programmers we don't like to type so let's do that really quickly let's jump back into our rake file and let's just add a task that's going to help us it's going to make things a little more convenient so what i'm going to do let's come here and let's just make a new task i'm going to call it gdb and what i'm going to do here is basically just run all of these different pieces in one shell command so we're going to use the sh command that just does this so let's start off by just running msp debug hopefully it won't mess this up let's run the gdb command notice i'm escaping the quotes because otherwise it'll think that i'm ending my command we're going to put an ambersand here that's basically going to start up the msp debug part in a separate process and have it run in the background and then once that's all set up then i'm going to run msp430f gdb i'm going to add dash q because i don't want to see that text to the front all the time so this is quiet mode just something that might be useful for any of you gdb enthusiasts that may not have seen that before let's give it the name of our compiled binary and then i'm also going to specify that i want a certain command to run every time we run and that's going to be target remote localhost 2000 and yeah so that should be our command so that's basically going to set up our msp debug in the background it's going to run gdb in quiet mode with our binary and it's going to run our command and if i got this all right we should be able to just run rake gdb now and it should basically start everything up and get us into position where we can start debugging of course it took a second to get all connected but once it is we're good to go so that's not too bad it took a little bit of project setup you know we we had to set this task up in our rig file but it's not too bad obviously this is going to be a bit different on different microcontrollers if you're on an avr if you're on some kind of arm microcontroller you may have a slightly different set of tools and a slightly different setup but this type of debugging is available on most microcontrollers that you're going to run into especially those that are commonly used and this approach to debugging is definitely not perfect it's not always going to be suitable i mean there are going to be times let's say that i'm debugging a sensor that's built into a pair of shoes and there's a bug that only happens when someone's actually running in that pair of shoes that's not going to be a situation where i can just plug a usb cable into it and say run msp debug on this thing that's not going to work but in a lot of cases it is going to work and this is a super easy way that you can just debug a program and it's a way that a lot of new embedded systems folks aren't aware of it's often overlooked so to me this is the first place you look this is the first thing you try when you're trying to debug a tricky situation in an embedded system so i hope this is helpful let me know down in the comments if you have other embedded questions debugging questions or just any other programming question that you'd like to see me address in a future video drop the video a like if you liked it subscribe if you don't want to miss the future videos that are going to totally change your life and until next week i'll see you later

Channel: Jacob Sorber

Views: 43,831

Keywords:

Id: m4agpY_w2y8

Length: 13min 51sec (831 seconds)

Published: Tue Aug 17 2021