Hardware breakpoint registers in PIC18F2550

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

Re: Hardware breakpoint registers in PIC18F2550

Postby SLTom992 » Mon Dec 15, 2014 12:37 am

That was my feeling as well. The debug equipment for the PIC's is so cheap and readily available it seems like only a practice to make another debugger.
SLTom992
 
Posts: 58
Joined: Tue Jun 10, 2014 8:59 pm
PIC experience: Professional 1+ years with MCHP products

Re: Hardware breakpoint registers in PIC18F2550

Postby Ian.M » Wed Dec 17, 2014 4:17 pm

I agree its fairly pointless *UNLESS* you want to be able to debug on a computer that isn't Intel PC architecture, or over a network without needing a full PC you can RDP or VNC into at the target board end etc. Its also the sort of thing that could be of interest to SourceBoost plugin developers as it might give the possibility of adding hardware debugging to that IDE.
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 jaromir » Fri Jul 29, 2016 9:35 pm

Hi guys, jaromir from http://jaromir.xf.cz/ here. I'm reliving this old thread to put all the information on single place - for the (perhaps a bit unlikely case) someone would be interested in the topic and add a few more details than I wrote in here http://jaromir.xf.cz/hdeb/goals/goals.html

Let's start with quick Q and A:
Q: Why on earth would you do your own debugger, when official tools work just fine?
A: Because I can. And because it's fun, discovering something new is amusing. Yes, it is completely pointless, but that's the point of hobby work. I have to do logical and needed things at work, all the time. For my hobby time I reserve my spare time to do all kinds of useless crap, it it makes me fun. Did I tell you I made my own cell phone, digital camera or GPS receiver? Oh my, such as waste of time!

The debugger project goes all the way back to year 2010 or so. I thought like it could be just fine to have small handheld device, being able to program another PIC with specific FLASH image. Well, that's somehow boring, so I thought of adding binary editor, able to change the image. With opcode list at hand I could enter and load programs of target PIC in machine code - the same way as you did it in 70's/80's in KIM-1 or similar entry-level computer kits. Being born in mid 80's - I was too late to experience it in my youth. Consequently, my thoughts lead me to ASCII editor to enter programs in assembly language, on board assembler could translate it to machine code. Now that starts to look like complete toolchain. I built such as device, sporting PIC18F2620 as brain of it and another PIC18F2620 as target device. User interface was 4x4 (plus few function keys) keyboard, with layout as on old cell phones and 98x64 graphical LCD, giving me 16x8 characters of 5x7 font. The whole thing fit into a few kilobytes of FLASH and worked just fine, but there was something missing. Actually, two things: high level compiler and debugger. Unfortunately, HLL compiler, like C or Pascal was completely out of my reach - I had no idea where to start. Assembler is fairly easy, just chasing strings and spitting out binary values; but compiler was completely different story. So I decided to make some debugger.
It was not easy thing to do, as Microchip doesn't make any documents public. The only thing officially available is debug register description of PIC16F877 - the rest of it had to be guessed, resulting in rudimentary description as here http://jaromir.xf.cz/hdeb/bdm/bdm.html
I implemented the debugger into PIC18F2620, but it started to show it's weak points, like too little RAM and somehow 8-bit architecture. So I took dsPIC33FJ128GP802, the biggest RAM PIC MCU in DIP package, ported all software components (editor, assembler, programmer, semi-finished debugger) and finished it into single monolithic package. The result is to be seen here http://jaromir.xf.cz/hdeb/desc/hdeb_desc.html
At the time (winter 2011/2012) Designspark started a contest, aiming at then new chipkit32 board with PIC32 MCU. So, I ported the debugger again, to PIC32, result of it was PIC Programmer, fourth revision - PP04.
PP04 included a lot of redesigned software. The menu-driven interface working above linear memory space was thrown out and I implemented command-line driven "operational system" working above FAT32 filesystem - I must admit I was slightly inspired by GNU bash, though my CLI is far far from being as powerful. You can now use commands like ls (ls *.as to list all files with "as" extension), cp, md or rd to operate with files and directories. You have simple ED editor to edit, AS to assemble files, PG to program and DE to debug the target PIC18 formware. To have more fun, I added simple BASIC and BF interpreters.
More info about PP04 is to be found here https://hackaday.io/project/1757-pp04-camel-computer, notice also the download section with complete documentation and C source files. Beware though, my coding style is far from perfect and at the time was even worse. Comments are rare, organization is messy and code not very self-documenting, You've been warned.
The original Designspark contest disappeared from their website, along with the documents, so I made the public display at hackaday.io site. If there is anybody else to make mirror of those documents/projects, feel free to do so, just let me know.

The debugger itself is no rocket science you understand how it works. Though the understanding took a lot of time and effort, nights spent with oscilloscope and logic analyser to chase bugs in debug executive or debugger itself.
First of all, it loads user program as usual with one difference - all code protect bits are disabled and DEBUG bit in configuration word is programmed to 0 = enabled. Plus, debug executive has to be added, but I'll get there later. From now, the device enters debug mode every time when there is transition 1->0 on RB6 pin, reset happens (those two can be induced from debugger at any time) or breakpoint is hit/single step is done (those two are possbile after previous debugger action). The actual debug mode is nothing but kind of "interrupt" with vector at 0x200028 and special program, called debug executive has to treat all the debug actions and bitbanging serial communication via RB6/RB7 pins to debugger probe. More details are here http://jaromir.xf.cz/hdeb/bdm/bdm.html
I wrote the debug executive programs in assembly language, as it has to be very compact and every byte matters here.

My approach is somehow different from what Joseph Watson did - he debugged program entered by bootloader, so you have to program the bootloader first. I considered this one too, but it slightly limits its usability. I wanted "real" debugger, doing all required actions even with unprogrammed "virgin" PICs and via only two pins RP6/RB7. I love to make things harder ;-)
Anyway, Joe's work is great and I'm glad not being the only one fiddling with undocumented features of PIC18.
some of my projects http://jaromir.xf.cz/
more of my projects https://hackaday.io/jaromir
User avatar
jaromir
Verified identity
 
Posts: 9
Joined: Thu Jul 28, 2016 7:16 am
PIC experience: Professional 5+ years with MCHP products

Re: Hardware breakpoint registers in PIC18F2550

Postby NorthGuy » Sat Jul 30, 2016 4:18 am

Very interesting. I'm working on similar things myself, and while I was working on debugging I came across this thread and found a link to Jaromir web page and read it, and found it very informative and well written.

I started working on a development tool in 2013. I wanted to build a system that would let easily and efficiently re-use code. The idea was very simple: you write a module (task) which does something, them you just throw any number of these tasks together, assign pins and it is all done. The tool ensures proper timing and scheduling, organizes multitasking and such. The existing compiler-linker chains didn't look very friendly for this approach, so I decided to write my own and make it available to others. I have already went great distance.The beta version will be done by the end of the year.

The original idea was to build everything in software - compilers, configurators, simulator with no link to real hardware. But this approach looked somehow incompete to me, so in the beginning of 2015 I decided to see if I can make a hardware programmer.

As a result, I spent all of 2015 working on the programmer/debugger for PICs. It now supports pretty much all PICs which have LVP. I managed to squeeze all the necessary software for programming and debugging all PICs into PIC16F1454 and it works very well - faster than ICD3 actually. I used all my own debug and programming executives. I wrote all the programming software - graphic user interface and command lines. However, there is no plans for the command line debugger.

