Searching \ for '[PIC] pickit2 unreliable debug 12F675' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'pickit2 unreliable debug 12F675'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] pickit2 unreliable debug 12F675'
2010\11\16@010022 by James Newton

face picon face
Anyone used a PICKit2 to debug a 12F675?

I've got the right adapters, etc... but the thing skips past the breakpoint,
will go off single stepping on it's own after the C setup code and stop
responding, etc...

Just crazy.

Nothing at all plugged into the chip. Configured for internal osc, no wdt,
etc... Just PC -> USB -> PICKit2 -> RJ11 adapter, phone cord, to the little
debugging adapter with the special ICD chip.

Getting ready to regret having agreed to help with this project... I thought
TI's stuff was full of gremlins... wow...
--
James Newton
1-970-462-7764

2010\11\16@030145 by Nicola Perotto

picon face


On 16/11/2010 6.00, James Newton wrote:
> Anyone used a PICKit2 to debug a 12F675?
I tried but not worked. Problems like yours.
Connected ICD2 and worked perfectly without other modifications.
Maybe PICkit2 bug/limit

2010\11\16@091602 by Olin Lathrop

face picon face
James Newton wrote:
> Anyone used a PICKit2 to debug a 12F675?

As I said before, ask yourself whether you really need this.  The simulator
is a much nicer debugger than the PICKit2 as long as you can simulate the
inputs well enough.  What inputs does this chip receive?

Seriously, you might get your project running quicker if you ditched the
PICKit2 and spent the time instead setting up simulation of whatever inputs
you need.  On such a simple chip, manually changing a input pin or feeding a
value into the A/D might be good enough.  I've done this a bunch of times.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\11\16@095933 by jim

flavicon
face

James,

I would tend to agree with Olin here in this case.  I too have used the
simulator to debug and develop code  for various projects.  I have a PICKIT 2 as well as an ICD2, but I use
the simulator most of the time.   I seldom use the hardware mentioned above.  When I simulate the code I
have written, I usually use the
manual pin stimulation mode and select the toggle function for inputs. YMMV.  It depends on what you want
to test and how closely you can match the simulator inputs with actual
inputs that will ultimately be  used in the actual product.  But for simplicity and expediency, in my
book, the simulator can't be beat.

Regards,

Jim

> ---{Original Message removed}

2010\11\16@101839 by Oli Glaser

flavicon
face
On 16/11/2010 06:00, James Newton wrote:
> Anyone used a PICKit2 to debug a 12F675?
>
>

I've never been too keen on the PicKit2s debugging capabilities.
I would either use the simulator or my ICD3.
I know it's a pain to decide on a course of action and then have to rethink, but I reckon you might save yourself a lot more frustration here.

2010\11\16@111455 by Matt Bennett

flavicon
face
On Tue, November 16, 2010 12:00 am, James Newton wrote:
> Anyone used a PICKit2 to debug a 12F675?
>
> I've got the right adapters, etc... but the thing skips past the
> breakpoint,
> will go off single stepping on it's own after the C setup code and stop
> responding, etc...
>
> Just crazy.
>
> Nothing at all plugged into the chip. Configured for internal osc, no wdt,
> etc... Just PC -> USB -> PICKit2 -> RJ11 adapter, phone cord, to the
> little
> debugging adapter with the special ICD chip.

This may sound a little obvious to some, but you didn't mention it, so I
figured I ought to ask- do you have a decoupling capacitor on the part?

Matt


The views I express are my own, not that of my employer, a large
multinational corporation that you are familiar with

2010\11\16@222638 by James Newton

face picon face
Great idea Matt... I actually didn't have any... that made it worse... words
can not express my frustration at this point.

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.

Look... I like debuggers... I don't like simulators (they are doomed to
succeed) and I would really love to be able to show this working.
Has anyone done it with a PICKit3?

--
James Newton
1-970-462-7764
{Original Message removed}

2010\11\17@010618 by Xiaofan Chen

face picon face
On Wed, Nov 17, 2010 at 11:26 AM, James Newton <spam_OUTjamesnewtonTakeThisOuTspammassmind.org> wrote:
> Look... I like debuggers... I don't like simulators (they are doomed to
> succeed) and I would really love to be able to show this working.
>
> Has anyone done it with a PICKit3?
>

