Interrupts are being disabled and I don't understand why.

[E_Blue]

I'm trying to blink a LED with TMR1 interrupt but the interrupts are being disabled when I stop the program in debug mode. I'm seeing this on the Watch window.

When I hit the run button the program restarts.

Could be the MPLAB IDE?

The programs seems to work fine.

The device is a PIC16LF627. MPLAB IDE v8.92
_________________
Electric Blue

[temtronic]

I don't use 'debug' but know that code compiled for 'debug' is not the same as for 'release'. Learned that the hard way years ago as 'debug' was the default 'build configuration'. Contacted Microchip, they sent me a 'patch' so defualt would be 'release', so my problem solved.

I'm sure those that use debug can explain the technical details as to wat's different. Maybe dump the 2 listings as 'play computer' to see what code is different ?

[E_Blue]

I didn't compared but I searched if some instruction in the disassembling list were changing something in the INTCON or PIE registers and they don't.

If I leave the circuit without a breakpoint or if I doesn't halt the program manually and runs fine even in debug mode.

I think is some shenanigan with the ICD3, they probably "instructed" the ICD3 to disable interrupts so the interrupts doesn't interrupt the communication between the device and the ICD3 on halt.

I didn't tried to stop the program when run at 4MHz, maybe that change something. I will try it tomorrow.
_________________
Electric Blue

[Ttelmah]

Er. If you have 'stopped the program', then 'of course' interrupts are disabled.
The processor is _stopped_. It is sitting in the microcode used to handle
the debugger. When it is in this all main code is stopped.
The interrupts will still be triggering and setting the interrupt flags, but
no handler will be called until the main code is restarted. On some systems
this can cause a really nasty behaviour when you restart. The interrupt
triggers at the start of the instruction after the restart, but the handler then
returns to the instruction where the breakpoint is set. Result you are stuck.
The PIC does not do this, but some other chips do. On the PIC, it is the
first phase of the next instruction where the interrupt actually triggers.
This is the standard behaviour for debugging. You cannot have the code stop
at a breakpoint and carry on handling interrupts (actually some hardware
debugging tools could do this, but I've not seen one in years that can).
Some chips do support this, but not the PIC.

On some of the PIC's, there is an option in the debugger settings to make
the timers themselves 'freeze' when the chip stops.

[E_Blue]

I know that everything freeze on halt but Why the interrupt registers are not restored when I hit run again? Instead the program "continues" from PC 0x0000 not from the next instruction.
_________________
Electric Blue

[newguy]

Do you have the watchdog enabled?

[E_Blue]

No, in this case I don't.

[Ttelmah]

OK.
Obvious first thing, does the code run correctly if you don't have the
breakpoint?. If the breakpoint instruction is one causing a problem,
this could explain the behaviour.
Now the protection fuses, should not be enabled when developing. These
will be being turned off by the compiler, with debug being used, but as a
general rule do not use these till the code is finished. Having these set
if not actually debugging implies using extra lives of the program memory
when any change is made.
Is there any possibility that an external hardware event is triggering a
reset when the processor stops at the breakpoint?.
Look at your code listing. How many stack levels are used?. How much
RAM?. The debugger needs some resources (look in the help in MPLAB
to see how much). My suspicion would be that possibly you are
overrunning the stack when the breakpoint is called, so the code cannot
correctly return, or the RAM is running short.

[E_Blue]

I don't think that a hardware reset is being happening, the supply has 3A limit so, no brownout, the MCLR is with a pull up resistor and is handled only by the ICD3, there's no pin or external device that can reset the microcontroller.

Yes, the code runs fine if nothing stop it.

Here's the statistics of the lst file

ROM used: 182 words (4%)
Largest free fragment is 2048
RAM used: 13 (3%) at main() level
25 (7%) worst case
Stack used: 1 locations (0 in main + 1 for interrupts)
Stack size: 16
_________________
Electric Blue

[Ttelmah]

OK.
That rules out the RAM and stack...

I have a nasty feeling this might be an issue with ICD3, and MPLAB 8.92.
The development of MPLAB was grinding to a halt when the ICD3 came
out. There are quite a few threads on the MPLAB forums, with people
having issues with the later chips and the ICD3 on MPLAB.

Microchip did publish some notes about errors at this time:
[url]
https://microchip.my.site.com/s/article/How-to-troubleshoot-ICD3-errors
[/url]
It might be worth trying the manual firmware update outlined here.

[E_Blue]

Thanks, for the info. I'm finishing the code and in a bit of rush now, so I will test this on weekend, just to get some personal knowledge.
_________________
Electric Blue