DEBUG on 18F4620

Hi,
Does anyone know why Debug does not compile without warnings on 18F4620? I am using PBP 2.46 with MPLAB 7.10 I have located the problem to the P18F4620.INC in MPLAB To make the program compile without warnings I must edit the file to remove the DEBUG Label used in the INC file

For the moment this solves the problem but the question is why have they done like this?

Mike
This is what the edited part of the P18F4620 file looks like
;=============================================
;
; Register Definitions
;
;===============================================

;----- Register Files -----------------------------------------
PORTA EQU H'0F80'
LOTS OF MORE DEFINES
OSCCON EQU H'0FD3'
;DEBUG EQU H'0FD4'
T0CON EQU H'0FD5'

If you do a seach for "DEBUG" in the pdf Datasheet for the 18F4620, you will see that the word is used as a reseverd word. It points to the configuration bit for the In-Cuircut Dubugger (Hardware). Not the same a PBP DEBUG, which is a simple serial command (PBP Software). Your solution should work neatly. Unless, of course, you decide in the future to use the ICD feature of the chip.

Steve

Mike,

Why use DEBUG instead of HSER? HSER uses the PIC hardware serial port, not the "bit-banged" software serial of PBP. The HSER ends up being much more effiecent, both in code space and execution time.

Steve

You know how it is, things tend to grow bigger and I am using the Windows method of programming ( if the code gets too big or too slow change the hardware) For the moment the USART pins are assigned to other I/O functions, maybe in the future if I have to change the PCB layout I might swap the pins to enable HSER functions. DEBUG gives the smallest code for the moment given the hardware used.

I thought reserved words in PBP were reserved words and not words MPLAB also wanted to use. What will we loose next time?

Mike

That's kinda interesting and i agree that some things could be changed to allow all feature, but usually it's a good practice to use internal PIC ressource instead than a software solution to, at least, save code space. For a such device (64K) i'm pretty sure there's a few thing that could be changed prior to say that DEBUG is the solution.

Sometimes i'm afraid what people do with PIC. Pretty sure than most of their own feature aren't used.
Why using PULSIN while you can use internal Counter?
Why using SERIN/DEBUGIN while you can use HSERIN?
Why using I2CREAD while your PIC have internal MSSP?
Why using PAUSE/US while your PIC have spare timer(s)?
Why using Sound while your PIC have spare CCP and allow your frequency range?
What is the real need of 20MHZ crystal while 4MHZ would be enough?
And so on...

Once done, you'll be amased how many project could be ported from a 8K device to a 4K (or less) memory device.

OK i heard some... sorry to say that.

Maybe we should talk to Microchip and ask them to make a PIC with NO internal hardware except A/D converter. Then they could spend all money on codespace :)

When selecting a PIC, functions, performance and price has to be matched. This DEBUG project became a bit big for a 16F877A and I only pay 2.5 USD more for the 18F4620 so why not?? As for using DEBUG in the new PIC, the idea was to reuse the old program without changing too much. Functions in PBP, as I see it, are here for the user to use, if you want small and fast write ASM.

The only change I had to do was some ADC settings and change in the MPLAB file, I am happy, my product is happy and the only thing to remember is to change the MPLAB file everytime I upgrade. This is also true for all the changes you have to do if you want the CONFIG settings to be included in you program but that is an other story. Maybe we really should talk to Microchip about some things.

mike

It just might be a good idea for somebody to talk to microchip about this one.

The DEBUG in the .inc file, does not point to the DEBUG config bit as one might expect. That bit is defined as ...
<pre>_DEBUG_ON_4L EQU H'7F' ; Enabled<br>_DEBUG_OFF_4L EQU H'FF' ; Disabled</pre>
Instead, it points to register FD4h.
<pre>DEBUG EQU H'0FD4'</pre>In the datasheets, FD4h is shown as ... 2: Unimplemented registers are read as ‘0’.

If it's an unimplemented register, why define it in the .inc file.

My guess is that it is used by the "ICD2 executive" program when in debug mode. And, I'm also guessing that the DEBUG equate, is in there by mistake, because the ...

P18F2525.INC
P18F25K20.INC
P18F2620.INC
P18F4525.INC
P18F45K20.INC
P18F4620.INC

files, all have the same problem. These chips all have the same basic Core, so the .inc files were probably just copies of each other, with small changes for each chip. Propagating the error along with it.

Perhaps if they knew about it. You might not have to make the changes after the next Upgrade. :)
<br>

BUT as it cause a problem to a third party software and not in their own... i guess they'll never do any change.

I don't have access to my ICD-2 here, but it would be interesting if someone can perform an ICD test and use DEBUG just to see how it goes on this PIC by commenting the DEBUG equate, and on ather PIC #... in the 18F serie wich the DEBUG_ON DEBUG_OFF fuses.

Also interesting, would be to disassemble the ICD2 Executive and see how many of those other Un-Implemented registers actually do something too.

DT

Just installed MPLAB 7.40 today... problem is still there. Have'nt access to my ICD-2 again.