Searching \ for '[PIC]: ICD Debugger Specification' 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/devprogs.htm?key=icd
Search entire site for: 'ICD Debugger Specification'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: ICD Debugger Specification'
2001\05\01@224258 by Bob Ammerman

picon face
Well, it looks like Mchip has finally released a document describing how the
'876 chips implement ICD. See DS51242A.

It gives lots of useful information, most of which makes sense. It may even
be enough to actually implement a customer ICD system.

There is on odd thing tho':

Here is section 2.5 from the document:

<QUOTE>

2.5 Communicating with the Target Device

The debug executive establishes the communication channel between the
target device (RB<7:6>) and computer software (e.g., MPLAB IDE.)
Since the debugger will issue read-modify-write instructions (BSF, BCF) on
PORTB for communication with the debugger interface module, addresses
0x106 and 0x186 should be used to modify PORTB<7:6> and TRISB<7:6> so
that bits <5:0> are not corrupted. If the user requests a read or a write of
PORTB or TRISB, addresses 0x006 and 0x086 can be used to access the
RB<5:0> portions of the register.

</QUOTE>

What is Mchip trying to say here? It looks to me that references to
addresses 0x106 and 0x186 only affect the high two order bits of PORTB/TRISB
while references to 0x006 and 0x086 refer to the entire PORTB/TRISB. Perhaps
this is only true when in ICD code (INBUG == 1).

What do you folks think?

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2001\05\02@011141 by Dmitry Kiryashov

flavicon
face
If it could be another issue. Read_modify_write isn't working
for those addresses except bits 7 and 6.

Like you can read from, can write to but RMW is not the same.
Is it possible like that?

More logical explanation is what you gave. Inventing exemption
is much more sophisticated that just disabling 5..0 access.

WBR Dmitry.

PS.

BTW PIC's from inside are microcode driven or they are implemented
in hardware?