I wish I could share the code and stuff - I like what I did and it would be fun to share. However, this is a commercial project which is supposed to bring me income some day, so I cannot do this. :( My web site is http://www.northernsoftware.com/
User avatar
NorthGuy
Verified identity
 
Posts: 17
Joined: Sat Jul 30, 2016 3:08 am
PIC experience: Professional 2-5 years with MCHP products

Re: Hardware breakpoint registers in PIC18F2550

Postby jaromir » Tue Aug 02, 2016 1:43 pm

northguy:
Now this is what I call interesting project! Too bad you can't release the sources (what I fully understand), but I'm definitely interested seeing/testing this project once finished.
some of my projects http://jaromir.xf.cz/
more of my projects https://hackaday.io/jaromir
User avatar
jaromir
Verified identity
 
Posts: 9
Joined: Thu Jul 28, 2016 7:16 am
PIC experience: Professional 5+ years with MCHP products

Re: Hardware breakpoint registers in PIC18F2550

Postby NeilKeiding » Tue Aug 09, 2016 5:10 pm

Hi..as per my knowledge 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.
[ spammy PCB links removed by admin ]
NeilKeiding
 
Posts: 1
Joined: Sun Aug 07, 2016 7:25 pm
PIC experience: Experienced Hobbyist

Re: Hardware breakpoint registers in PIC18F2550

Postby jaromir » Wed Aug 10, 2016 11:16 pm

Did you read my posts here? Joe did refer to http://jaromir.xf.cz/hdeb/bdm/bdm.html as well. You may also find useful this one https://hackaday.io/project/1757-pp04-camel-computer
some of my projects http://jaromir.xf.cz/
more of my projects https://hackaday.io/jaromir
User avatar
jaromir
Verified identity
 
Posts: 9
Joined: Thu Jul 28, 2016 7:16 am
PIC experience: Professional 5+ years with MCHP products

Re: Hardware breakpoint registers in PIC18F2550

Postby Joseph Watson » Mon Aug 29, 2016 10:37 pm

I am sure Jaromir will find this interesting as perhaps will some others. It concerns the list of ways that a PIC18 can be triggered to enter its debug mode, that is, with the INBUG bit turned on in the undocumented DEBUG register at 0xFD4. The already known ways consist of:

1. A high-to-low transition input into the RB6 pin
2. Power-On-Reset or MCLR Reset signal
3. A breakpoint being encountered
4. Following execution of an instruction with the single-step bit set in the Debug register

I seem to have found one more way.

I was playing with a PIC18F4620 chip and wanted to enable debug mode operation by setting the configuration registers for no code protection in any memory blocks, clearing the Debug bit of Config4L to zero, and storing an appropriate GOTO command in the debug vector at 0x200028. I was using MPLAB IPE to drive my PICKit 3 for programming the PIC chip. While the IPE was willing to program the PIC for no code protection, it did not want to program the Debug vector at 0x200028 nor clear the Debug bit of Config4L.

So I wrote some code to run in the PIC to set up the Debug vector and to clear the Debug bit of Config4L. I figured at the conclusion of that code, the PIC would still be in user mode, not debug mode, and that is exactly the way it was. Initially, I ended this sequence with a BRA $ command so it would just sit and wait for me to press the Reset button on my little PIC system. Pressing the Reset button did cause the PIC to enter its debug mode and assert the INBUG bit of the Debug register.

I kept wondering if there might be something else I could do to trigger it to automatically enter the debug mode after my little program set the Debug vector and cleared the Debug bit of Config4L. I tried using a software RESET command but that did not work. Then, of all things, a simple BRA 0x0000 did the trick. I tried branching to a couple of other addresses but none seems to work except branching to address zero.

This may just be an unintended serendipitous effect caused by the internal hardware design of the PIC but it does seem to work for me. I have since duplicated it on a PIC18LF4620 as well.

(By the way, now that I think about it, setting the single-step bit in the DEBUG register might have worked as well but it seems like more fun to discover something new.)
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 viya0414 » Fri Nov 24, 2017 7:52 am

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.
[ spammy PCB links removed by admin ]
viya0414
Banned
 
Posts: 1
Joined: Fri Nov 24, 2017 7:44 am

Re: Hardware breakpoint registers in PIC18F2550

Postby Joseph Watson » Mon Dec 04, 2017 8:11 am

Go back to the start of this thread and read through it. You will find out how to access the hardware breakpoint registers.
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

PreviousNext

Return to 16-Bit Core

Who is online

Users browsing this forum: No registered users and 13 guests

cron