Ok, I'll go through it with you: >From 51553E.pdf: "4.4.2 Reserved Resources Due to the built-in in-circuit debugging capability of ICD devices and the ICSP function offered by the debugger, the PICkit 2 Debug Express uses some on-chip resources when debugging. It also uses program memory and file register locations in the target device during debugging. These locations are not available for use by user code. In MPLAB IDE, registers marked with an "R" in register displays represent reserved registers. For information on device resources that are needed for in-circuit debugging, please refer to the MPLAB ICD 2 Help, found in the MPLAB IDE under Help>Topics. The device reserved resource information found under "Resources Used By MPLAB ICD 2 "is the same for the PICkit 2 Debug Express.= " I'm not using any of the registers marked R in the register list. I don't find the ICD2 Help file at the Microchip site, but since a PICListe= r (not sure if he wants to be ID'd) is kindly sending us his unused ICD2, I'm installing the ICD2 support option into MPLAB here. Reading through the Limitations section, the first thing I see that is applicable is: "ICD/ICE devices must be clocked (internally on INTOSC or externally on OSC1) and have MCLR high to communicate with the debug tool." In my code: __CONFIG (UNPROTECT // & BORDIS //brown out reset disabled (default enabled= ) & MCLRDIS //master clear reset on pin 3 disabled (default enabled) // & PWRTEN //power up timer enabled (default disabled) & WDTDIS //watch dog timer disabled (default enabled= ) & INTIO //internal osc, GP4,5 are IO (default RCCLK= ) ); Moving on to the specific device limitations, my comments in <> PIC12F629/675 Limitations Headers are required for debug when using these devices. See the "Header Board Specification" for details. Header limitations are as follows: General Debug Limitations General Programming Limitations You cannot single step through an interrupt Due to hardware restrictions the emulator cannot jump to the interrupt vector memory location in single step or animate mode. Cannot erase ID memory at Vdd < 4.5v At Vdd < 4.5v, the part cannot be bulk erased, so it has to be row erased. Row erase can be used on program memory, but not on configuration memory (where user ID resides.) Program Memory standard flash Program memory not enhanced flash. You cannot program in low voltage mode (Vdd<4.5V.) See device programming specification for more information. RBIF is cleared when PORT is interrogated by software, except when Freeze o= n Halt is enabled. This header cannot be programmed while the GP1/RA1 pin is high (VIH) due to an -ICD debug silicon issue. There are two work arounds: (1) Move the circuitry that makes GP1/RA1 high to another I/O pin during programming. (2) Manually make GP1/RA1 low during programming (for debuggers that can supply power to the target): Disconnect the header from the target circuit. Select Debugger>Settings, Power tab, and check "Power target circuit from ...." if it is not already checked. Connect GP1 to Vss on the header. Program the header by selecting Debugger>Program. Disconnect GP1 from Vss on the header. If you were NOT using a debug tool to power your target board, select Debugger>Settings, Power tab, and uncheck "Power target circuit from ...". Insert the header into the target board. Code is now programmed into the device and ready to be debugged. Repeat the process to reprogram the device. Freeze on Halt Limitations Timer0 will not freeze using the internal clock. CMOUTx Pins do not freeze, status bits and interrupt flags do freeze. RBIF is cleared when PORT is interrogated by software, except when Freeze o= n Halt is enabled. So, yes, I have complied with all of that, and it still doesn't work. #fail Microchip# I have a debug header for the 16F690 on the way and will be curious if the PICKit2 will work in debug mode with that chip. And the nice donation of an ICD2 will hopefully allow me to play with the 12F675 more cleanly again as well. -- James Newton 1-970-462-7764 -----Original Message----- From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf Of Funny NYPD Sent: Saturday, November 20, 2010 05:48 To: Microcontroller discussion list - Public. Subject: Re: [PIC] pickit2 unreliable debug 12F675 I am not sure you have read the chapter 4.4 "Using PICKit 2 debug express" on "PICkit 2 user guide 51553E.pdf", which is available at the standalone PICkit 2 program (a PC software not included in MPLAB), click "Help->PIckit 2 user's guide". There are also "reserved resources", if those MCU resource is used by your application, it will lead to errors or simply malfunction on debugging. Funny N. Au Group Electronics, http://www.AuElectronics.com http://www.AuElectronics.com/products http://augroups.blogspot.com/ ________________________________ From: James Newton To: Microcontroller discussion list - Public. Sent: Fri, November 19, 2010 11:36:17 PM Subject: RE: [PIC] pickit2 unreliable debug 12F675 Thanks much Dwayne, and everyone else who has replied to this. I verified the limitations, and found that the MCLR function must be disabled from the external pin for the debugger to work at all. I don't have the ICD2 help file installed (since I don't have an ICD 2) and the PICKit 2 help file doesn't list a Limitations topic group. I probably wasn't being clear... even with NO external circuitry attached, just the PICKit2, the RJ11 adapter, and the 12F675 debugging header (all stop) I still can't step the chip. I can program it, I can run it (and verify that it is running "Hello World" with a meter on GPIO2 pin), and it will try to debug, but either run away ignoring the break point, or repeatedly step without being commanded to do so (which locks MPLAB up). I've tried bypass caps on the power pins, pulling MCLR high with a resistor= , and a million other things. I have the later PICKit 2 with the red button, so it doesn't need the pull ups on the data pins, but I tried that anyway, etc... It just doesn't work. I considered buying a PICKit 3 out of pocket just to see if it would work, but I think, based on your experience and the comments of others, that I will wait and try to save my pennies for an ICD2 or ICD3. Why is the 2 more expensive than the 3? Anyway, I was able to get the immediate job done without the debug function= .. It was fun playing hi-low with a single PIC pin to find the mid point of th= e A2D reading on the POT... long story. Thanks again. -- James Newton 1-970-462-7764 -----Original Message----- From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf Of Dwayne Reid Sent: Wednesday, November 17, 2010 09:41 To: Microcontroller discussion list - Public. Subject: RE: [PIC] pickit2 unreliable debug 12F675 At 08:26 PM 11/16/2010, James Newton wrote: >I would really love to see someone from Microchip demonstrate debugging of a >12F675 with the PICKit2... In front of a lawyer ready to file a class action >lawsuit for advertizing something that obviously doesn't work. Hi there, James. I've stayed out of this thread because I haven't used the PK2 for debug. However, I HAVE used the ICD2 to successfully debug many projects and the PK2 should be almost identical. You need to pay particular attention to the limitations for debugging the 12f675 that are shown when you bring up the help feature in MPLAB. There are a couple of things that will bite you because they are non-obvious. Even the obvious limitations keep getting me because I forget them between projects. You can read about the limitations by clicking Help -> Topics -> Debuggers -> MPLAB ICD2 and clicking OK. Expand the Limitations topic group and select "8-Bit Device Limitations - PIC10F/12F/16F", then selecting "PIC12F629/675 Limitations". However, here are the three most important ones: 1) Can't use the internal watchdog. Turn it off in the chip's configuration. 2) GPIO3 is normally switchable between !MCLR or an input. If you are using the debug header, it MUST be configured as !MCLR and must be HI in order for the chip to work. 3) GPIO1 must be LOW when in order to send the program into the chip's flash memory. This one gets me often. The above are the main items to look out for. Good luck! dwayne -- Dwayne Reid Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax www.trinity-electronics.com Custom Electronics Design and Manufacturing -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .