Hardware Tool Debug Features by Device - Help with Microchip MCUs

[ez24]

Hardware Tool Debug Features by Device chart:

http://ww1.microchip.com/downloads/en/DeviceDoc/HWToolDebugFeatures.pdf

I do not understand most terms used.  Does anyone know of any resource that I can read to learn what these terms mean?

I am interested in what debug features the PIC16F18875 has

thanks

[Ammar]

BPs stands for Break points. You can put break points into your code to check the state of your device at that point in the code.

Pass counter: Probably lets you know how many times your code has passed a certain point before a break point.

Clock switch break: Many MCUs have several clock sources. Will stop execution when it switches clocks.

Stop watch: Probably measures the time between execution and a break point.

WDT timeout break: Look up watch dog timer.

etc...

Are there any in particular you want to know about?

[H.O]

I do not understand most terms used.  Does anyone know of any resource that I can read to learn what these terms mean?

Have you tried the last page of the document itself? Or are you looking for a more in depth explaination?

[hans]

In general; the most basic breakpoint is on a particular line of code. You set a breakpoint in the IDE, and if the controller wants to execute that line it will halt and allow you to step through the program.
A subset of that is not execution of a particular line of code, but access to a particular memory address. Some controllers can also distuingish between read and write. This is especially useful if you want to check what code sets a particular value to a variable which you don't understand, or possibly what call is causing data spillage (like some unbounded operation).
Range BPs are another subset of that; instead of breaking on 1 particular address it can break on a whole set of addresses, like an array.

Tuple and sequenced BPs are more complex breakpoints. Tuple can be nice if you want to break only under certain conditions. Like only break at this line if this condition is true. Sometimes you can also write this is in code (just break inside the if statement), but if you have some really tight timed loop this can be an useful feature.
Sequenced BPs are same deal, but useful to break on certain program flows.

Tables are used on PIC for FLASH/EEPROM access, so I suppose table BPs are related to reading or writing non-volatile data.

Pass counter is part of complex breakpoints. In this case you don't want to break on every occassion but only e.g. at the 3rd time it passes.

Sleep on wake, stack over/underflow, WDT, clock switch breakpoints are also quite obvious. These are 'events' in the chip that can cause a reset or some code execution that you sometimes want to debug from the very first moment it happens.

Software breakpoints can be used if there are not enough hardware breakpoints. Most chips only have like 3-6 hardware breakpoints, which can be used up very quickly on even a moderate complex project. With software breakpoints instead it will recompile sections of your program to evaluate and check the breakpoint conditions in software. This is ofcourse somewhat slower to execute.
The abscence or limitations of such a tool can be a reason to develop complex business logic like protocol stacks on a PC.

The Real ICE emulator has a few nice instrumentation features like trace, data capture and live watch. It's unfortunate though that live watch is not available on the lower end chips&debuggers, because it's so nice to have a simple integer display some internal state of your program while it keeps running. This can sometimes be emulated in code via a serial console, but the debugger just tapping of some memory is much more convenient to set up.

Quite surprised to see, to be honest, that the PIC32MZ does not support some of the debugging features that are present on the PIC32MX. For example software breakpoints is a pretty big miss.

[ez24]

Thanks everyone, I ordered a PIC 8 bit Curiosity board

http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=DM164137

which has PIC16F1619

And by Jan 2017 this one is suppose to be available:

http://www.microchip.com/developmenttools/productdetails.aspx?partno=dm164136

which has PIC16F18875

And here are the debug features of the PIC16F18875 :

Prog/Data BPs    -   1  Total   -  This is a big surprise for me.  I would have thought unlimited so something is going on that I do not know  - is it possible this means Hardware BP  and I am thinking of Software BPs ?

Data BPAccess   - R/W     -  My guess is this mean that some data can be stored somewhere with the BP happens

Tuples (ANDed BPs)  -  0  -   Since this is NA for my chip I think I will put this on the back burner but sounds useful

Sequenced BPs   -  No   -   same as above  - bummer

Range BPs  -  N/A     -  same as above

Table R/W BPs  -  No   

Pass counter  -  Yes  -  In this case you don't want to break on every occasion but only e.g. at the 3rd time it passes.  -  Sounds useful

Clock switch break  -  No

Sleep wake break  -  No

Stack over/under Break  -  Yes  -  ?

WDT Timeout Break  -  No

Stopwatch  -  No

Debug reads -  Yes:RI  -  Yes:ICD3  -  N/A:PK3    - 

Whops I just noticed these facts are for different programmers so none of this may apply to Curiosity boards  -      So I think "Device"  means the programmer not the chip like I thought at the beginning        

So here I stop and wait until I get my Curiosity and work on it and I guess I will have to figure this out myself

I have read the docs on the Curiosity and there is no mention of any of this.  Looks like it will be learn as I go   

Now a strange thing:

I googled "pic curiosity debug features"  and the first hit is the Curiosity page but here is a quote that shows up on the search page:
 "Its key features include real-time instruction trace, background debug and up to 32"  but when I go to the page there is nothing regarding this.  Even searching the page for some of these terms shows nothing.

I wonder what 32 means?  Doing a search on the search comes up with:  "32 Runtime Data Watch points"  and  32 MHZ

32 Runtime data watch points sounds good ?

Once again thanks to everyone that answered and I will print out the answers and use them as a reference 

[hans]

The features you listed make debugging via an IDE a joke. Debug features on PIC16 are really not that great to be honest.

The issue is that code stepping uses 1 breakpoint under the hood. It will set one on the next line, run the chip and then wait for that breakpoint to hit. You need to have 1 breakpoint open for code stepping to work. If you only have 1, you cannot code step while having a breakpoint set somewhere. Not forgetting to enable that single breakpoint (which is limited as it is) when you want to run your chip is very troublesome to say the least.

MPLAB will give a suggestion what you want to do at that point. Usually you will have to disable the breakpoint and don't forget to reenable it once you're done stepping.

Nevertheless some of the old ARM7TDMI chips also only had 2 breakpoints implemented. For those chips I really liked the Jlink debugger because it had excellent software breakpoints supported in the tool, and would reprogram the chip in no-time (like <0.5s!) if you exceed the limit without having to do anything. It's really easy to get spoiled with half a dozen or unlimited (PC) breakpoints. When I didn't had access to a Jlink at some point and needed to do some work on the ARM7TDMI chips, that moment of realization struck..

Microchip's 8-bit Emulation Extension Paks offer a variety of advanced emulation/debugging capabilities to assist customers with their tough code debugging jobs. Its key features include real-time instruction trace, background debug and up to 32 hardware address/data breakpoints.

After looking at the page html, this description is in the site dropdown menu (Design Support -> Development Tools -> Emulation Extension Paks) and not part of the curiosity boards. It just happens that you combined curiosity and debugging and Google thought this is an interesting quote.
AFAIK such features are limited to the Real ICE debugger and for the higher end controllers. And yes, if you're serious about debugging one of those PIC16s you should probably get one of those emulation paks and REAL ICE. Will cost a fortune though, so not really economical for low volume stuff. That's why I don't bother with small chips; as I said I got spoiled with big PICs and ARM chips.


Data and instruction trace is a means of dumping a raw log of data and instruction point values so you can have live watches (like I described) but also debug crashes in more detail. You can get a log of what instructions were executed prior to a breakpoint or crash. That can help immensely if you have no clue what triggered it and symptoms are vague to say the least. Oh.. the bugs I've spent days finding the issue. Would probably have been fixed within an afternoon using a trace option.

Again, nice feature.. but it's like as nice as an 1GHz scope. Nice to see, yes I want to have one, but I don't really need one daily.