I like debuggers too. But when I was working with PIC12F629 back in
2004/2005, I gave up using ICD 2 (not PICkit 2 at the time). There are
too many limitations with debugging for the 12F629/12F675 (read the help
very carefully about the limitations with regard to the limitations). Luckily
I have an LED pin and I use that as the debug indicator, with the help
of a good oscilloscope (Lecroy) and that is much better than using
the ICD 2. BTW, 12F629 and 12F675 are very similar and use the
same debug header.

PICkit 3 will not help you either.

-- Xiaofa

2010\11\17@013919 by Steve Smith

flavicon
face
I have to say the last app I wrote for a 675 / 629 I did entirely on an f877
and wrote the IO conditionally so there were two compile methods and found
that was the best way of working with an 8 pin... Its quite restrictive
having only 3 I/O available whilst debugging and the F877 solution was
reasonably simple in terms of a work around that ICD2 could handle

Steve

{Original Message removed}

2010\11\17@075514 by Michael Rigby-Jones

flavicon
face


> -----Original Message-----
> From: .....piclist-bouncesKILLspamspam@spam@MIT.edu [piclist-bouncesspamKILLspamMIT.edu] On
Behalf
{Quote hidden}

I worked on a small project a few months back with a 12F615 (and
appropriate debug header) and found the same issue; PICKit2 was adequate
for programming but I could only debug with the ICD2.

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2010\11\17@122347 by Dwayne Reid

flavicon
face
At 11:38 PM 11/16/2010, Steve Smith wrote:
>I have to say the last app I wrote for a 675 / 629 I did entirely on an f877
>and wrote the IO conditionally so there were two compile methods and found
>that was the best way of working with an 8 pin... Its quite restrictive
>having only 3 I/O available whilst debugging and the F877 solution was
>reasonably simple in terms of a work around that ICD2 could handle

I'm not sure why you say "having only 3 i/o available while debugging".  You need to have the 12f675 debug header if you are going to use the debug feature and that header brings out all 6 i/o lines.

There are caveats: gpio3 cannot be used as an input and one pin (gpio2?) must be in a particular logic state in order to send the program into the flash memory but other than that, you do have access to all 5 i/o lines.  As mentioned: the 6th (input) line must be used as !MCLR.

dwayne

-- Dwayne Reid   <.....dwaynerKILLspamspam.....planet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax
http://www.trinity-electronics.com
Custom Electronics Design and Manufacturing

2010\11\17@124035 by Dwayne Reid

flavicon
face
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   <EraseMEdwaynerspam_OUTspamTakeThisOuTplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax
http://www.trinity-electronics.com
Custom Electronics Design and Manufacturing

2010\11\19@233629 by James Newton

face picon face
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 the
A2D reading on the POT... long story.

Thanks again.

--
James Newton
1-970-462-7764
{Original Message removed}

2010\11\19@233716 by James Newton

face picon face
There are only 5 GPIO lines on the 12F675, so subtract 2 and that leaves 3.
--
James Newton
1-970-462-7764
{Original Message removed}

2010\11\19@233813 by James Newton

face picon face
Thanks Mike, for confirming this for me.... Microchip should NOT be
advertising the PICKit 2 as a debugger for that chip... chaps my hide.

--
James Newton
1-970-462-7764
{Original Message removed}

2010\11\19@233905 by James Newton

face picon face
Thanks Steve, I've got an 16F690 header on the way so I'll use that for
development... maybe the PICKit2 will actually debug with it...

--
James Newton
1-970-462-7764
{Original Message removed}

2010\11\19@234037 by James Newton

face picon face
Would the ICD2 at least single step the thing? I do agree that the pin
limitations make debugging on the 12F675 a loosing game, but I'm curious if
it's possible at all.

--
James Newton
1-970-462-7764
{Original Message removed}

2010\11\20@000747 by Oli Glaser

flavicon
face
On 20/11/2010 04:36, James Newton wrote:
{Quote hidden}

My advice is to get the ICD3 if you are getting anything - it's far better than the PicKit3(which has had quite a few teething problems), and the ICD2 is now unsupported I believe. The ICD3 is the replacement for the ICD2, and does everything and more for less price. I got one when I needed more than my PicKit2 could handle (debugging PIC32 and so on) and I'm very glad I did, has worked great for me so far over quite a few projects. If the 12F675 is debug friendly with anything (i.e. it's not the chip itself that's got problems), I'd bet on the ICD3 doing okay with it.

