18F4520 - MPLABX 5.50 - Win 10 - PICkit4 received fresh from Microchip - pic-as 2.32

I tested my program in the micro and seems to run the desired main loop as I expected. However, when trying to look into some registers by debugging, "building for debugging" goes OK but, when when trying to "program for debugging" I get an error message.

The RB5 pin in this (venerable) micro, identified as PGM, is currently not connected to anything.

Current configuration here below (just in case, making LVP = ON) gives the same result. Puzzled to say the least myself.

Suggestions, I would appreciate them.

 

In project properties, verify that the debugger is PK4 in Connected Hardware Tool and that its serial number is shown.
To debug, start the build by clicking the Debug Icon (green arrow on the toolbar) instead of Clean and Build for Debug (the hammer and brush).
That's all I can think of..
Good luck.
EDIT: If PK4 requires LVP and you have disabled LVP in a previous high Vpp cycle (using just the two ICSP pins) you might have to re-enable LVP by programming the config bit in a trial build then ensure LVP is enabled on subsequent builds.
I love the 4520.

 

In project properties, verify that the debugger is PK4 in Connected Hardware Tool and that its serial number is shown. Duly recognized / identified.

To debug, start the build by clicking the Debug Icon (green arrow on the toolbar) instead of Clean and Build for Debug (the hammer and brush).
That's all I can think of..
Good luck.
Same results, Johnny

EDIT: If PK4 requires LVP and you have disabled LVP in a previous high Vpp cycle (using just the two ICSP pins) you might have to re-enable LVP by programming the config bit in a trial build then ensure LVP is enabled on subsequent builds. Whether I changed or not to LVP = OFF, the message below showed up. And whether I clicked Yes or No the result is the same.

How to check that my micro is being actually programmed as I requested with all those CONFIG ?

I love the 4520.

 

I seem to remember from somewhere (or I might have dreamed it) that DEBUG should be left OFF.

 

Hmmm... I'd let MPLAB do the config change.
I don't know about the DEBUG bit with the PK4 and later MPLABX with pic-as. I would think that any conflicts would be noted with a dialog like TS showed. I just ported an 18F to RealICE and it complained that I didn't have the various config bits set to allow debug. I let it do it once then edited the config file.
You should be able to inspect the config bits after a build or after reading the chip using PIC Memory Views -> Config bits. That will show the current image in MPLABX RAM. Or should..

 

I seem to remember from somewhere (or I might have dreamed it) that DEBUG should be left OFF.

Hmmm... I'd let MPLAB do the config change.
I don't know about the DEBUG bit with the PK4 and later MPLABX with pic-as. I would think that any conflicts would be noted with a dialog like TS showed. I just ported an 18F to RealICE and it complained that I didn't have the various config bits set to allow debug. I let it do it once then edited the config file.
You should be able to inspect the config bits after a build or after reading the chip using PIC Memory Views -> Config bits. That will show the current image in MPLABX RAM. Or should..

The configuration utility for this micro makes no mention of DEBUG (whether ON or OFF) at all.
Tried with or without, with no luck.

 

Grrr..
Make sure you are not trampling on reserved resources for the PK4 - memory areas that are used by the debugger. They're usually at the end of the memory spaces.

3 Reserved Resources
Due to the built-in in-circuit debugging capability of some devices, and the ICSP function offered by the debugger, the MPLAB PICkit 4 in-circuit debugger uses on-chip resources when debugging, i.e., some device resources are reserved for use by the debugger. For a list of reserved resources by device for the debugger, go to the MPLAB X IDE Learn & Discover page, Users Guide & Release Notes, and click on the links under Reserved Resources.

Were you able to verify the config bits?

EDIT: if you will post a sample pic-as code, I'll download MPLABX 5.50 and try it with a PK3/18F4520 (all I have) to see what's what.

EDIT EDIT: consider using MPLABX 5.10 which has MPASM. MPASM is a real assembler for assembly language programming. pic-as is not.

 

OK Johnny.
Off to the doctor in minutes. When I come back this afternoon I will reduce my current project to a small sample (which I also could test, by the way). Anyway I keep in mind that the program seems to work in real hardware.

¿Sure you cannot try mine as is? I could zip the whole and send it to you, duly scanned file by file prior to send it.

Sorry Johnny but the idea of going back to MPASM, makes me nervous. Too many things that are confusing me. The first time I had to think of low or high voltage programming and still ignoring most of the details...

 

Sounds good. It doesn’t have to be anything more than a simple loop with your configuration settings that I can step. Thanks.

 

Got some good news Johnny:
Your request for a simple loop inspired me to test it in my bench and ¡it worked! entering Debug mode as required.

My (extremely) shortened code is attached. Nor more nor less than my template.

BTW,

Grrr..
Make sure you are not trampling on reserved resources for the PK4 - memory areas that are used by the debugger. They're usually at the end of the memory spaces.

I'm afraid the problem is what you say above. Have to check that.

Things are moving. ¡Sí señor!

 

I'm afraid the problem is what you say above. Have to check that.

What did you find out?
Been busy with grandkids and EOY Corp. stuff but will take a look if you still need it.
Best,
JiTx

 

What did you find out?
Been busy with grandkids and EOY Corp. stuff but will take a look if you still need it.
Best,
JiTx

Hola Johnny

You man, spot on: code stepping on the debugger's space!!

Comments:

In my ignorance I believed that by clicking on the green debug arrow that space would be freed automatically for it, but no; discovered the necessity to do it myself. Instructed the linker with -Wl, -reserve=rom@0x7000:0x7FFF and we are in business. (Note: do not change nothing in the command but just the range, otherwise it is a syntax error). Took long to discover

The error message about config bits was actually related to the config bit LVP=ON. I made it OFF and straight we go to debug mode. Finally!

BTW, why with the so much space available, the assembler brings part of the code to the bottom (or is it the top?) is a mistery.

Result: in minutes I was able to verify that at least part of my code works as intended. Off for an espresso now.

A big Gracias Johnny.

 

BTW, why with the so much space available, the assembler brings part of the code to the bottom (or is it the top?) is a mistery.

I don't know either. Maybe to make space for the interrupt service routines.

While we're here, there is usually some RAM reserved for the debugger as well. I don't know if you can tell pic-as to reserve that or if your RAM assignment is absolute but I'd check it out.

Glad you're back on track!
Have a good one.

 

I don't know either. Maybe to make space for the interrupt service routines.

While we're here, there is usually some RAM reserved for the debugger as well. I don't know if you can tell pic-as to reserve that or if your RAM assignment is absolute but I'd check it out.

Glad you're back on track!
Have a good one.

If I needed I could reserve RAM, but I still have no clear idea (even recall reading that the RAM memory used is under control of the debugger but not available to the user). Still confused myself.

Today, when stopping for the day I will revise what MCHP says.

 

I took the liberty of checking it out myself (I use the 4520 and who knows, may use a PK4 someday).
Here's a PDF of the doc page that shows all the reserved spaces for normal debugging and the additional spaces needed for software breakpoints.
PK4 supports software breakpoints. Nice!