Right. Let’s give this a go.
Okay. Well, that just works. This might
be a very short video. So, I’m sure
you’re all aware of the six stages of
debugging. It is a journey that we all
have to take at some point in our lives.
Somebody reports a bug. Our initial
reaction is denial. It must be user
error. It’s something weird they are
doing. We definitely tested our code
before we shipped it. And we definitely
tested the functionality they are
complaining about. They must be
mistaken.
The next stage is more denial. Maybe
they aren’t making it up, but we’ve
never seen the bug and we can’t recreate
it. It’s the classic it works on my
machine.
Finally, we have some acceptance. The
bug is real. We’ve managed to recreate
it, but it’s definitely not supposed to
happen. The code is not supposed to
behave in the way we are seeing. There
is something wrong with the universe.
Now we’re in the fun part. Why is the
code behaving in this way? It’s
certainly not behaving in the way we
intended. We need to do some debugging.
Hopefully, after we’ve done some
debugging, we have the moment of
revelation. The bug is laid bare and the
problem in the code is obvious.
And then we face the horrible truth. The
code is obviously completely broken. How
on earth did it ever work? Our big
challenge is getting from this stage.
Why does that happen? To the stage where
we know why it’s happening without doing
lots of work. What are our options? This
is something that anybody using the
Arduino framework will be aware of. Our
two friends, print line and print f.
This is commonly known as print f
debugging. You start to add lots of
logging to your code. It starts off
fairly tame. We have a few here one,
here two, and other things like that,
but it gets increasingly desperate.
should not be here. Why the beep are we
here? It gets increasingly frustrating
as the code just doesn’t behave in the
way you expect. And I’m sure you’ve all
written some variation of these print
statements. The other alternative is
flashing lights. We can add some LEDs to
the mix. You hook them up to some GPIO
pins and you can flash them when the
code does certain things. If you’re
really lucky, you might even have access
to a signal analyzer. These are great
and can do all sorts of clever things
like decode I squared C SPI and other
protocols. Really handy if you have one.
If you’re doing Arduino development,
then you might be thinking that’s it.
We’ve got print f debugging and we’ve
got wiggling GPIO pins. That’s all we’ve
got to work with. But there is another
way. Now I’m using my super simple dev
board that I made in a previous video.
Check out a link in the top right
somewhere. The boards were made by PCB
Way and they came out really nicely. I’m
using an ESP32S3 on these boards and one
of the very nice things about these
modules is that they have built-in
support for USB. What’s really, really
nice is that they support debugging over
USB. You can see here that they show up
as a USB JTAG serial debug unit. This is
really neat. It means that we can just
hit the debug button in the Arduino IDE
and debug our code. For people who
prefer platform IO, it also works there.
Let’s give it a proper go in the Arduino
IDE and see what’s possible. So, we’re
in the Arguino IDE. I’ve got a really
simple sketch here. We have some LEDs
hooked up to our ESP32. And I’ve just
done the fbuzz code. So, fsbuzz, if it’s
divisible by three, then it’s fizz.
Divisible by five buzz. Divisible by
both fsbuzz. So, let’s debug this code.
So, it’s really simple. We can put break
points into our code just by clicking
here in the margin. Say I’ve clicked
here now this red dot. So there’s a
break point here. Now when I start
debugging it will break on this. Now
there is a built-in breakpoint on setup.
So if I hit start debugging you’ll see
this run
and we’ve stopped in the setup code. Now
you can step over. So we can hit the
step over button and we’ll step through
the code. Or you can just hit continue.
So now we’re down at our break point in
loop. Now if we look in our variables
you can see locally we have count equals

1. Now you can also add watches. This is
   quite powerful. You can add expressions.
   So we can see here we have our if
   statements. So what I can do is add
   expressions for each of these if
   statements. So I’m going to do count
   percentage 15. You can see the value of
   that count percentage five
   and we can do count percentage three. So
   we can see which of our if statements
   should actually be true. So at the
   moment because count is one none of them
   will be true. So if we step through can
   see that none of our if statements will
   actually be hit. So we run through the
   loop and we just hit continue. Come back
   around to our break point. Now count is
   two. Obviously be quite tedious to step
   through this until one of these is met.
   So what you can do is make your break
   points conditional. So we can edit this
   break point and what we can do we can
   add an expression. So let’s just say we
   want to break when count is equal to 15.
   So let’s just do count equals 15. So now
   our break point is a conditional break
   point. So now when I hit continue the
   code will run
   until count equals 15. So now count is


2. So what should happen is we hit the
   fsbuzz um if statement. So if we just
   step through,
   we now have fsbuzz true and the fsbuzz
   LED will turn on. Now the other powerful
   things you can do, we’ve done
   conditional break points. You can just
   go in and edit values. So let’s um let’s
   change this break point so it’s no
   longer conditional. So I’ll just remove
   it and read it and we’ll run. And
   obviously count is 16. What we can do,
   we can just go in and change this value.
   Let’s put it back to 15 again. so that
   fsbuzz is still true.
   So, it’s really powerful these
   debuggers. Definitely worth having a
   play and it really helps you debug your
   code. There’s obviously some limitations
   here. If you’re doing anything real
   time, it’s going to be quite tricky. Or
   if you’re doing kind of interrupt
   handlers, you probably don’t want break
   points on your interrupt handlers, but
   for general debugging, absolutely
   fantastic. Give it a go. It works on all
   the ESP32 devices that have built-in USB
   support. So, really handy.