Maybe ask Microchip for confirmation about the 12Fs before you go spending, but for PICs in general the ICD3 is a handy thing to have around.
(pity I don't have any 12Fs here, or I would have tried one and reported back..)
By the way, (you probably know this, but just in case) all the help files are available on the Microchip site, and each chip has a page that links to the relevant documents (errata, app notes, etc) so you will probably find info on debugging limitations there.

> 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 the
> A2D reading on the POT... long story.
>
> Thanks again.
>
> --
> James Newton
> 1-970-462-7764

2010\11\20@044958 by Bob Axtell

face picon face
Has anybody used a debug header with pickitx ? I can program with my PICKIT3, but nary a step of debugging.


--Bob A

2010\11\20@081003 by Olin Lathrop

face picon face
James Newton wrote:
> 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.

James, you are really going a long way around to avoid the simulator.  What
exactly is going into and coming out of this PIC?  Most people that think
the simulator can't help with their project don't realize how flexible the
stimulus facility is.  Yes, the user interface is needlessly squirrely, but
it's also quite capable.  You haven't explained why you don't want to try it
other than you "don't like" simulators, which is no answer at all.

If inputs can be simulated well enough (and most likely they can), then the
simulator is the best debugger of all the choices in MPLAB.  It's fast, it
gives you access to everything, it has trace back capability, it doesn't
skid on breakpoints, and it can have a unlimited number of breakpoints.

If you're not familiar enough with the simulator to think of it as a tool to
use whenever it's appropriate then it would be worth spending some time
getting there.  This sounds like the perfect project to do that with.  Give
us some more info, and we can help with that.

> Why is the 2 more expensive than the 3?

Because it's older maybe?


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\11\20@084745 by Funny NYPD

picon face
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 <jamesnewtonspamspam_OUTmassmind.org>
To: Microcontroller discussion list - Public. <@spam@piclistKILLspamspammit.edu>
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 the
A2D reading on the POT... long story.

Thanks again.

--
James Newton
1-970-462-7764
{Original Message removed}

2010\11\20@085232 by Funny NYPD

picon face
Try avoid PK3 if you don't need more headache, it is more like an ICD2 rather than a PK2.
On hardware base, the PK3 is an hybrid of PK2 and ICD2, software base, it is purely ICD2. None of the good software architecture on PK2 has shown up in PK3 yet (Please correct me if I am wrong).

Funny N.
Au Group Electronics, http://www.AuElectronics.com
http://www.AuElectronics.com/products
http://augroups.blogspot.com/




________________________________
From: James Newton <KILLspamjamesnewtonKILLspamspammassmind.org>
To: Microcontroller discussion list - Public. <RemoveMEpiclistTakeThisOuTspammit.edu>
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 the
A2D reading on the POT... long story.

Thanks again.

--
James Newton
1-970-462-7764
{Original Message removed}

2010\11\20@183137 by James Newton

face picon face
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 PICLister
(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  <no interrupts enabled, so no
issue>
Due to hardware restrictions the emulator cannot jump to the interrupt
vector memory location in single step or animate mode. <again>

Cannot erase ID memory at Vdd < 4.5v  <running at 5v, no issue>
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.) <running at 5v, no issue>

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.
<running at 5v, no issue>

RBIF is cleared when PORT is interrogated by software, except when Freeze on
Halt is enabled. <? No RB or RBIF, no issue>
This header cannot be programmed while the GP1/RA1 pin is high (VIH) due to
an -ICD debug silicon issue.  <Nothing connected to RA1, it's low and I can
program, no issue>
There are two work arounds:

(1) Move the circuitry that makes GP1/RA1 high to another I/O pin during
programming. <yeah, I'm using GPIO2 for testing>

(2) Manually make GP1/RA1 low during programming (for debuggers that can
supply power to the target): <no need>

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. <no need, the pin isn't being
used>


Freeze on Halt Limitations
Timer0 will not freeze using the internal clock. <not using Timer0>
CMOUTx Pins do not freeze, status bits and interrupt flags do freeze. <not
using any of that>
RBIF is cleared when PORT is interrogated by software, except when Freeze on
Halt is enabled. <not used>



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 removed}

2010\11\20@184419 by James Newton

face picon face
/sigh/ I know I'm going to regret this...