Bob Ammerman wrote:
{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\05\02@090607 by Olin Lathrop

face picon face
> What is Mchip trying to say here? It looks to me that references to
> addresses 0x106 and 0x186 only affect the high two order bits of
PORTB/TRISB
> while references to 0x006 and 0x086 refer to the entire PORTB/TRISB.
Perhaps
> this is only true when in ICD code (INBUG == 1).
>
> What do you folks think?

Very interesting, Bob.  Microchip has so far stated that 06h and 106h
(PORTB), and 86h and 186h (TRISB) are equivalent.  I had even considered
recognizing some of the aliased registers in my bank swithching macros and
switching to whichever alias required fewer instructions to get to.

Look at the register map for the 16F876 on page 13 of the data sheet.  I had
always interpreted this as Microchip outright promising that locations 06h
and 106h are equivalent.  It is very interesting to note that only port B is
aliased in this way.  The other ports are not.  Hmm.  I hope you are right
that the different behaviour only occurs when a special bit is set.  Where
did you find this INBUG bit?  What register is it in?  I don't remember it
and a quick check in the likely places in the manual didn't turn up
anything.  I use the ICE for in circuit debugging so I never paid attention
to that before.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olinKILLspamspam@spam@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\05\02@094641 by Bob Ammerman

picon face
The information I posted is from the mchip document

"On Chip Debugger Specification", DS41242A

I found it by drilling down to the 87x on the mchip website.

You probably didn't remember this stuff  because, AFAIK, mchip has just
recently released this document.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

{Original Message removed}

2001\05\03@231041 by myke predko

flavicon
face
> > What is Mchip trying to say here? It looks to me that references to
> > addresses 0x106 and 0x186 only affect the high two order bits of
> PORTB/TRISB
> > while references to 0x006 and 0x086 refer to the entire PORTB/TRISB.
> Perhaps
> > this is only true when in ICD code (INBUG == 1).
> >
> > What do you folks think?
>
> Very interesting, Bob.  Microchip has so far stated that 06h and 106h
> (PORTB), and 86h and 186h (TRISB) are equivalent.  I had even considered
> recognizing some of the aliased registers in my bank swithching macros and
> switching to whichever alias required fewer instructions to get to.

When I was doing the second edition of my PICmicro microcontroller book, I
did some hacking of the ICD Interface and I found that in "ICD mode", all
the hardware registers could be written to, but any changes to them didn't
take effect until *after* a "return" instruction was executed.

While the PICmicro MCU was in ICD mode the only hardware resources that
could be accessed correctly were:
1.  RB6/RB7 via 0x0106.  Only the Programming "Data" pin's TRIS bit could be
changed.  The Clock bit stayed in input mode.
2.  Program memory flash read/write controls.
3.  ICKBUG and BIGBUG (according to DS51242A - I didn't have this document
when I was playing around with it so I called the registers "Reserve_E" and
"Reserve_F") could be read and written before executing a "return" to return
to the executing application.
4.  STATUS, PCLATH, FSR
5.  All File Registers

If you are interested in seeing what I found, Take a look at pages 650 to
652 of the book.  On the CD-ROM, in the EMU-II directory, you will find the
source code that I created from the 256 instructions inserted into the ICD
by the controller.

myke

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\04@005541 by Bob Ammerman

picon face
Bob Ammerman started this thread with:

> > > What is Mchip trying to say here? It looks to me that references to
> > > addresses 0x106 and 0x186 only affect the high two order bits of
> > PORTB/TRISB
> > > while references to 0x006 and 0x086 refer to the entire PORTB/TRISB.
> > Perhaps
> > > this is only true when in ICD code (INBUG == 1).
> > >
> > > What do you folks think?

Myke Predko noted:

> When I was doing the second edition of my PICmicro microcontroller book, I
> did some hacking of the ICD Interface and I found that in "ICD mode", all
> the hardware registers could be written to, but any changes to them didn't
> take effect until *after* a "return" instruction was executed.

Bob then wondered:

Would this still be the case if 'FREEZE' wasn't specified inthe debug
control register?

Myke continued on:

> While the PICmicro MCU was in ICD mode the only hardware resources that
> could be accessed correctly were:
> 1.  RB6/RB7 via 0x0106.  Only the Programming "Data" pin's TRIS bit could
be
> changed.  The Clock bit stayed in input mode.
> 2.  Program memory flash read/write controls.
> 3.  ICKBUG and BIGBUG (according to DS51242A - I didn't have this document
> when I was playing around with it so I called the registers "Reserve_E"
and
> "Reserve_F") could be read and written before executing a "return" to
return
> to the executing application.
> 4.  STATUS, PCLATH, FSR
> 5.  All File Registers
>
> If you are interested in seeing what I found, Take a look at pages 650 to
> 652 of the book.  On the CD-ROM, in the EMU-II directory, you will find
the
> source code that I created from the 256 instructions inserted into the ICD
> by the controller.

Finally, Bob queried:

I assume you mean the 256 instructions inserted into the device under test
by the ICD?

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\05\04@011119 by myke predko

flavicon
face
Hi Bob,


> Bob Ammerman started this thread with:
>
> > > > What is Mchip trying to say here? It looks to me that references to
> > > > addresses 0x106 and 0x186 only affect the high two order bits of
> > > PORTB/TRISB
> > > > while references to 0x006 and 0x086 refer to the entire PORTB/TRISB.
> > > Perhaps
> > > > this is only true when in ICD code (INBUG == 1).
> > > >
> > > > What do you folks think?
>
> Myke Predko noted:
>
> > When I was doing the second edition of my PICmicro microcontroller book,
I
> > did some hacking of the ICD Interface and I found that in "ICD mode",
all
> > the hardware registers could be written to, but any changes to them
didn't
> > take effect until *after* a "return" instruction was executed.
>
> Bob then wondered:
>
> Would this still be the case if 'FREEZE' wasn't specified inthe debug
> control register?

The FREEZ bit is set for all instructions sent to it by the ICD card, but
this is AFTER the register read/writes are performed.

This is a good question and somebody from Microchip should explain how the
code executes.

> Myke continued on:
>
> > While the PICmicro MCU was in ICD mode the only hardware resources that
> > could be accessed correctly were:
> > 1.  RB6/RB7 via 0x0106.  Only the Programming "Data" pin's TRIS bit
could
> be
> > changed.  The Clock bit stayed in input mode.
> > 2.  Program memory flash read/write controls.
> > 3.  ICKBUG and BIGBUG (according to DS51242A - I didn't have this
document
> > when I was playing around with it so I called the registers "Reserve_E"
> and
> > "Reserve_F") could be read and written before executing a "return" to
> return
> > to the executing application.
> > 4.  STATUS, PCLATH, FSR
> > 5.  All File Registers
> >
> > If you are interested in seeing what I found, Take a look at pages 650
to
> > 652 of the book.  On the CD-ROM, in the EMU-II directory, you will find
> the
> > source code that I created from the 256 instructions inserted into the
ICD
> > by the controller.
>
> Finally, Bob queried:
>
> I assume you mean the 256 instructions inserted into the device under test
> by the ICD?

Yes.

myke

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\05\08@005709 by Alejandro Lavarello

picon face
Hi Bob, hi Myke, and others interested in ICD

Another question:
  The ICD code do not allow nested routines? According to DS51242A,
a RETURN will cause the clear of the INBUG bit and "warms" peripherals
freezed by FREEZ bit. (I think that more flexible will be if Microchip
creates a new specific instruction, like "RETURN_FROM_ICD"
instead a general-purpose RETURN).

Another more interesting thing:
  Is necesary to write a GOTO  DEBUG_CODE in the configuration zone (at
position
0x2004)? In certain situation, the PC points to 0x2004 (beyond the program
memory)
But, I dont understand why, in another situation, if a HALT
signal is asserted the PC points to 0x0001. (Section 2.7 to 2.7.2 )

What do you have discovered about it? DS51242A is confusing, I think.

Cheers!
       Alejandro.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\08@011607 by Tony Nixon

flavicon
picon face
Alejandro Lavarello wrote:
>
> Hi Bob, hi Myke, and others interested in ICD
>
> Another question:
>    The ICD code do not allow nested routines? According to DS51242A,
> a RETURN will cause the clear of the INBUG bit and "warms" peripherals
> freezed by FREEZ bit. (I think that more flexible will be if Microchip
> creates a new specific instruction, like "RETURN_FROM_ICD"
> instead a general-purpose RETURN).
>
> Another more interesting thing:
>    Is necesary to write a GOTO  DEBUG_CODE in the configuration zone (at
> position
> 0x2004)? In certain situation, the PC points to 0x2004 (beyond the program
> memory)

This doesn't make sense to me.

I understand that address 0x2004 must be programmed with a programmer,
but if it has a simple goto X instruction there as the data sheet
states, then the PIC must execute at a ROM page according to the current
PCLATH status. This seems wrong.

I would have thought, that the PC would be "loaded" directly from the 13
bit data at address 0x2004.



>  But, I dont understand why, in another situation, if a HALT
> signal is asserted the PC points to 0x0001. (Section 2.7 to 2.7.2 )

This is only after a reset.


--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
salesspamKILLspampicnpoke.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\08@071506 by Bob Ammerman

picon face
> Hi Bob, hi Myke, and others interested in ICD
>
> Another question:
>    The ICD code do not allow nested routines? According to DS51242A,
> a RETURN will cause the clear of the INBUG bit and "warms" peripherals
> freezed by FREEZ bit. (I think that more flexible will be if Microchip
> creates a new specific instruction, like "RETURN_FROM_ICD"
> instead a general-purpose RETURN).

Yes, that is how I read it.

> Another more interesting thing:
>    Is necesary to write a GOTO  DEBUG_CODE in the configuration zone (at
> position
> 0x2004)? In certain situation, the PC points to 0x2004 (beyond the program
> memory)

Yeah, I guess so. But something is fishy here because nothing is being done
with PCLATH!

>  But, I dont understand why, in another situation, if a HALT
> signal is asserted the PC points to 0x0001. (Section 2.7 to 2.7.2 )

Its because of the way the breakpoint is implemented. The breakpoint address
register is initialized to zero. If external HALT is asserted as we come out
of reset the device will automatically take a breakpoint, BUT the breakpoint
is always taken AFTER the instruction executes, hence the PC will be 0x0001.
That's why mChip tells you to put a NOP in location 0: so that you can
really start single stepping your programming from location 0x0001.

> What do you have discovered about it? DS51242A is confusing, I think.

It certainly is.

> Cheers!
>         Alejandro.
>
> --
> http://www.piclist.com hint: The list server can filter out subtopics
> (like ads or off topics) for you. See http://www.piclist.com/#topics
>
>

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\08@210857 by Alejandro Lavarello

picon face
Thanks to Bob Ammermann and Tony Nixon for his replies.

Anbody that own a Microchip's ICD can read the position 0x2004
in the target PIC (with debug code enabled)? I think that reading this
location
can validate (or not) the Tony's hipotesis about 13 bits loading
of the PC (please read below).

Meanwhile, I try to build a ICD using the information provided for
Patrick Touzet in his pages:

http://www.multimania.com/silicium31/
http://www.multimania.com/silicium31/Electronique/PIC/free_icd.htm

Best regards.

        Alejandro.


I wrote:

>> Another more interesting thing:
>>    Is necesary to write a GOTO  DEBUG_CODE in the configuration zone (at
>> position
>> 0x2004)? In certain situation, the PC points to 0x2004 (beyond the program
>> memory)

Tony Nixon replies:

>This doesn't make sense to me.

>I understand that address 0x2004 must be programmed with a programmer,
>but if it has a simple goto X instruction there as the data sheet
>states, then the PIC must execute at a ROM page according to the current
>PCLATH status. This seems wrong.

>I would have thought, that the PC would be "loaded" directly from the 13
>bit data at address 0x2004.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\08@213810 by Alexandre Domingos F. Souza

flavicon
face
>Meanwhile, I try to build a ICD using the information provided for
>Patrick Touzet in his pages:
>http://www.multimania.com/silicium31/
>http://www.multimania.com/silicium31/Electronique/PIC/free_icd.htm

       Errr...very interesting...but...

       How do I use that????????????

       How do I connect the ICD to my board? I thought there was a board that you put on the circuit to be debugged, connect this board to the ICD and use the pic you programmed on top of this...How do it work?

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\08@215526 by myke predko

flavicon
face
Hiya,

Should I post the source code I created from the ICD download on my web
page?  I held off because seeing the code is one thing, but you do not see
how the ICD box interfaces to it (there is a *lot* of communications
including resets going on there).

Before I post it, I want to change the registers (0x018E and 0x018F) to the
Microchip specified names.

{Quote hidden}

This "feature" makes it quite challenging to code for the ICD and when you
take a look at the source for the ICD (on the targe PICmicro), it can be
quite difficult to understand.

When I played around with the ICD, trying to "clean up" the code on my own,
I discovered this aspect of the debugger.

Personally, I don't know how much importance I would place on a separate
instruction since there is really only 256 instructions that you can play
with and I want to see what I can come up with on my own, but I will
probably use the Microchip code simply because I have invested quite a bit
of time understanding it.

>  > Another more interesting thing:
> >    Is necesary to write a GOTO  DEBUG_CODE in the configuration zone (at
> > position
> > 0x2004)? In certain situation, the PC points to 0x2004 (beyond the
program
> > memory)
>
> Yeah, I guess so. But something is fishy here because nothing is being
done
> with PCLATH!

I don't understand this either.  I suspect that if ICD mode is selected in
the configuration registers this address becomes a new reset vector.

> >  But, I dont understand why, in another situation, if a HALT
> > signal is asserted the PC points to 0x0001. (Section 2.7 to 2.7.2 )
>
> Its because of the way the breakpoint is implemented. The breakpoint
address
> register is initialized to zero. If external HALT is asserted as we come
out
> of reset the device will automatically take a breakpoint, BUT the
breakpoint
> is always taken AFTER the instruction executes, hence the PC will be
0x0001.
> That's why mChip tells you to put a NOP in location 0: so that you can
> really start single stepping your programming from location 0x0001.
>
> > What do you have discovered about it? DS51242A is confusing, I think.
>
> It certainly is.

I have spent about fifteen hours with an oscilloscope and burning different
code into the chip to see how it works.

It actually isn't that confusing - but it is limited.  I feel like there
should be ways of enhancing its capabilities (ie being able to access the PC
stack), but I don't know.

myke

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


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