Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

I need a PIC16F688-ICD chip

Status
Not open for further replies.
Help me out here... The pic16f688 is a 14 pin... The AC162056 has a different chip on it Its just lableled pic16f688icd as that what is programed to debug...
In Circuit Debug needs the Reset, ICSP data and ICSP clock pins available for the debugging, so generally they aren't available to be used by the application.

On a 14 pin chip, with power and reset, there are 11 pin remaining for the application. To lose 2 of those on every single item produced just to make the developer's life easier on a handful of prototypes could be seen as wasteful.

Microchip's solution was to make the pic16f688 with basically a spare ICSP data and ICSP clock pins, plus a few others, so that an application with a DIL14 socket could take the AC162056 directly while performing In Circuit Debug, with no hardware or software changes.

That was about 15 years ago. Many products use surface mount ICs, so there's no easy way of having a debug board that can be just plugged in. If a surface mount microcontroller is used, a debug board would have to be connected with wires, so a larger microcontroller could be used for debugging, and so there's no real need for a debug version.

Just having a 14 pin DIL IC could cost a lot more in board area, height and assembly costs than having a 20 pin QFN package, so a couple of spare pins taken to test points will cost nearly nothing and will allow a few wires to be soldered on to do everything that the debug board would do.

Depending on how the microcontroller is programmed, the ICSP data and ICSP clock pins may be needed on production devices anyhow. With DIL ICs, it was practical to program each one in a ZIF socket, but that's not done so often now and ICSP is used, so those extra pads are available for debugging anyhow.

In short, there's no need for separate debug versions any more, so Microchip don't sell them.
 
If you want a 20-year-old, 20-pin pic, just buy the still-available 16f690. Same pin-out, more features.
 
I'm not looking for a 20pin pic. I'm looking for the specific debug ICD for the 16f688, not some others..
But I just received my debug header and it had that ICD 20pins chip on it, so I'm good now.
Although I will have to do some rigging to connect that debug header board to the pickit3, because they're not the same connectivity types..
 
Again, I need that particular chip (the 20pins ICD) because I already have a board with a 16F688 (14pins) to debug. There is no way to get debug to work on the 14pins 688, so it requires the header board with the ICD chip on it.
But I was afraid not to be able to find it, and it actually comes with the header board, so I'm good with that now.
The one thing I need to figure out is how I'm going to juryrigg that RJ12 connection on that header board to the ordinary 6pins header on the pickit3.
 
Is an rj12 cable a normal telephone connection where you are? If so, pick one up and chop off one end and add a 0.1" header.

Mike.
 
Unfortunately no. The phone plugs here are the huge bulky types. And there are some RJ11 types sometimes on the devices' side, not the wall plugs, but they are not RJ12, just RJ11, which may plug into each other, but aren't really the same, because the RJ11 only have 1 or 2 pairs, whereas the RJ12 has 3 pairs.
I already went through a bunch of my old junk, looking for old phones, and found several, with a few having RJ11 plugs, but none have 3 pairs, so no use.
There is no local RadioShack or whatever here, so no place to check for parts around here..
 
Can you solder wires onto the RJ12 connector to connect to your PicKit3?

Mike.
 
Since I couldn't find anything useful to plug into that RJ12 thing, I'm now considering just desoldering that thing from its board, and then just put wires there. Not sure yet what I'll use at the other end to plug into the pickit3..
 
Learn how to debug the "old school" way...Turning on/off LED's and sending data through a serial connection.
Yeah like that used to easy.... The new ICD board should do the old pic16f688 chips... You need to read the addendum...
 
Those adapters are expensive, even that simple one. I've already burned quite enough on those things, so I'm just rigging something.
I couldn't get that RJ12 connector off that header board, because I don't have a decent desoldering tool and I don't want to damage it, but I managed to solder a set of wires to the solder side on that board's connector, and then I used a small breadboard to plug those wires in and that allows plugging the pickit3 there too, which is doing the job of the adapter. Not perfect for sure, but it worked, as I'm now able to run debugging.
Still some things to figure out with that debugging stuff, such as how to display a variable's contents for example. Not the SFRs, but one of my own defined variable in the code. For now, since I couldn't figure that out, I just display directly by physical address, which works, but it's half ass and there has to be a way to display a variable's contents by stating its name, not its real address.

So this at least proves one thing: with that ac162056 header board, which does indeed come with that IDC 20pins chip on it, we can actually get debugging running using the pickit3, so no need for that other more expensive gizmo ICD2 or others..
 
Still some things to figure out with that debugging stuff, such as how to display a variable's contents for example. Not the SFRs, but one of my own defined variable in the code.
That's dependent on what you use to develop code, and which IDE you're using (MPLAB vs MPLABX).
Your tools need to create a COFF or ELF file with symbolic debugging info.
 
I'm running mplabx v5.3, with mpasm. I had to downgrade to v5.3 when I found out they had nuked mpasm from it, so that also means I will stick with that version, not upgrading it, since they certainly won't do anything to bring mpasm back.
I have no idea about those coff or elf. Never heard of it and haven't come across anything about that in what I've been reading.
So, more stuff to discover now..
 
I'm sure someone here uses mplabx for assembly. Hopefully they'll see this and explain how.

Mike.
 
The assembler included with XC8 (pic-as or aspic, depending on the version) is not the same as mpasm, and brings along a whole new set of issues.
The two aren't compatible.

If you're using mpasm, try reading this thread on the microchip forum for some hints on debugging with mplabx and mpasm:
https://www.microchip.com/forums/m667427.aspx
 
When I first tried programming this PIC, not having ever done any of this before, I knew nothing about it, and I had installed the latest mplabx version, and the only assembler I could find was that oddball pic-as thingy, which is wierd and not friendly at all.
Not that mpasm is any friendlier, but at least mpasm is more "like" other "real" assemblers, while I feel like pic-as feels more like a C compiler.
Anyway, I wrote some code with pic-as, and never could get anything right. Never got a full assembly going, always lots of errors that I just couldn't fix.
I gave up on pic-as and found out I had to downgrade one version of mplabx to regain the use of mpasm, which was nuked in the latest incarnation.
Once I reworked everything under mpasm, after a few errors corrected and proper syntax applied, I finally got a full assembly done and programmed the pic with pickit3, and my code ran, although not exactly as expected, but it ran. So that was my functional software/hardware stack.
Now added in that tool chain, is that ICD header, which I got running fine now, debugging via pickit3.
I see sometimes some error/warning messages about XC8 licensing issues, which I don't want to deal with.
I have been debugging lately, and tweaked a few details that debugging revealed, but I'm still stuck on how to set up those "watches" for the defined variables as I mentioned.
For now, to keep going, I managed to fake it by doing the watch on a specified real absolute address, but that should be done by name, so how do I do that?
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top