First, I DO use the simulator, and I do understand that it has (a lot of)
advantages. But it always works, and the real device does NOT always work,
and that is why I "don't like" simulators: They are doomed to succeed.
In this specific case: I have a pot connected to AN0 and set so that 2.5v is
on the pin. Now I want to know exactly what ADC count the chip is reading so
I can set that as the midpoint in my code and turn the motors one direction
when the voltage is lower and the other when it is higher.
With a debugger, I simply read the ADC output register and I'm done.

How would you get that value without the debugger?
Go on; tell me how I'm an idiot for not "just" reading the complete ADC
documentation and calculating the correct count reading based on that. Tell
me that you would plug in some code you already have that transmits the
register value on a single pin to a serial port on your PC. Tell me the
simulator has a mode for that, AND that the simulation will, in fact, match
the real output. No, no, better yet, tell me that it's stupid to run motors
off a pot reading and that I'm a moron for even thinking that way. Or some
other abuse I haven't even dared to imagine.
I'm your bitch, bring it "Master".

--
James Newton
1-970-462-7764
{Original Message removed}

2010\11\20@192342 by John Temples

flavicon
face
On Sat, 20 Nov 2010, James Newton wrote:

> In this specific case: I have a pot connected to AN0 and set so that 2.5v is
> on the pin. Now I want to know exactly what ADC count the chip is reading so
> I can set that as the midpoint in my code and turn the motors one direction
> when the voltage is lower and the other when it is higher.
>
> With a debugger, I simply read the ADC output register and I'm done.
>
> How would you get that value without the debugger?

The simulator has a register injection feature that reads hex values
from a file that are injected into ADRES over time.

--
John W. Temples, II

2010\11\20@193827 by James Newton

face picon face
Think about that for just a second?
If I /knew/ the value of ADRES to inject, why would I be trying to find it?

--
James Newton
1-970-462-7764
{Original Message removed}

2010\11\20@202510 by Jan-Erik Soderholm

face picon face
I think like this...

Right, you can setup the pot to give 2.5V at the input
using a voltmeter. But then what ? Will you always
use a voltmeter when setting the pot ?

What does it matter if the motor stands still with 2.4V
or 2.6V at the ADC input ? The visual difference in the
setting of the pot would probably be very small. What kind
of pot is it ? A regular 1-turn or some 10-turn pot ?

I'd also guess that the differense between the ADC value
with Vpp/2 (5V/2, right?) will be quite small compared with
the theoretical half-range value (according to the datasheet).
Probably just +/- a few bits, after all, that is what the
datasheet specifies. And probably smaller then any visable
difference from the mid-position setting of the pot.

*Or* I must seriously be missing something here. :-)

Jan-Erik.







On 2010-11-21 01:38, James Newton wrote:
> Think about that for just a second?
>
> If I /knew/ the value of ADRES to inject, why would I be trying to find it?
>
> --
> James Newton
> 1-970-462-7764
>
> {Original Message removed}

2010\11\20@221430 by Dwayne Reid

flavicon
face
Hi there, James.

I'm sorry that I wasn't clear enough.

The Debug Header for the 12f675 allows you to use all 5 i/o lines for your application.

The debug chip on the header is 6 pins larger than the chip that you are debugging.  Those extra 6 lines are used for pgc & pgd as well as Vpp, reset (I think) and to enable or disable the a/d section (the same header can debug the 12f675 or 12f629).  That means that you CAN use pins gpio 0, 1, 2, 4, 5 in your project and not have any of those pins eaten up by the debugger.

But, as usual, Microchip made mistakes when designing that debug chip.  That's why the problems with gpio1 and not being able to use gpio3 as an input while debugging.  It also looks as if they aren't going to bother fixing those mistakes.

I've been using both the 12f675 and 16f676 debug headers with an ICD2 for several years now - they allow me to debug projects that aren't well suited to the simulator (dealing with multiple asynchronous inputs).

One suggestion: if you do decide to pony up the cash for one of the ICD units, get the ICD3.  Its been WAY less hassle than the ICD2 has ever been.  Much, much more stable and consistent.

Another suggestion: if you think that you might ever want to use the 14 pin variants of that family (16f676, 16f630), get that debug header instead.  The top 8 pins (1,2,3,4:14,13,12,11) map out exactly to the 12f675.  You will have to put conditional compile switches in your code to deal with the differences in the a/d convertor, though.

dwayne


