Searching \ for '[PIC] ICD Reality Check' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devprogs.htm?key=icd
Search entire site for: 'ICD Reality Check'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] ICD Reality Check'
2011\04\17@010448 by Josh Koffman

face picon face
Hi folks,

I'm considering using a PIC18f25K22 in an upcoming project. I chose
this chip because I require two UARTs. I just noticed that it has the
RX/TX for one the UARTs multiplexed on the PCG/PCD pins used for in
circuit debugging. As far as I know (and I'd love to be proven wrong)
that means I can't use both UARTs while in debug mode. My current plan
is to develop half the code (call it the transmit code) on the other
UART, change that code to point to the disabled UART, write the
receive code on the exposed UART, then compile in release mode and
hope they both work. I would be debugging each half separately but I'd
be unable to do them together.

Any thoughts on why I'm wrong, or on possibly better ways to go about this?

Thanks!

Josh
-- A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
        -Douglas Adams

2011\04\17@011314 by Josh Koffman

face picon face
Wait a second...am I just being dumb?

Could I use the transmit and receive on a single UART independently?
Same speeds. The RX and TX pins would each go to their own
transceiver.

Thoughts?

Josh
-- A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
        -Douglas Adams

2011\04\17@012618 by Josh Koffman

face picon face
On Sun, Apr 17, 2011 at 1:04 AM, Josh Koffman <spam_OUTjoshybearTakeThisOuTspamgmail.com> wrote:
<snip>
> RX/TX for one the UARTs multiplexed on the PCG/PCD pins used for in
<snip>

That should of course be PGC and PGD. Apologies.

-j
-- A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
        -Douglas Adams

2011\04\17@084700 by Olin Lathrop

face picon face
Josh Koffman wrote:
> I'm considering using a PIC18f25K22 in an upcoming project. I chose
> this chip because I require two UARTs. I just noticed that it has the
> RX/TX for one the UARTs multiplexed on the PCG/PCD pins used for in
> circuit debugging. As far as I know (and I'd love to be proven wrong)
> that means I can't use both UARTs while in debug mode. My current plan
> is to develop half the code (call it the transmit code) on the other
> UART, change that code to point to the disabled UART, write the
> receive code on the exposed UART, then compile in release mode and
> hope they both work. I would be debugging each half separately but I'd
> be unable to do them together.

I haven't looked, but there is probably something like a 18F45K22.  Use that
for debugging.


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

2011\04\17@093029 by Herbert Graf

picon face
On Sun, 2011-04-17 at 01:04 -0400, Josh Koffman wrote:
> Hi folks,
>
> I'm considering using a PIC18f25K22 in an upcoming project. I chose
> this chip because I require two UARTs. I just noticed that it has the
> RX/TX for one the UARTs multiplexed on the PCG/PCD pins used for in
> circuit debugging. As far as I know (and I'd love to be proven wrong)
> that means I can't use both UARTs while in debug mode. My current plan
> is to develop half the code (call it the transmit code) on the other
> UART, change that code to point to the disabled UART, write the
> receive code on the exposed UART, then compile in release mode and
> hope they both work. I would be debugging each half separately but I'd
> be unable to do them together.
>
> Any thoughts on why I'm wrong, or on possibly better ways to go about this?

I don't know specifically about that part, but some parts allow you to
select different pins for ICD functionality (you still program over the
PGC/PGD pins, but then use other pins for debug). Perhaps this is only
something available in the 24/30/33F parts?

TTYL

2011\04\17@093138 by Herbert Graf

picon face
On Sun, 2011-04-17 at 01:12 -0400, Josh Koffman wrote:
> Wait a second...am I just being dumb?
>
> Could I use the transmit and receive on a single UART independently?
> Same speeds. The RX and TX pins would each go to their own
> transceiver.

Do you mean the RX connected to one device and the TX to another?
Absolutely, as long as speeds and com parameters are the same.

TTYL

2011\04\17@105817 by Oli Glaser

flavicon
face
On 17/04/2011 14:30, Herbert Graf wrote:
> On Sun, 2011-04-17 at 01:04 -0400, Josh Koffman wrote:
>> Hi folks,
>>
>> I'm considering using a PIC18f25K22 in an upcoming project. I chose
>> this chip because I require two UARTs. I just noticed that it has the
>> RX/TX for one the UARTs multiplexed on the PCG/PCD pins used for in
>> circuit debugging. As far as I know (and I'd love to be proven wrong)
>> that means I can't use both UARTs while in debug mode. My current plan
>> is to develop half the code (call it the transmit code) on the other
>> UART, change that code to point to the disabled UART, write the
>> receive code on the exposed UART, then compile in release mode and
>> hope they both work. I would be debugging each half separately but I'd
>> be unable to do them together.
>>
>> Any thoughts on why I'm wrong, or on possibly better ways to go about this?
> I don't know specifically about that part, but some parts allow you to
> select different pins for ICD functionality (you still program over the
> PGC/PGD pins, but then use other pins for debug). Perhaps this is only
> something available in the 24/30/33F parts?

I think it is - I can't remember seeing more than PGC/PGD port on any 18F parts.
I do know there are some 18F parts with "Peripheral Pin Select", which allows you to map the peripheral to different pins. One such family is the 18FxxJ50 - I used the 24J50 from this family, which does have 2 UARTs.
Probably the best way if you want to use that chip would be to use the next size up in the family for debug (which should hopefully not have the UART multiplexed with PGC/PGD) as Olin suggested.

2011\04\17@172109 by Josh Koffman

face picon face
On Sun, Apr 17, 2011 at 10:57 AM, Oli Glaser <.....oli.glaserKILLspamspam@spam@talktalk.net> wrote:
> On 17/04/2011 14:30, Herbert Graf wrote:
>> I don't know specifically about that part, but some parts allow you to
>> select different pins for ICD functionality (you still program over the
>> PGC/PGD pins, but then use other pins for debug). Perhaps this is only
>> something available in the 24/30/33F parts?
>
> I think it is - I can't remember seeing more than PGC/PGD port on any
> 18F parts.
> I do know there are some 18F parts with "Peripheral Pin Select", which
> allows you to map the peripheral to different pins. One such family is
> the 18FxxJ50 - I used the 24J50 from this family, which does have 2 UARTs..
> Probably the best way if you want to use that chip would be to use the
> next size up in the family for debug (which should hopefully not have
> the UART multiplexed with PGC/PGD) as Olin suggested.

Funnily enough, there is an 18F part that does it. The 18F4550 and the
18F4455 both do it. I had a discussion with one of the Microchip
Training guys about that, and he didn't realize there was an 18F part
that did it either. The part I don't get it is that you have to
program the chip to enable the secondary port...using the original
port. So unless you preprogram the chip out of circuit, or have two
ICSP ports on your board, you can't really use the second port easily.

In any case, I think Olin's suggestion is a good one but I think for
this application I will just use the TX and RX lines connected to
separate transceivers. I planned out my port connections last night I
realized I can't spare the extra RX and TX lines anyway.

Thanks!

Josh
-- A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
        -Douglas Adams

2011\04\17@172455 by Josh Koffman

face picon face
On Sun, Apr 17, 2011 at 9:31 AM, Herbert Graf <hkgrafspamKILLspamgmail.com> wrote:
> On Sun, 2011-04-17 at 01:12 -0400, Josh Koffman wrote:
>> Could I use the transmit and receive on a single UART independently?
>> Same speeds. The RX and TX pins would each go to their own
>> transceiver.
>
> Do you mean the RX connected to one device and the TX to another?
> Absolutely, as long as speeds and com parameters are the same.

Yup. I had a look at my code library and it looks like I don't do
anything funny like disabling the ports so it should work (I think).

This sounds pretty good and it saves me the extra port pins...interesting....

Josh
-- A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
        -Douglas Adams

2011\04\17@172913 by Josh Koffman

face picon face
On Sun, Apr 17, 2011 at 8:47 AM, Olin Lathrop <.....olin_piclistKILLspamspam.....embedinc.com> wrote:
> I haven't looked, but there is probably something like a 18F45K22.  Use that
> for debugging.

Right, that makes sense. Thanks!

Josh
-- A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
        -Douglas Adams

2011\04\17@173422 by Jan-Erik Soderholm

face picon face
Josh Koffman wrote 2011-04-17 23:24:
> On Sun, Apr 17, 2011 at 9:31 AM, Herbert Graf<EraseMEhkgrafspam_OUTspamTakeThisOuTgmail.com>  wrote:
>> On Sun, 2011-04-17 at 01:12 -0400, Josh Koffman wrote:
>>> Could I use the transmit and receive on a single UART independently?
>>> Same speeds. The RX and TX pins would each go to their own
>>> transceiver.
>>
>> Do you mean the RX connected to one device and the TX to another?
>> Absolutely, as long as speeds and com parameters are the same.
>
> Yup. I had a look at my code library and it looks like I don't do
> anything funny like disabling the ports so it should work (I think).
>
> This sounds pretty good and it saves me the extra port pins...interesting....
>
> Josh

Or, another way to look at it.

>>> Could I use the transmit and receive on a single UART independently?

You always use then independently! :-)

The PIC or the USART has no way to tell if both signals actualy
go to a single system on the other side or not. There are
no "connections" between them (apart from sharing some hardware
such as the baud rate generator).

:-)

Jan-Erik

2011\04\17@174131 by Oli Glaser

flavicon
face
On 17/04/2011 22:20, Josh Koffman wrote:
> Funnily enough, there is an 18F part that does it. The 18F4550 and the
> 18F4455 both do it. I had a discussion with one of the Microchip
> Training guys about that, and he didn't realize there was an 18F part
> that did it either. The part I don't get it is that you have to
> program the chip to enable the secondary port...using the original
> port. So unless you preprogram the chip out of circuit, or have two
> ICSP ports on your board, you can't really use the second port easily.

Doh! I have both an 18F4550 and 18F4455 here, but it's been a while since I used either - typical.. :-)
With the enabling of the secondary port - IIRC the programming is actually available on either straight away, just the debug port needs to be set in the config bits. This means you can set it up however you want, and only use one port. The first time you program, you enable the port for debug (if it's not the default one)
At least this is the way I remember it on the PIC32.

2011\04\18@081127 by Olin Lathrop

face picon face
Josh Koffman wrote:
> Funnily enough, there is an 18F part that does it. The 18F4550 and the
> 18F4455 both do it. I had a discussion with one of the Microchip
> Training guys about that, and he didn't realize there was an 18F part
> that did it either. The part I don't get it is that you have to
> program the chip to enable the secondary port...using the original
> port.

No, the dedicated programming port is always "live" for programming when you
raise the Vpp line of the dedicated port, if you've enabled the port by
tying a line high.  On those chips, I can't see any reason to ever use the
traditional PGC and PGD lines.


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

2011\04\18@100152 by Herbert Graf

picon face
On Sun, 2011-04-17 at 17:20 -0400, Josh Koffman wrote:
{Quote hidden}

That's why I thought the 18F had that feature, thanks for pointing that
out.

In my case I used a DPDT through to go between program mode and debug
mode, worked quite well.

TTYL

2011\04\18@111339 by Oli Glaser

flavicon
face
On 18/04/2011 13:11, Olin Lathrop wrote:
> Josh Koffman wrote:
>> Funnily enough, there is an 18F part that does it. The 18F4550 and the
>> 18F4455 both do it. I had a discussion with one of the Microchip
>> Training guys about that, and he didn't realize there was an 18F part
>> that did it either. The part I don't get it is that you have to
>> program the chip to enable the secondary port...using the original
>> port.
> No, the dedicated programming port is always "live" for programming when you
> raise the Vpp line of the dedicated port, if you've enabled the port by
> tying a line high.  On those chips, I can't see any reason to ever use the
> traditional PGC and PGD lines.
>

I just had a read of the 18F4550 datasheet - you have to program the relevant config bit first to enable the dedicated port. This would appear to mean that you have to use the legacy port first.
I thought it was like the PIC32 (or other higher end PICs) where you can use any port to program, and the config bit selects the debug port only, but apparently not.

2011\04\18@121818 by Olin Lathrop

face picon face
Oli Glaser wrote:
> I just had a read of the 18F4550 datasheet - you have to program the
> relevant config bit first to enable the dedicated port. This would
> appear to mean that you have to use the legacy port first.

Yes, that's what I thought at first too from the datasheet.  I think the
datasheet description is misleading or downright wrong.  I can tell you that
I've got units in production using the 18F4550 that were only ever
programmed via the dedicated programming/debug port.


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

2011\04\18@132414 by Oli Glaser

flavicon
face
On 18/04/2011 17:18, Olin Lathrop wrote:
> Oli Glaser wrote:
>> I just had a read of the 18F4550 datasheet - you have to program the
>> relevant config bit first to enable the dedicated port. This would
>> appear to mean that you have to use the legacy port first.
> Yes, that's what I thought at first too from the datasheet.  I think the
> datasheet description is misleading or downright wrong.  I can tell you that
> I've got units in production using the 18F4550 that were only ever
> programmed via the dedicated programming/debug port.
>

Interesting, given this fact, I wondered if the ICPRT config bit is set by default on the 44-pin devices, but I just checked and according to the datasheet it's not.
Like you say, it would seem that the datasheet is not telling the full story. At the very least they fail to mention that ICPRT is set by default for the 44-pin device (which would make sense in your case)

2011\04\18@202119 by piclist4

flavicon
face
On Sun, 9 May 2010, Olin Lathrop wrote:

> No, the dedicated programming port is always "live" for programming when you
> raise the Vpp line of the dedicated port,

If that's true, it doesn't work with the REAL ICE.  The REAL ICE reads
zeros for the device ID when trying to enter programming mode on the
dedicated port with ICPRT = 0.

> if you've enabled the port by tying a line high.

If you're referring to the ICPORTS pin, that enables 28-pin emulation
when low.  I can't see any indication that bringing it high (which
would be the normal state when using a 40/44 pin device) has anything
to do with enabling the dedicated port.

Oli Glaser wrote:

> At the very least they fail to mention that ICPRT is set by default
> for the 44-pin device.

ICPRT is 0 (dedicated port disabled) after erasing a 44-pin part, just
like the data sheet says.  I suppose it's possible that 44-pin parts
are shipping from the factory with ICPRT = 1 even though the default
is 0, though that seems unlikely.

Another reference:

http://www.microchip.com/forums/tm.aspx?high=&m=191731&mpage=1#191738

--
John W. Temples, II

2011\04\19@091605 by Olin Lathrop

face picon face
piclist4@xargs.com wrote:
>> No, the dedicated programming port is always "live" for programming
>> when you raise the Vpp line of the dedicated port,
>
> If that's true, it doesn't work with the REAL ICE.  The REAL ICE reads
> zeros for the device ID when trying to enter programming mode on the
> dedicated port with ICPRT = 0.

Like I said, I've got virgin chips that have only ever been programmed over
the dedicated programming port.  This works for debugging with a RealIce
too.  It may very well be that ICPRT = 0 disables that.  The disconnect may
be that chips are shipped from the factory with the dedicated programming
port enabled.  That may not be what the documentation says, but it makes
sense when you think about it.

>> if you've enabled the port by tying a line high.
>
> If you're referring to the ICPORTS pin, that enables 28-pin emulation
> when low.

Yeah, you're right.  I had just taken a quick look at a schematic using a
18F4550 and saw that line tied high and misremembered that it had something
to do with enabling the port.


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

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