Post by thread:[PIC]: In-Circuit Debugging

Re PIC16F87X, is the "debug executive program" <--> target PIC communications interface documentation available? I'm looking for the sort of information one would need to design a simple debug tool to utilize the chip's onboard debugging capabilities. The documentation I've found indicates the debug data path is RB.6 and RB.7, but says nothing about data content, format, transmission scheme... (Apologies for previous msg w/out [PIC] preface---what a PITA 'feature' IMHO] Regards, Steve -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

The interface between the target and the ICD, and the interface between the ICD and the computer are not published by Microchip, and I doubt anyone has spent much time discovering them. Microchip, however, has released several bits of information so you can either 1) find out yourself or 2) make your own based on the chip's built in dubugging capabilities. To find out the protocols Microchip uses, you could check out the program running on the ICD chip, which is included in HEX within MPLAB distributions. Some have disassembled it, and unless your state falls under UCITA you have the right to disassemble and inspect the available code for purposes of interoperability, though tread carefully there, and remember, IANAL. To build your own, check out www.microchip.com/Download/lit/pline/picmicro/families/16f87x/51242a.pdf which goes into deail about the on-chip debugging capabilities, including breakpoints, halting the chip externally, etc. It doesn't provide code, but using that and some simple serial routines (available everywhere, search the archives or piclist) you'll be able to whip out a simple debugger in very little time. There is also code to run the Picstart plus, which may be related in some of the protocols used. I hope this helps! -Adam S Parkis wrote: {Quote hidden}>Re PIC16F87X, is the "debug executive program" <--> target PIC >communications interface documentation available? I'm looking for the >sort of information one would need to design a simple debug tool to >utilize the chip's onboard debugging capabilities. > >The documentation I've found indicates the debug data path is RB.6 and >RB.7, but says nothing about data content, format, transmission >scheme... > > >(Apologies for previous msg w/out [PIC] preface---what a PITA >'feature' IMHO] > > >Regards, > >Steve > >-- >http://www.piclist.com hint: The PICList is archived three different >ways. See http://www.piclist.com/#archives for details. > > > > > -- http://www.piclist.com hint: To leave the PICList spam_OUTpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

www.piclist.com/techref/microchip/icdhow.htm www.piclist.com/techref/piclist/listfaq.htm#topics The topic tagging has proven it self to be better to have than to not have... I know it takes effort to remember but having a wide range of discussions with 2200 of the best minds on the planet while still being able to focus on PIC technical issues is worth the 6 extra keystrokes. James Newton, PICList Admin #3 .....jamesnewtonKILLspam@spam@piclist.com 1-619-652-0593 phone http://www.piclist.com {Original Message removed}

>Re PIC16F87X, is the "debug executive program" <--> target PIC >communications interface documentation available? I'm looking for the >sort of information one would need to design a simple debug tool to >utilize the chip's onboard debugging capabilities. > >The documentation I've found indicates the debug data path is RB.6 and >RB.7, but says nothing about data content, format, transmission >scheme... read Microchip's datasheet about the ICD registers in PIC16F87X at www.microchip.com/Download/lit/pline/picmicro/families/16f87x/51242a. pdf as you can see there is nothing but additional interrupt source when the execution address match the breakpoint register value after that you have the program control, you may implement whatever you want communication via RB6 and RB7 the reason for choosing those pins is that they are used for ICSP too so your ICD can upload the debugger part easily in blank chips if you want to build your debugger compatible with MPLAB though you have to sniff their protocol between the PC and the ICD and to do the same, otherwise you are free to do whatever you want with your code which handles the interrupt Best regards Tsvetan --- PCB prototypes for $26 at http://run.to/pcb -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Hello: There are some ideas how ICD works here. I haven't proved it 'cause I don't need to. When you look at registers of PIC16F877 for instance you can see two reserved bytes at addresses 18Eh and 18Fh. Reading carefully Microchips' manual about the ICD you should notice three things. First there is one breakpoint only and it's clear the address must be saved somewhere in the RAM memory. Above mentioned bytes serve for this. There is probably a hardware mechanism (get ready when you select the "debug" bit in a configuration word) initiates an interrupt (rather a reset) when the program counter reaches the value saved in mentioned registers. Second: You are not allowed to write anything to program address 0 but NOP instruction. It suggests the reset of a processor being in a debug mode doesn't read a value saved there but anything else. May be a jump at the beginning of a small program saved to the highest memory you are not allowed to use (The thirt thing). I bet there is a very small program reading the serial communication, handle registers etc.... Don't forget you aren't allowed to use a couple of registers being in debug mode. Working for Microchip I would consider such scheme as the easiest way how to improve the developing of projects very significantly. I thank them for it. It shorts a development time of our projects very much so the cost of a ICD equipment can be forgotten. I would be glad if someone prove my thoughts and tell me if I was wrong. Regards Pokorny {Original Message removed}

Information Here: www.microchip.com/10/lit/suppdoc/specs/51242a/index.htm Niklas Wennerstrand -----Ursprungligt meddelande----- Från: pic microcontroller discussion list [PICLISTKILLspamMITVMA.MIT.EDU] För Igor Pokorny Skickat: den 16 juli 2001 23:49 Till: .....PICLISTKILLspam.....MITVMA.MIT.EDU Ämne: Re: [PIC]: In-Circuit Debugging Hello: There are some ideas how ICD works here. I haven't proved it 'cause I don't need to. When you look at registers of PIC16F877 for instance you can see two reserved bytes at addresses 18Eh and 18Fh. Reading carefully Microchips' manual about the ICD you should notice three things. First there is one breakpoint only and it's clear the address must be saved somewhere in the RAM memory. Above mentioned bytes serve for this. There is probably a hardware mechanism (get ready when you select the "debug" bit in a configuration word) initiates an interrupt (rather a reset) when the program counter reaches the value saved in mentioned registers. Second: You are not allowed to write anything to program address 0 but NOP instruction. It suggests the reset of a processor being in a debug mode doesn't read a value saved there but anything else. May be a jump at the beginning of a small program saved to the highest memory you are not allowed to use (The thirt thing). I bet there is a very small program reading the serial communication, handle registers etc.... Don't forget you aren't allowed to use a couple of registers being in debug mode. Working for Microchip I would consider such scheme as the easiest way how to improve the developing of projects very significantly. I thank them for it. It shorts a development time of our projects very much so the cost of a ICD equipment can be forgotten. I would be glad if someone prove my thoughts and tell me if I was wrong. Regards Pokorny {Original Message removed}