At 09:37 PM 11/19/2010, James Newton wrote:
>There are only 5 GPIO lines on the 12F675, so subtract 2 and that leaves 3..
>
>--
>James Newton
>1-970-462-7764
>
>{Original Message removed}

2010\11\20@221822 by Oli Glaser

flavicon
face
On 21/11/2010 01:23, Jan-Erik Soderholm wrote:
{Quote hidden}

Yes, I see it similarly - a bit of adjusting and gathering empirical data will often suffice for this kind of thing, where the tolerances are reasonable.
However, I can understand the desire to get the hardware debug working as it is undoubtedly a useful tool to have available in general.
For instance, I used to get along without my ICD3 just fine, using things like LEDs or bit banged UART for debugging, but it's certainly more convenient (IMHO) to use the ICD3 and have it all contained within MPLAB.
If I understand where James is coming from, it's not so much the fact that he needs it to make things "possible", just maybe a bit easier.
Plus, there's the frustration when something is meant to work but doesn't, most engineers (me included) find it hard to leave a problem "unsolved", even if it doesn't actually matter much to the whole project...  :-)



{Quote hidden}

>> {Original Message removed}

2010\11\21@100445 by Olin Lathrop

face picon face
James Newton wrote:
> First, I DO use the simulator, and I do understand that it has (a lot
> of) advantages. But it always works, and the real device does NOT
> always work, and that is why I "don't like" simulators: They are
> doomed to succeed.

There are only a few limited things that will work in the simulator and not
on a real PIC.  These are obviously hardware issues, like Vdd not what you
think, forgotten or broken bypass cap, MCLR not held as you think, PGM high
with LVP enabled, incorrect oscillator selected, or external oscillator
hooked up incorrectly.  These issues are all pretty easy to verify with a
scope and get out of the way.  If you can run code on the target PIC at all,
then these issues have most likely been taken care of and the simulator will
be useful to debug your code.

Put another way, the simulator is for debugging your code, not your hardware
setup.  Once you get the hardware setup issues out of the way, the simulator
can be a very useful tool and is definitely a nice debugging environment.

> In this specific case: I have a pot connected to AN0 and set so that
> 2.5v is on the pin. Now I want to know exactly what ADC count the
> chip is reading so I can set that as the midpoint in my code and turn
> the motors one direction when the voltage is lower and the other when
> it is higher.

In theory the threshold is between 511 and 512, assuming you are using a 5V
supply.  Actually, as long as the pot voltage is derived from Vdd
(ratiometric), the absolute supply voltage doesn't matter anyway.  One part
in 1023 is less than you can set the pot to accurately anyway, so why not
just use the 511/512 break to make your decision?

If you really need the motor to stop at a specific pot position, you should
put a deadband in there anyway.  Pots can drift and have some mechanical
backlash.  I doubt you have 1 part in 1000 long term repeatability anyway,
even if you could somehow get back to exactly the same shaft position.  If
this is user tweaked, 1 part in 1000 repeatability is way more than can be
perceived.

> With a debugger, I simply read the ADC output register and I'm done.
>
> How would you get that value without the debugger?

Is this all you want to do with the PICKit2?  I thought you wanted to debug
your code.  I was of course mostly referring to using the simulator to debug
code.  You can put a bunch of A/D readings in a file, mutter the right
incantations to the stimulus setup, and those values will become successive
A/D readings in the simulated code.  You can also simply set a breakpoint
where you detect A/D conversion done and poke the desired value into
ADRESH:ADRESL, then debug the following code to see how it handles that
reading.

> Go on; tell me how I'm an idiot for not "just" reading the complete
> ADC documentation and calculating the correct count reading based on
> that.

I wasn't going to say "idiot".  Besides, the midpoint requires no special
calculations.  As I said, it's between 511 and 512 if you're using all 10
result bits, between 127 and 128 in 8 bit result mode.

> Tell me that you would plug in some code you already have that
> transmits the register value on a single pin to a serial port on your
> PC.

If I really needed to know what a A/D reading was in this setup as a
one-off, I would probably use two pins, one clock and one data.  A sequence
of 10 clocked bits is short enough to be captured on a scope and then
analysed by hand.  It's only 10 bits after all.

> Tell me the simulator has a mode for that, AND that the
> simulation will, in fact, match the real output.

