PIC16F688: debug possible? PicKit 2 vs PicKit 3 vs MPLAB ICD 3

[Gordito]

Hi, i am planning to use a PIC16F688 for a project. I am also looking into getting a programmer + debugger for it. I am new to the PICs and somewhat confused about a few things i've read:

1) Do i really need to use a PIC16F688-ICD version pic in order to be able to do in-circuit-debugging, or is there a way i can use the production version pic?

The PIC16F688 is classified under the 'required header' section in the header spec document. The section has the following notice which seems to say i need to find the -ICD version:

Some devices have no built-in debug circuitry. Therefore, special ICE/ICD versions of
these devices are required for debug tool operation.
Currently available headers and their associated ICE/ICD devices are shown below by
supported device.

Mouser doesn't have the -ICD equivalent, a bummer since i was going to buy everything there...

2) What are the major differences between MPLAB 3 and PicKit 2 or 3? There is a big price difference and i fail to see the differences, especially debug wise. In which case would MPLAB ICD 3 be better than one of the PicKits?

3) I've read that picKit 2, but not PicKit 3, has a logic analyzer (4 or 5 lines i believe).
Is this usable for any digital logic projet, even those who don't have pics? This is a nice bonus feature if it's possible...

Thanks for your time.

 

[Wp100]

Hi,

You raise a lot of poins that could take pages to explain fully / are detailed in other previous posts.

Assuming you are a normal hobby user then a genuine Microchip PK2 is still the best one to get. Pk3 is a lot more expensive and still being developed and dos not offer the hobby user much advantage.

As you have seen, the debug function is inbuilt to some chips but not all.
There is not two versions of the same chip ie one with debugger and one without, so rather than mess around with debugger header adapters and all the extra plugs and wires etc simply select a similar chip that does have debugger built in.
Just use the parametric search on Microchips chip selector or if you are not sure come back and say what key features your chip must have.

Hardware debugger as its better called is intended for you to run your final program in you target circiut and test for any previously missed bugs.

The free software MPLAB contains a software simulator that can do many similar functions and is normally the first line of testing, Mplab also has facilities for using other more complex third party simulators like Proteus.

 

[3v0]

I love Mouser and buy most of my parts from them. But for microchip products check out Newark. They are significantly less expensive.

The diff on a few PICs is enough to pay the extra shipping.

 

[Pommie]

When I have had this problem in the past I have used a larger chip that has debug facilities and use #ifdef to choose between incompatible code. Doing this allows you to fully debug your code and then change the device to get the final hex file.

A good chip to "emulate" the 688 would be the 16F88.

What language are you using?
This is the start of an asm file that used this technique.

	#ifdef	__16F88
		include	"p16f88.inc"
	#endif
	#ifdef	__16F876A
		include	"p16f876A.inc"
TMR0IE	equ	T0IE
TMR0IF	equ	T0IF
	#endif

#define XON		0x11
#define XOFF		0x13



		errorlevel	-302
		radix	dec

	#ifdef	__16F88
	__config  _CONFIG1, _CP_OFF & _CCP1_RB0 & _DEBUG_ON & _WRT_PROTECT_OFF & _CPD_OFF & _LVP_OFF & _BODEN_OFF & _MCLR_OFF & _PWRTE_ON & _WDT_OFF & _INTRC_IO
	__config  _CONFIG2, _IESO_OFF & _FCMEN_OFF
	endif

	#ifdef	__16F876A
	__CONFIG _CP_OFF & _DEBUG_ON & _WDT_OFF & _BODEN_OFF & _PWRTE_ON & _HS_OSC & _WRT_OFF & _LVP_OFF & _CPD_OFF
	endif

This was because I needed to use the timer1 oscillator and on the 16F88 it shares the debug pins.

Mike.

 

[Gordito]

Thank you all for your replies. I researched some more and also clarified my confusion about -ICD devices: they are on the ICD headers and they are the only source for them.

I've decided to go with pickit 2. As far i can tell, the only difference between the buying the programmer by itself vs debug express or starter kit is the lack of dev board? I'm also deciding if i shouldn't just drop the F687 and go for the F88. I'll recheck the specs.

When I have had this problem in the past I have used a larger chip that has debug facilities and use #ifdef to choose between incompatible code. Doing this allows you to fully debug your code and then change the device to get the final hex file.

I am curious to know how you deal with the different pinouts... what is your production pineline like, do you program and test the F88 on a prototype broadboard and only load the program in the F688 when you get to the pcb stage? Do you do ICSP?

What language are you using?
This is the start of an asm file that used this technique.

I know C and used to do ASM. Thanks for the code. I'll research later which language is better suited for my project (convert unknown protocol on RS-422 to proper ascii RS-232) and is available with F688 and mplab ide. I believe it is possible to do C but i'll have to check.

This was because I needed to use the timer1 oscillator and on the 16F88 it shares the debug pins.

Pardon my ignorance, what was because you needed to use the timer? I don't understand what this refers to and i'm sure it's helpful

 

[Pommie]

The way I deal with different pinouts is to label all pins. I.E.

	#ifdef	__16F88
#define	LED PORTA,0
#define Sw1 PORTA,1
	#endif

	#ifdef	__16F688
#define LED PORTC,0
#define Sw1 PORTA,0
	#endif

So the processor currently selected will define what is on which pin.

By doing it this way you can leave the ICSP pins free to do debugging/programming.

I would build a prototype with the bigger chip to develop/debug on and occasionally program the real target chip and try it in the real hardware.

If you need to use the external Timer1 oscillator then you can't use the 16F88 as it (the osc) shares the debug pins. Edit, I needed timer1 as a Real Time Clock.

Changing your design to use the 18F88 would probably be the simplest solution.

Mike.

 

[Gordito]

