This may come as a surprise if your experience of embedded systems begins with “Which Linux distro should I use?” but a logic analyser can be your best friend for debugging.
I’m not knocking the big processors with gigabytes of onboard RAM and Flash, they very much have their place in the embedded world. However there are applications for which they are very much not suitable, such as time critical hardware control. As ever you should pick the right tool for the job, which is not necessarily the tool that looks flashiest and makes you a nice cup of tea in the morning.
So anyway, debugging with logic analysers. Obviously my precious little Saleae (if you don’t know what I’m talking about, ask and I will write some fulsome praise for them) is very useful for showing that I am correctly driving the I²C lines or that it’s my fault the UART input is shifted left one bit. That isn’t all it’s good for, though. If you haven’t grown up playing on small processors, it’s easy to forget that GPIOs can be used for other things than turning on LEDs.
(Don’t underestimate the LEDs, though. I usually ask for prototype PCBs to have a random LED or two on them, just so that I can get some visual feedback that my code is actually doing something before I’ve got the serial port up and running.)
Particularly early on in a project, I often find myself faced with problems that aren’t readily debugged by writing log messages to the serial port. Events may be happening more rapidly than I can log them, and in any case that will seriously perturb the system in a way that may make the problem harder to find. Waggling a GPIO takes only a few clock cycles, and gives you additional information besides.
Not sure that your interrupt routine is going off correctly? Pick an unused GPIO, attach a logic analyser to it and set it high while the interrupt routine is running. The logic analyser will even tell you just how long the ISR is running for. If you put similar instrumentation on routines you think may conflict, you can find out a lot about timing issues. Your biggest problem may be running out of spare GPIOs!
Arranging for this sort of thing to be possible is one reason why hardware and software engineers should talk to each other right from the start of a project. As I mentioned above, I usually ask for an LED or two to appease my paranoia. Our hardware team, who are very much of the same mind, do their best to bring unused pins out to test points. Apart from debugging, this has been immensely helpful on occasion when it turns out that a particular signal didn’t appear on a pin we thought it could be routed to.
When I find myself doing this often it makes less sense to use the rather nice Sensepeek probes we have (see above re fulsome praise), so I usually end up having flying leads soldered to the board instead. These can be a bit of a problem. I recommend using a bit of tape or blu-tack to stick the leads down to your desk; you only have to blow up a board once to realise how dangerous having a wire wafting around in the breeze can be. It’s also a good idea to label flying leads with what they are connected to, especially if one of them is Ground. It’s irritating to have to hunt through the board layout because you can’t remember if GPIO A was on the left or the right.
This is a supplement to hardware debugging. I do make extensive use of gdb and mspdebug together with JLink for breakpoint debugging on the actual hardware. There are pros and cons of each approach; breakpoint debugging can tell you exactly what is in those registers you are suspicious of, and exactly what the flow of control is, but it will affect timing in a way that inverting a GPIO won’t. I often find myself alternating which approach I use, letting pin waggling direct me to the code I need to step through.
None of this will be news to the old hands who have been playing around with MSP430s, STM32s, or similar devices for years. Reading through Linked-In and various forums, though, I see many people who rightly call themselves embedded engineers but who sound like they wouldn’t know what to do if presented with a PIC18. Sometimes we forget that the things that have been obvious to us for forty years might never occur to people with other backgrounds. If you are one of those people, I hope this has given you some idea of what you can do right down on the silicon.