Hardware breakpoint registers in PIC18F2550

(instructions, reset, WDT, specifications...) PIC17Cxx, PIC18Fxxx

Hardware breakpoint registers in PIC18F2550

Postby Joseph Watson » Mon Aug 04, 2014 2:27 am

I am trying to find out how to access the registers in the PIC18F2550 that holds the hardware breakpoint address while debugging. I know how it is done in the PIC18F452 but it is not the same in this chip. If someone has that info, please post it or PM me with it. Thanks.
NCR once refused to hire me because I was too short. I'm still waiting on my growth spurt.
User avatar
Joseph Watson
 
Posts: 49
Joined: Sat May 31, 2014 8:06 pm
Location: Ohio, USA
PIC experience: Experienced Hobbyist

Re: Hardware breakpoint registers in PIC18F2550

Postby jtemples » Mon Aug 04, 2014 2:58 am

What do you mean by "access" it?
jtemples
Verified identity
 
Posts: 195
Joined: Sun May 25, 2014 2:23 am
Location: The 805
PIC experience: Professional 5+ years with MCHP products

Re: Hardware breakpoint registers in PIC18F2550

Postby Joseph Watson » Mon Aug 04, 2014 4:28 am

The hardware breakpoint registers are not accessible in normal operation, only in debug mode. I want to access them with my own assembly language code. I believe the Shadow bit in the Debug register must be set to 1 and then perhaps more steps taken to enable the hardware breakpoint registers to become accessible. I am not sure of what steps and not sure of what address or addresses are used for storing in them. Experimentation has shown that 0xFB9 may be involved but I am not sure just how.
NCR once refused to hire me because I was too short. I'm still waiting on my growth spurt.
User avatar
Joseph Watson
 
Posts: 49
Joined: Sat May 31, 2014 8:06 pm
Location: Ohio, USA
PIC experience: Experienced Hobbyist

Re: Hardware breakpoint registers in PIC18F2550

Postby ric » Mon Aug 04, 2014 5:06 am

I think the debug registers for the 16F877 were the only ones that were ever officially "leaked".
Where did you find out about the PIC18F452 registers?
I assume a bit of disassembly of the debug executive should reveal where they are.
Latest test project, an LED matrix display made from one reel of addressable LEDs. here
User avatar
ric
Verified identity
 
Posts: 659
Joined: Sat May 24, 2014 2:35 pm
Location: Melbourne, Australia
PIC experience: Professional 5+ years with MCHP products

Re: Hardware breakpoint registers in PIC18F2550

Postby Ian.M » Mon Aug 04, 2014 10:14 am