The simulator can't measure a voltage on a real pin, but that's the .01%
problem anyway.  The problem is usually what the code does with that
reading, or in setting up and managing the A/D in the first place.  The
simulator can help with those things quite well.  The details of ADIF
getting set some fixed time after conversion start, ADRES not getting set
until then, etc, are all well simulated.

> No, no, better yet,
> tell me that it's stupid to run motors off a pot reading and that I'm
> a moron for even thinking that way.

You haven't explained what this PIC is supposed to do, so it's hard to reach
any conclusions.

> Or some other abuse I haven't
> even dared to imagine.
>
> I'm your bitch, bring it "Master".

Wow, you ran out of small furry animals to kick or something?  I was trying
to help.  Remember, you came here asking for advice.  My life will go on
just fine whether you ever get this working or not.  I'm willing to help,
but if I'd known you were going to be a jerk about it I wouldn't have
bothered.

I had thought of going back and deleting some of the things I said above,
but I already spent the time on them before I realized you decided to be a
arrogant ingrate.  Maybe they will help someone else trying to debug a small
PIC project.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\11\21@141154 by Oli Glaser

flavicon
face
On 21/11/2010 15:05, Olin Lathrop wrote:
> James Newton wrote:
>
>> Tell me that you would plug in some code you already have that
>> transmits the register value on a single pin to a serial port on your
>> PC.
> If I really needed to know what a A/D reading was in this setup as a
> one-off, I would probably use two pins, one clock and one data.  A sequence
> of 10 clocked bits is short enough to be captured on a scope and then
> analysed by hand.  It's only 10 bits after all.
>

Yes, that's the kind of thing I was thinking of when I mentioned bit banging stuff - a couple of pins, or maybe just one Tx pin if they are in short supply, then you could use the PicKit2 UART tool. I have done this quite a lot - I just use the PGC/PGD pins as the Tx/Rx so it saves having to move the PicKit2 connections at all.



{Quote hidden}

ROFL - only on the PicList.....

2010\11\22@042528 by alan.b.pearce

face picon face
> will wait and try to save my pennies for an ICD2 or ICD3. Why is the 2
more
> expensive than the 3?

Because the ICD2 is being phased out, and the ICD3 is much better
(faster USB interface, and able to handle a wider range of PICs). -- Scanned by iCritical.

2010\11\22@081208 by Olin Lathrop

face picon face
Oli Glaser wrote:
>> If I really needed to know what a A/D reading was in this setup as a
>> one-off, I would probably use two pins, one clock and one data.  A
>> sequence of 10 clocked bits is short enough to be captured on a
>> scope and then analysed by hand.  It's only 10 bits after all.
>
> Yes, that's the kind of thing I was thinking of when I mentioned bit
> banging stuff - a couple of pins, or maybe just one Tx pin if they are
> in short supply, then you could use the PicKit2 UART tool. I have done
> this quite a lot - I just use the PGC/PGD pins as the Tx/Rx so it
> saves having to move the PicKit2 connections at all.

Yes, you could do it with one pin and a UART to receive bytes.  The problem
with that is that the timing has to be just right.  While that's doable,
it's a lot more work than just clocking out 10 bits and analyzing the scope
capture once or twice.  If you had to do it regularly, then the extra effort
of creating a software UART at a standard baud rate could be worth it.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\11\22@094959 by Charles Craft

picon face
Looks like the ICD2 trade-in program ended in 2009.
Anyone have luck getting a discount on a ICD3 in 2010?

On 11/22/2010 4:25 AM, spamBeGonealan.b.pearcespamBeGonespamstfc.ac.uk wrote:
>> will wait and try to save my pennies for an ICD2 or ICD3. Why is the 2
>>      
> more
>    
>> expensive than the 3?
>>      
> Because the ICD2 is being phased out, and the ICD3 is much better
> (faster USB interface, and able to handle a wider range of PICs).
>

2010\11\22@173356 by Barry Gershenfeld

picon face
Still, you can't beat developing on a 12C671 (as in, OTP) for
entertainment.  Not only can't you debug it, but you have to unsolder it and
throw it away after each cycle.  I did that once. (ONCE).

I think that what I got out of that adventure was much like what Steve Smith
said above.  Work out all the hardware mysteries on a more capable chip,
like the 877, and then port back to the little guy.  This may not eliminate
differences between the chips, but I haven't found many of those.  Most
problems are due to...the way Microchip designs
peripherals...misinterpreting the data sheet...misunderstanding compiler
behavior...making assumptions about "obvious" things that turn out to be
wrong...and, (I have to say it), debug code with bugs in it :)

