How to Detect Debug Mode in a PIC Micro



I’ve been posting about my progress in designing a dual motor controller that also reads and outputs RC servo pulses.  For that design I used a PIC16F1829 from Microchip.  It’s a pretty cool little part with lots of features, but also a low pin count.  I was able to get all of the functionality squeezed into my design.  But I did run short of pins and had to multiplex the debugger/programmer connections (PGD and PGC lines).

One servo input signal had to be multiplexed with the debugger/programmer clock line (PGC in the partial schematic above).  This was not too big of a deal.  The i/o pin on the controller was always going to be an input.  It would either be reading the clock from the debugger, or reading a pulse from an RC receiver).  It’s not likely people will be debugging/programming this module while reading a servo input signal.  And if they do there is a 270 ohm resistor to isolate the debugger/programmer from the servo signal.   So that shared i/o pin is safe.

I like to ensure my designs have some kind of heart-beat LED on board.  Ideally I place an LED that lights when power is applied and an LED that flashes when any onboard microcontroller is running.  These two indicators allow you to move through a troubleshooting process quickly.   Due to i/o and space limitations I was forced to have just a single LED.  I chose to use it as a communication LED connected to the PIC16F1829.  I knew that this module only functioned when a serial interface was being used, and an LED indicating communication was occurring would tell me a lot if I was troubleshooting.  I opted to blink this LED when good communication packets are received.  I make the PIC16F1829 i/o pin an output-high to light the LED, and turn it into an input to extinguish the LED.

Since I ran short of i/o pins I had to share my LED line with the debugger/programmer data line (PGD above).   To my knowledge “PGD”  is both an input and an output from Microchip’s debuggers/programmers  (reading and writing data to the microcontroller).  This means that I can’t light the LED when I’m debugging as I might be connecting two outputs together.  Similarly, I can’t light it when I’m programming the PIC part.

The programming restriction is not too much of a problem.  We won’t be programming this design while serial communication is occurring, and I only turn the PIC i/o into an output when I receive a good data packet from the serial interface.  I think programming the part is pretty safe.

So I really only needed to tackle the issue of making sure I didn’t light the LED when I was debugging.  There were two options I saw.

1.  Have two pieces of code.  One for debugging that never lights the LED.  And one for all the rest of the time that does light it.

2.  Determine programmatically when it’s okay to turn the LED i/o into an output.

During most of the development I went  the #1 route.  I had a constant defined in the program.  If it was “1” I didn’t light the LED.  If it was “0” I did light it.   But I know myself.  At some point, probably 2 years from today, I would be messing abound with source code and testing it with the wrong constant.  I’d probably blow up a couple of debuggers and waste half a day trying to figure out what the problem was.

As I was finishing up the firmware I decided to protect myself from myself, and do this programmatically.  The code below shows how to read the 2nd configuration word (16 bits) in this particular PIC controller.  The 12th bit of that word is set  (by the debugger) if the microcontroller is operating in debug mode.  So right after power up I configure the oscillator, watchdog timer, and before messing with anything else I check to see if the device is being run by a debugger.  If it is not I clear the DebugOn variable, and that tells me I can go ahead and light the LED when I receive communication.

It’s probably not a world changing code example, but since I’m always multiplexing the PGD and PGC lines, this code can help me make sure I’m doing it safely in future designs.



  1. Joe Steffy says:

    Is this code applicable to Atmel micros as well? I’m having trouble progamming an AtTiny 85 using an Arduino Uno as an ISP. I think setting the clock speed is where I’m f*****g up. I’m a total noob to micro-controllers, just ask Frank. Thanks.

  2. Hey Joe,

    It’s specific to PIC microcontrollers, and to a degree the PIC16F1829 (or similar parts). We’ve got a couple of Atmel programmers at the office though. You’re welcome to borrow one if it helps out with your project.

  3. Joe Steffy says:

    Thanks Lon, I may need to take you up on that. I went and told my boss about all the cool s**t that can be done with micro-controllers. Now he has a project. I thought no problem, use the Uno to program the AtTiny just like I’ve seen on several tutorials on the web. I can’t quite make that work. I think I’ve isolated where that problem is, I’m just not sure what to do about it but if I could borrow a progammer just to make this one project work that would get this car out of the shop for now. The other thing is, and pardon my noobness, can I control FET to act as a variable resistor? To simulate a sending unit that is 0-90 Ohms to ground?

Speak Your Mind