Jarin reverse engineered the PIC18F4620 family debug mode back in 2009.
http://jaromir.xf.cz/hdeb/hdeb.html
If you look at the MPLAB 8 PICkit 2 debugger pk2.xml you will find:
Code: Select all
   <pk2:debugexec id="PIC18F4550">
      <pk2:defilename filename="pk18F_Bank03.HEX"/>
      <pk2:desize size="0x240"/>
      <pk2:dememtype memtype="MT_PROGRAM"/>
      <pk2:depcadd address="0xFFD"/>
      <pk2:dewregadd address="0x3FF"/>
      <pk2:dereservedrange start="0x3F4" end="0x3FF"/>   <!-- Used by DE -->
      <pk2:dereservedrange start="0x800" end="0xEFF"/>   <!-- Unused -->
      <pk2:dereservedrange start="0xFDB" end="0xFDF"/>   <!-- Skip PLUSW2, PREINC2, POSTDEC2, POSTINC2, INDF2 -->
      <pk2:dereservedrange start="0xFE3" end="0xFE7"/>   <!-- Skip PLUSW1, PREINC1, POSTDEC1, POSTINC1, INDF1 -->
      <pk2:dereservedrange start="0xFEB" end="0xFEF"/>   <!-- Skip PLUSW0, PREINC0, POSTDEC0, POSTINC0, INDF0 -->
      <pk2:dereservedrange start="0xFD4" end="0xFD4"/>   <!-- hidden shadow bank register -->
      <pk2:dereservedrange start="0xFFD" end="0xFFF"/>   <!-- Stack (garbage to user)-->
      <pk2:deremap realadd="0xFD8" savedadd="0x3FE"/>    <!-- STATUS -->
      <pk2:deremap realadd="0xFE0" savedadd="0x3FD"/>    <!-- BSR -->
      <pk2:deremap realadd="0xFE8" savedadd="0x3FF"/>    <!--  WREG -->
      <pk2:deremap realadd="0xFE9" savedadd="0x3FC"/>    <!-- FSR0L -->
      <pk2:deremap realadd="0xFEA" savedadd="0x3FB"/>    <!-- FSR0H -->
      <pk2:deremap realadd="0xFF9" savedadd="0xFFD"/>    <!-- PCL (steal from TOS) -->
      <pk2:deremap realadd="0xFFA" savedadd="0x3F5"/>    <!-- PCLATH -->
      <pk2:deremap realadd="0xFFB" savedadd="0x3F4"/>    <!-- PCLATL -->
   </pk2:debugexec>         
   
   <pk2:debugexec id="PIC18F4620">
      <pk2:defilename filename="pk18F_Bank14.HEX"/>
      <pk2:desize size="0x240"/>
      <pk2:dememtype memtype="MT_PROGRAM"/>
      <pk2:depcadd address="0xFFD"/>
      <pk2:dewregadd address="0xEFF"/>
      <pk2:dereservedrange start="0xEF4" end="0xEFF"/>   <!-- Used by DE -->
      <pk2:dereservedrange start="0xFDB" end="0xFDF"/>   <!-- Skip PLUSW2, PREINC2, POSTDEC2, POSTINC2, INDF2 -->
      <pk2:dereservedrange start="0xFE3" end="0xFE7"/>   <!-- Skip PLUSW1, PREINC1, POSTDEC1, POSTINC1, INDF1 -->
      <pk2:dereservedrange start="0xFEB" end="0xFEF"/>   <!-- Skip PLUSW0, PREINC0, POSTDEC0, POSTINC0, INDF0 -->
      <pk2:dereservedrange start="0xFD4" end="0xFD4"/>   <!-- hidden shadow bank register -->
      <pk2:dereservedrange start="0xFFD" end="0xFFF"/>   <!-- Stack (garbage to user)-->
      <pk2:deremap realadd="0xFD8" savedadd="0xEFE"/>    <!-- STATUS -->
      <pk2:deremap realadd="0xFE0" savedadd="0xEFD"/>    <!-- BSR -->
      <pk2:deremap realadd="0xFE8" savedadd="0xEFF"/>    <!--  WREG -->
      <pk2:deremap realadd="0xFE9" savedadd="0xEFC"/>    <!-- FSR0L -->
      <pk2:deremap realadd="0xFEA" savedadd="0xEFB"/>    <!-- FSR0H -->
      <pk2:deremap realadd="0xFF9" savedadd="0xFFD"/>    <!-- PCL (steal from TOS) -->
      <pk2:deremap realadd="0xFFA" savedadd="0xEF5"/>    <!-- PCLATH -->
      <pk2:deremap realadd="0xFFB" savedadd="0xEF4"/>    <!-- PCLATL -->
   </pk2:debugexec>   

Disassembling and comparing pk18F_Bank03.HEX and pk18F_Bank14.HEX + Jarin's work should gain you a good understanding of the debug SFRs.

N.B. I belive the debug SFRs may be protected when running user mode code and I think you need to be in a debug executive (Microchip or your own replacement) to access them. See http://www.microchip.com/forums/m681290.aspx
Ian.M
Verified identity
 
Posts: 95
Joined: Wed May 28, 2014 12:47 am
PIC experience: Professional 1+ years with MCHP products

Re: Hardware breakpoint registers in PIC18F2550

Postby Olin Lathrop » Mon Aug 04, 2014 1:46 pm

Joseph Watson wrote:I am trying to find out how to access the registers in the PIC18F2550 that holds the hardware breakpoint address while debugging.

Why? Unless you are creating your own debugger, what use is this to you? If you are creating your own third party debugger, you can probably explain that to your local FAE and Microchip might give you the appropriate documentation.

I expect this is something Microchip doesn't normally give out because then they'd have to support it to the general publich that will just get themselves into trouble and not derive any benefit. If you do have a legitimate reason for access these registers, Microchip may help you. If you don't, then you're just wasting a lot of time. In any case, nobody here can help. Even those few that may have been given this information by Microchip probably had to sign a NDA, so can't help.

Trying to infer the interface by reverse engineering will at best only tell you how it is used in specific instances, not what is possible in general and what broader restrictions might be.

I don't see any upside here.
User avatar
Olin Lathrop
Verified identity
 
Posts: 48
Joined: Fri May 30, 2014 3:38 pm
Location: Littleton, MA USA
PIC experience: Professional 5+ years with MCHP products

Re: Hardware breakpoint registers in PIC18F2550

Postby Joseph Watson » Mon Aug 04, 2014 6:30 pm