Like you, I use the simulator to debug pure code, but I like to see it run
on hardware when I'm testing hardware.  I suspect it's how I think, and
there are probably quite a few of us in that group.

Barry

If I were as smart as some of the people here, having read and completely
understood everything, I wouldn't bother testing my code.  And I'd never
need to ask a question

2010\11\22@203105 by Xiaofan Chen

face picon face
On Tue, Nov 23, 2010 at 6:33 AM, Barry Gershenfeld <TakeThisOuTgbarry42EraseMEspamspam_OUTgmail.com> wrote:
> Still, you can't beat developing on a 12C671 (as in, OTP) for
> entertainment.  Not only can't you debug it, but you have to unsolder it and
> throw it away after each cycle.  I did that once. (ONCE).

I used ICE2000 to debug 16C72A and it was a joy, far better than
ICD 2 or PICkit 2/3. The thing is not cheap and the processor
module is also not cheap, but it is a real emulator.


-- Xiaofan

2010\11\22@210900 by Dwayne Reid

flavicon
face
At 06:31 PM 11/22/2010, Xiaofan Chen wrote:

>I used ICE2000 to debug 16C72A and it was a joy, far better than
>ICD 2 or PICkit 2/3. The thing is not cheap and the processor
>module is also not cheap, but it is a real emulator.

I use my ICE2000 every month for anywhere from a day to a week at a time.  The time savings are ENORMOUS, especially when you have a customer making changes in the middle of the project.

It was well worth the initial cost as well as the on-going costs for new processor modules.

dwayne

-- Dwayne Reid   <RemoveMEdwaynerspamTakeThisOuTplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax
http://www.trinity-electronics.com
Custom Electronics Design and Manufacturing

2010\11\22@210927 by Funny NYPD

picon face
Every time when I recommend ICE2000 to newbie, people laughed on me. I think ICE2000 is obsolete now.

Funny N.
Au Group Electronics, http://www.AuElectronics.com
http://www.AuElectronics.com/products
http://augroups.blogspot.com/




________________________________
From: Xiaofan Chen <xiaofancEraseMEspam.....gmail.com>
To: Microcontroller discussion list - Public. <EraseMEpiclistspammit.edu>
Sent: Mon, November 22, 2010 8:31:04 PM
Subject: Re: [PIC] pickit2 unreliable debug 12F675

On Tue, Nov 23, 2010 at 6:33 AM, Barry Gershenfeld <RemoveMEgbarry42EraseMEspamEraseMEgmail.com> wrote:
> Still, you can't beat developing on a 12C671 (as in, OTP) for
> entertainment.  Not only can't you debug it, but you have to unsolder it and
> throw it away after each cycle.  I did that once. (ONCE).

I used ICE2000 to debug 16C72A and it was a joy, far better than
ICD 2 or PICkit 2/3. The thing is not cheap and the processor
module is also not cheap, but it is a real emulator.


-- Xiaofan

2010\11\23@080427 by Olin Lathrop

face picon face
Dwayne Reid wrote:
> I use my ICE2000 every month for anywhere from a day to a week at a
> time.  The time savings are ENORMOUS, especially when you have a
> customer making changes in the middle of the project.
>
> It was well worth the initial cost as well as the on-going costs for
> new processor modules.

I totally agree.  The ICE2000 and ICE4000 are great debugging tools.  We
have one of each, and probably a couple dozen processor modules.

Unfortunately Microchip doesn't make processor modules for new parts anymore
because they don't want to bother with the bondout part.  It's a real shame..
We also have a few RealIce for those cases where a real ICE can't be used,
but the debugging experience is not as nice or efficient.  I'd happily fork
over the cash for new processor modules if only they were available.  The
real ICE's are well worth their cost.

For small projects the simulator is a good solution.  It doesn't suffer from
the annoyances of the in-circuit debuggers.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\11\23@081100 by Olin Lathrop

face picon face
Funny NYPD wrote:
> Every time when I recommend ICE2000 to newbie, people laughed on me.