Oh ok i get it now, your statement referred to using F876A instead of the F88 because of the shared clock/PGC on the F88. I misread the code and thought it was regarding swapping the F688 for an F88.

I would build a prototype with the bigger chip to develop/debug on and occasionally program the real target chip and try it in the real hardware.

If i understand correctly, using that example you have two different trace layouts depending on the chip. One breadboard or pcb to test (F876A), and a final one with no debug/ICSP (for the F88). And i suppose you 'occasionally program the real target chip' on the breadboard or prototype pcb if the pin-out of used pins is the same?

Supposing i need to external clock and want to work with only one layout, i could make my own 20 pin ICSP header socket to route the F876A pins to the functionally corresponding pins of an on-board F88 socket. Then i use the F88 directly in the onbard socket when i'm done debugging. This seems like a good idea?

In any case if don't need the external clock i'll just use the F88 instead of F88 + F688.

Thanks again for the help, this thread has clarified many things.

 

[Gordito]

Recap

Ok just to close the subject, now that i had a PICKIT 2 for a week i'll put my observations here for the benefit of others:

1) To know if a pic can be debugged in mplab without the special (expensive) idc header board , verify that it is in the right column of the supported device list and DOESN'T have an asterisk after it (see link) . Notice that some are noted partially, ex: 'PIC16F87, 88' so search carefully. The debug config flag is also noted in the datasheet's device overview section.
**broken link removed**

2) I am happily debugging my code, which means for the Pickit 2 that i have one breakpoint and mouseovers over variables give me their values. There doesn't seem to be any kind of multi variable displays. I haven't seen the 'Step Out' activated yet even after using step into to go into a called subroutine. Might be normal, i'm new to pickit 2.

Also, it took me some time to jury-rig a icsp connector with what i had on hand. I tried IDT connectors but gave up for the moment and soldered on sawn dip sockets. Think about what you will use (2.54 mm, square pins on the pickit 2 side, use single row connector x 6). Or just buy the icsp cable (half the price of the whole pickit unit!)

For my needs, the pickit 2 programmer is really worth it, especially for the price. It is worth it to get a PIC with the debug flag, no required header and enough functions and free IO pins for your needs (ex: PIC16F88)

3) I resolved the various, numerous and constant 'device not found' errors:
(Pardon the list but you might recognize your symptoms) :
pickit not found, usb device not recognized (windows!). Also the unit would hang or crash after a few writes (Leds indicating 'BUSY' when target circuit is unplugged and apps closed). Sometimes write+verify would seem fine but immediately verifying after this would say there is a change. Sometimes in pickit 2 app, after a crash, even after unplugging the usb and rebooting, it would say there is no OS in the unit, or need to update the firmware. Replugging the usb after reboot didn't always work with windows refusing to recognize the device

What i did to fix this (now i debug and hardly ever crashes)

a) Use the shortest USB to Pickit cable. I used the one from my camera about 5" long. I believe this fixed everything...

b) I gave my circuit using it's own power source and isolated the ICSP connections.

c) User errors: When switching to PICKIT 2 app from MPLAB, don<t forget to put the mplab debugger or programmer to 'none'. When using the uart and logic tools pay attention to replacing the proper connections for programming.

d) When i used the cable that pickit 2 came with i had problems to the point of the unit being unusable but a workaround required unplugging the usb and letting the unit sit for about 5 minutes... no less, more was better. Then windows would recognize it. So i don't know, might be some residual voltage somewhere when the unit crashes or hangs, preventing it's proper detection.

4) Useful docs:
PICmicro Mid-Range MCU Family Reference Manual.pdf
MPASM-MPLINK User's Guide.pdf
Nigel's tutorials

Good luck!

 

[3v0]

For a multi variable display look into the local and watch windows.

Some of the newer PICs (maybe only in the 18F line) allow 3 breakpoints. They often have PLL's that can be used to increase the processor speed by 4x. Many can be had in DIP packages.

Step out does not work with a pickit2. But it does with the simulator. Maybe ICD3.

 

[Gordito]

Thanks for the info.
Unfortunately it appears that locals and watch windows are only for higher level languages so i don't have access at the moment (doing ASM).

 

[3v0]

Chuckle. They invented compilers for a reason

 

[Wp100]

Hi,

Unfortunately it appears that locals and watch windows are only for higher level languages so i don't have access at the moment (doing ASM).

Locals may be for C only, but the Watch window is available in Sim and Debugger with Assembler.

Nothing wrong with Assembler, you learn at lot about the detailed workings of the Pic chips this way and that knowledge will be of use if you move onto C.

As 3V0 mentioned, many of the 18F chips , typically the 2520 and 4520 have 3 breakpoints and are so much easlier to use with their large ram areas, 384 bytes available before you need to change Banks plus no Page boundaries in program memory to worry about when you have large programs.

 

[Gordito]

Oops i just realized i missed that "view" menu when i had a quick look at the ide!...

My next pic shopping run will certainly pay more attention to the debug features. Where can i find a comparative list of the pic's various debug features, without having to look at all the datasheets? Ex: Number of breakpoints, icd header required, other functions on the same pins as PGD / PGC?

Regarding the pickit2, i've used both the UART and logic/analyzer tool and very satisfied. Lots of stuff in that little programmer!

My project requires a serial port UART so i had to make one anyhow but i now use it to send debug messages from the pic to window's hyperterminal via a 2(!) wire RS232 connection (i have no db9 cables just headers). It's not much work and worth it for extending feedback from the PIC. It frees up the UART tool so you can have a logic probe or logic analyzer.

 

[3v0]

About the only debug issue is if it has ICD at all and how many breakpoints. Mostly only the bottom end chips lack ICD.

For the number of breakpoints you have to check the datsheet. I would expect 3 on newer chips with more memory. Not sure.