I am familiar with the Jaromir.xf.cz pages. Based on that info, I have been writing my own little debug executive. I also found info reaffirming the data that he presents for both the PIC18F452 and the PIC18F4520 in the downloads associated with the book at this page:http://www.microdesignsinc.com/picbook/index.html.

My own testing has shown that the register at 0xFB9 does become accessible (writable and readable) or inaccessible (always returning zeros) according to whether the Shadow bit of the Debug register is set or not when in the debug mode. I suspect that I am just looking for the other associated registers and thought perhaps someone here knew where to find them or how to make them accessible. I have determined that none of the other "unimplemented" registers of the PIC18F2550 become similarly writable and readable when the Shadow bit is set.
NCR once refused to hire me because I was too short. I'm still waiting on my growth spurt.
User avatar
Joseph Watson
 
Posts: 49
Joined: Sat May 31, 2014 8:06 pm
Location: Ohio, USA
PIC experience: Experienced Hobbyist

Re: Hardware breakpoint registers in PIC18F2550

Postby Joseph Watson » Tue Aug 05, 2014 3:38 am

I am here with some news. I figured out where the additional breakpoint registers are located. They were right under my nose. In fact, they are right at the same addresses where they are on the PIC18F452, PIC18F4520, and the chips described on Jaromir.xf.cz pages. I did not think they could be there because there are "implemented" SFRs located at those addresses. However, when the Shadow bit of the Debug register is set while in debug mode, those overlapping "implemented" registers disappear and the breakpoint registers show up in their place. The one problem that kept me from seeing this was that the breakpoint value that is stored is half the address of the instruction upon which the breakpoint is set. This should have been intuitive to me since the addresses where the breakpoints are set are always even numbers, but since I had not reckoned with this, I was inadvertently setting my breakpoints at addresses that were effectively twice as large as I intended. The processor did not happen to pass through the erroneous addresses and that led me off on a wild goose chase. Thanks for any time you invested scratching your collective heads over this question.
NCR once refused to hire me because I was too short. I'm still waiting on my growth spurt.
User avatar
Joseph Watson
 
Posts: 49
Joined: Sat May 31, 2014 8:06 pm
Location: Ohio, USA
PIC experience: Experienced Hobbyist

Re: Hardware breakpoint registers in PIC18F2550

Postby Joseph Watson » Fri Sep 05, 2014 3:58 am

Hi Folks,

I am back with a bit more on this topic. Using the information at Jaromir Sukuba's website as well as info from the downloadable source files for QwikBug which were generated more than a decade ago, I did make my own in-circuit debugger for the PIC182550 which could no doubt be easily ported to other PIC18 chips. This debugger, called DBg, can be made to work with assembly language programs downloaded via a Microchip USB bootloader. However, currently it is not the most straightforward thing to set up. I should think it could be used with compiled programs as well but that is outside my area of knowledge with the PIC processors.

By keeping all the code that does anything in the debugger itself, I managed to make it work with very inexpensive hardware and only a terminal emulator in the PC which is where one directs the debug operation. The debugger requires about 734 (decimal) bytes of Flash.

If anyone is interested, a web page describing this can be found at http://www.angelfire.com/oh3/ebjoew/DBg.html

The web page endeavors to not only present the debugger but also tries to lay down a little more cleanly the known details about the undocumented Debug mode hardware in the PIC18 chips.

For those who are concerned about such things, that web page is not intended to show newbies the optimum way or the "right" way to write PIC programs. It is just how I wrote this one. Well, that is sort of true. I actually have my own set of mnemonics that I use when I write PIC code. If I care to publish my code on the internet for others, I translate it to the standard Microchip mnemonics.

Also, yes, I am fully aware that there is a good in-circuit debugging facility available from Microchip that is nicely integrated into their development system. I just like to keep things simple and where I have access to everything that is going on. If something does not work, I don't have to work around the problem while somebody far away eventually gets around to fixing it.
NCR once refused to hire me because I was too short. I'm still waiting on my growth spurt.
User avatar
Joseph Watson
 
Posts: 49
Joined: Sat May 31, 2014 8:06 pm
Location: Ohio, USA
PIC experience: Experienced Hobbyist

Re: Hardware breakpoint registers in PIC18F2550

Postby Tom Maier » Sun Sep 07, 2014 3:17 pm

It's impressive that you were able to do that. And everything is beautifully documented.

Good reading material, but I'm sticking with my pickit3. :D
User avatar
Tom Maier
Verified identity
 
Posts: 179
Joined: Mon May 26, 2014 2:37 pm
PIC experience: Professional 5+ years with MCHP products

Next

Return to 16-Bit Core

Who is online

Users browsing this forum: No registered users and 12 guests

cron