There will always be people that buy on up front cost alone and don't think
it thru.  The world is full of cheap people.  For a hobbyist the expense may
not be worth it, but for a professional it is downright irresponsible not to
get a real ICE when it's available for a project.  It's no different than
getting a decent soldering iron, hot air station, set of small tools,
voltmeters, oscilloscopes, magnifiers, lights, good stock of parts, etc.
And if you look at the cost spread out over only a year's worth of jobs,
it's miniscule.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\11\23@185320 by Bob Axtell

face picon face
The way _I_ do debugging on non-ICD2-capable PICs is to connect a piezo beeper to an unused pin, and beep out in MORSE CODE the value of the ADC while running.

I track a firmware loop it by first clearing a memory location, then set bits in it as the PIC cranks through thr code.

Morse code is very easy to learn, especially just the 126 hex values.

I'll send some actually-used code if you like. Uses about 50 pgm words in the PIC12 and PIC16 devices.

Bob A

On 11/20/2010 5:38 PM, James Newton wrote:
{Quote hidden}

> John W. Temples, III

2010\11\23@223806 by Xiaofan Chen

face picon face
On Wed, Nov 24, 2010 at 7:52 AM, Bob Axtell <RemoveMEengineerspam_OUTspamKILLspamcotse.net> wrote:
> The way _I_ do debugging on non-ICD2-capable PICs is to connect a piezo
> beeper to an unused pin, and beep out in MORSE CODE the value of the ADC
> while running.

It can be difficult to have an unused pin for a 8-pin PIC (or 6-pin PIC). ;-)
Back in 2005 I was using PIC12F629/MPASM and I use a pin (used for LED)
for debugging (to check the loop timing).

The product is Series 31 Photoelectric Sensor.
http://www.pepperl-fuchs.us/cps/rde/xchg/usa/hs.xsl/11235.htm?rdeCOQ=SID-7C0F893C-1C405864

The through-beam version is a bit tricky since the transmitting unit
(simple, non-intelligent) and receiving unit are separated. A faster
8-pin PICs would make things a bit easier.

-- Xiaofa

2010\11\23@231643 by Oli Glaser

flavicon
face
On 22/11/2010 13:12, Olin Lathrop wrote:
> Oli Glaser wrote:
>>> If I really needed to know what a A/D reading was in this setup as a
>>> one-off, I would probably use two pins, one clock and one data.  A
>>> sequence of 10 clocked bits is short enough to be captured on a
>>> scope and then analysed by hand.  It's only 10 bits after all.
>> Yes, that's the kind of thing I was thinking of when I mentioned bit
>> banging stuff - a couple of pins, or maybe just one Tx pin if they are
>> in short supply, then you could use the PicKit2 UART tool. I have done
>> this quite a lot - I just use the PGC/PGD pins as the Tx/Rx so it
>> saves having to move the PicKit2 connections at all.
> Yes, you could do it with one pin and a UART to receive bytes.  The problem
> with that is that the timing has to be just right.  While that's doable,
> it's a lot more work than just clocking out 10 bits and analyzing the scope
> capture once or twice.  If you had to do it regularly, then the extra effort
> of creating a software UART at a standard baud rate could be worth it.
>

Maybe in this case to read one or two registers it's not so important, but I find it helps for reading a bunch of data out. I have a few standard C routines in a file I wrote ages ago that I add to my project, set the baud rate and it's ready - timing is not a big deal really as it's unlikely you need to send the data quickly, I usually use 4800 or 9600. I just used this for debugging the Temp Logger project I as working on, quite useful for reading the various registers of the Dallas sensors, RTC and the values written to eeprom.
The PicKit2 UART tool is the main reason I do it like this, as it uses the same lines for the UART as programming.
I'm sure people all have their favourite methods of debugging small micros - I like the Morse code beeper just mentioned... :-)

2010\11\25@021231 by Tamas Rudnai

face picon face
On Tue, Nov 23, 2010 at 11:52 PM, Bob Axtell <RemoveMEengineerTakeThisOuTspamspamcotse.net> wrote:

> The way _I_ do debugging on non-ICD2-capable PICs is to connect a piezo
> beeper to an unused pin, and beep out in MORSE CODE the value of the ADC
> while running.
>

Hehe, nice one :-) But would not it be better to use a serial line (bit-bang
or hardware does not matter) to your PC and see debug messages on screen?

Tamas



{Quote hidden}

>

More... (looser matching)
- Last day of these posts
- In 2010 , 2011 only
- Today
- New search...