Reset caused by MCLR from RUN PIC18F87J60

[JerryR]

Hello Group:

Using a PIC18F87J60 based target and compiling code from MPLab*x IDE using CCS PCWH version 5.064.

I am having intermittent problems with a reset caused by MCLR from RUN. This issue begins usually with my adding code to the project and is very similar to the thread:

https://www.ccsinfo.com/forum/viewtopic.php?t=35705&postdays=0&postorder=asc&start=0

The above thread ended without a fix stated.

The MCLR pin is pulled high through a 10K reisitor to 3.3 volts and appears clean. Vcore is bypassed using a 0.1uF and 1.0uF capacitors close to the uC. Vdd is also bypassed using 0.1uF capacitors.

Really the issue seems to be code-related. Usually, removing added code results in the problem being fixed. CCS C reports ROM usage at 34% and RAM useage at 27 - 28%.

Is there any way I can disable MCLR resets during run to help troubleshoot the issue?

Could the code added be causing the issue? I appreciate the group's help.

[JerryR]

Another observance- Problem is not apparent when I program the target. Problem only exists during debug! Just found this to be the case. Thanks

[PCM programmer]

Read this post by Ttelmah, about checking for stack levels, and about
how debug mode reduces the available stack:
http://www.ccsinfo.com/forum/viewtopic.php?t=54575&start=5

There are lots of good threads on this topic, search for:

[JerryR]

Thank you PCM I shall!

[Ttelmah]

The fundamental problem here is that 'MCLR from run', only actually means that the pattern of bits reflects this happening. If you arrive at the start of the code by some abnormal route, then you can get this reported as 'MCLR from run', though this is not the real cause.
You can't disable MCLR except on chips that offer this as a fuse option. Even then in fact the pin can still cause a reset, if the signal goes slight above Vdd.
Set yourself some markers to find where the problem is happening.

Declare a global variable and do not initialise it.
Have a macro that sets this to values, and scatter this through your code.
On boot, look at the value in this. It'll reflect what was loaded by the last macro it reached before the problem.
First, if the value varies, then you probably have a genuine MCLR.
Then if you have a fixed particular value, you can narrow down, by adding more values close after where this one is loaded, till you find exactly where the problem is appearing.

[JerryR]

Ttelmah: Good suggestions! I've done a similar thing by setting a trap at the start of my MAIN routine if a restart_cause= 15 occurs. Then set breakpoint in the code to see if all executes before a reset_cause = 15 occurs. Unfortunately, this thing is so intermittent, that it's hard to get it to occur consistently enough to trace. Yes, after studying the data sheet, I see the issue can be caused by code sending the PC back to zero.

I first blamed the issue on noise on the MCLR line, but scope says no, it's a clean 3.3V.

Other info: Problem does not occur if I program the target and run and hasn't occurred since I switched from a PICKit 3 to an ICD-3.

I'll try your suggestion and put number around in code to see if I can trace it that way. Thanks so much for your interest in my problem. Best regards!