DEBUGGING A 14 PINS PIC WITH MPLAB-X

[Animok]

Hi guys.
I am trying to debug a PIC16F1574 (14 pins) WITH MPLAB-X V5.35.
The problem is that the break points are broken and debugging does not stop at the selected points.
I've tried everything, maybe it's nonsense, but I don't see an explanation, especially when all the technical information says that debugging is possible.
Any ideas?
Thanks in advance to everyone .
NOTE: The problem is repeated with other 14-pin PICs such as the PIC16F18424.

[dyeatman]

What version compiler? What version of MpLab plugin?
_________________
Google and Forum Search are some of your best tools!!!!

[Ttelmah]

More importantly, what ICD unit, and what firmware in it???
I have seen issues in the past like this with particular units and firmware.
There is also an issue, the firmware for many of the ICD's was updated
to be compatible with MPLAB 6. This can cause issues with MPLAB 5.
It may be worth seeing if you can downgrade your ICD to the last
firmware that was done for use with MPLAB 5.

Also how is grounding done?. Is this a laptop (hence floating), or a
traditional PC (metal chassis). If the latter you might have a ground loop
if the supply to the ICD/board is also grounded. Is the board you are
using for the 14 pin chips different from the one you use for larger chips?.
Do you get any form of error displayed?. What happens if you single step?.
Try adding a 'nop' (delay_cycles(1);), and putting a breakpoint on this.

Understand the compiler and pul-in have np effect at all on debugging.
The debugging is completely done by MPLAB-X. The compiler merely
generates the code which MPLAB then feeds to the chip and debugs.

[Animok]

Hello again and thanks for responding.
I have certainly omitted the following important information:
- PICKIT-4
- CCS 5.112
- PIC16F1574 (recent attempt).
- MPLAB-X 5.35
I have debugged other PICs without problems in this environment, but they were not 14 pin.
What am I missing?

[temtronic]

I don't use MPLAB-X, but when you compile the program , are there 2 options, Debug and Release ?
The original MPLAB has those and it'll generate different code .

I'm probably wrong and I'm sure someone will reply soon.

[Ttelmah]

First, you have not answered about how the system is actually connected?.
Also not told us what is actually happening?.
Now, check and update the firmware.
In MPLAB, create a new project, selectng Pickit 4 as programmer. Then
select the configuration, and the tool pack options. Select use specified
tool pack, and you can then select which firmware to load to the Pickit.
It is _vital_ that the firmware in the Pickit 4 matches what your version
of MPLAB X requires.
Also keep the connections to the device from the Pickit short, and use
a short USB cable to the Pickit.

[Animok]

Thank you all, but I am going to consider debugging the 14-pin PICs impossible.

Below is the code I am using:

#include<FUSES-16F15323.h>
#include<SFR-15323.h>
//************************************************
unsigned int8 av,testart,tesleep,temperok;
//************************************************
void main()
{
TRISA=0B00000000;
TRISC=0B00110010;
//************************************************

RA2=0;RC0=0; //Off.
delay_ms(5000);
RA2=0;RC0=1; //GREEN LED
//------------------------------------------------ ------------------------------------------
COMIE:
av=0; // HERE I PUT THE INTERRUPTION!
RA2=1;RC0=0; //RED LED
goto COMIE;
//------------------------------------------------ -------------------------------------------
} //END OF MAIN.
//************************************************

FUSES-16F15323.h:

#include <16F15323.h>
#device ADC=10
#FUSES NOMCLR //Master Clear pin used for I/O
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOPUT
#use delay(internal=8000000)

**********************************
SFR-15323.h:

#nolist
#WORD PORTA=0X00C
#WORD PORTC=0X00E
#WORD TRISA = 0X012
#WORD TRISC = 0X014
//-----------------------
#BIT RA0=PORTA.0
#BIT RA1=PORTA.1
#BIT RA2=PORTA.2
#BIT RA3=PORTA.3
#BIT RA4=PORTA.4
#BIT RA5=PORTA.5
//----------------------
#BIT RC0=PORTC.0
#BIT RC1=PORTC.1
#BIT RC2=PORTC.2
#BIT RC3=PORTC.3
#BIT RC4=PORTC.4
#BIT RC5=PORTC.5

#list
*************************************************
MPLAB-X 3.5 = MPLAB- 5.5 = FAIL.

About my breakpoint, MPLAB-X shows:
"cannot be resolved to a valid program memory address"


Regards

[Ttelmah]

The message is completely correct!.....

That is why I suggested you try the delay_us(1) and putting the break there...
What is happening is that the av=0 line is being optimised away, since av
is already zero, and the compiler knows this, so optimises this line away,
hence the line is not there to break at.....



Nothing wrong with the debugging at all.

[temtronic]

hmm,curious.....

"AV is already zero"

I've always thought that RAM, being 'static CMOS', could be anything when power is applied, so you need to use AV=0; to be sure AV really IS 0.
CCS does have #Zeroram , which will force all RAM to zero.

I'm wondering if the compiler does a 'zero ram' ?

[Animok]

Thank you for your answers.
But it has been IMPOSSIBLE for me to use the break points with MPLAB-X on any 14-pin PIC.
If anyone has achieved it, I would appreciate it if you could tell me which Pic you used and your code example and configuration bits.
XC8 DOES execute interrupts on these PICs.

Greetings

[Ttelmah]

You are right, but the compiler is smarter and sneakier than you think.
It sees the line av=0, and replaces it with an initialisation when the
variable is declared. So the inline code vanishes....
Not obvious unless you look at the assembler it generates....