MCLR reset due to programming logic?

[santosh.manicka]

Hello all,

I am, just like most people who join this forum, is in dire need of help!

I am using a PIC18F6722 and my program resets due to MCLR_FROM_RUN (return code = 15).

The problem started occurring after I added code to an already existing whole bunch of code. I initially thought that the problem was due to lack of memory because the original code had occupied 71% of ROM and about 80% of RAM. So, I reduced the memory by a huge margin by commenting out 'large' variables and the problem was temporarily resolved.
After about half hour (during which the hardware was switched on and was performing an 'idle' while-loop), I triggered it to execute my new logic again and this time, the program reset.

Likewise, the following actions also helped resolve the problem temporarily-
1. Insertion of a few fprintf statements that sent across data on its one of the two serial ports
2. Increased/Reduced the size of the memory occupied by data on the eeprom

I understand that MCLR pin is an external program reset pin on this chip. So, what I don't understand is how a change in code affects the MCLR pin -- OR is it just a random coincidence??

Anyways, is there a generic fix for MCLR reset issues? I HAVE TRIED #FUSES NOMCLR too but it doesn't seem to have any effect at all!!

Cheers folks. Your help will be greatly appreciated.

[santosh.manicka]

Just a follow-up .... I added another frpintf statement to display the values of a couple variables on the serial port and the program reset due to brownout!!

[Ttelmah]

What compiler version?.
What is actually connected to the MCLR pin?.
MCLR, will cause a reset, _even if disabled_, if you are getting certain types of noise on the MCLR pin. The pin lacks the normal protection (since it also feeds the Vpp voltage). Disabling the MCLR fuse, turns off a FET connecting to the reset circuitry, _but_ this can still conduct if the incoming voltage goes outside the supply range. MCLR is also the event you will get if the supply falls below the operating minimum.
I'd be most suspicious that your new code is introducing noise on the pin, or supply ripples...
'MCLR from run', is exactly what you will see, if you jump to address 0. It's definition, is arriving at address 0, with all the power status bits 'unchanged' from their normal 'running' state.
However 'brownout', implies the BOR flag goes low, and this is a hardware triggered event.
Are you testing the restart_cause right at the start of the code?. If not, it can give an incorrect value.
What decoupling have you got close to the chip?. How is the ground rail laid out?. How is the supply derived?. What is the chip actually controlling?. etc. etc..

Best Wishes

[santosh.manicka]

Thank you for the reply.

I am an electronics naivete. So, I am not able to reply to a lot of questions you have asked. Right now I am trying to find if there COULD BE anything wrong with the software. So, if you suspect noise caused due to my code, would you say that its something wrong with my logic like memory overflow/overwrite etc...or would you say that the hardware should normally have sufficient safeguard against such noise, so the h/w still needs to be fixed?

[santosh.manicka]

The compiler version is 4.
The programmer is connected to the pin.
I actually used to run the program with the programmer connected to it. After I removed the programmer, the MCLR reset does not seem to occur (at least for now) but brownout happens and even a power-up reset (as if the hardware is powered up) happened today when the program was running.

[Ttelmah]

The version will be something like 4.056
Three digits _after_ the main version number. If the version number is below perhaps 4.035, then there were some major problems with the compiler.
However it does sound like your board is not properly decoupled. Can you post a circuit diagram for the processor as a picture we can look at?.

Best Wishes

[santosh.manicka]

The compiler version if 4.074
Here is an link to the circuit diagram-
http://www.esnips.com/doc/199b3da5-89b6-4ecf-ba33-6fb9a7f4736e/CircuitDiagram

Sorry, I couldn't figure out a way to post the pic here. You will have to download the file...
Cheers!

[santosh.manicka]

Another update -
The brownout seems to occur if there is a #fuses NOMCLR.
If the MCLR is enabled, only MCLR reset seems to occur and not brownout.
If the brownout is also disabled, then there seems to be a very high current supplied to the motor (see circuit diagram).

[PCM programmer]

See the diagram about halfway down this thread, which shows the
preferred circuit board layout for the motor circuit:
http://www.ccsinfo.com/forum/viewtopic.php?t=32927

[PCM programmer]

Also, your PIC schematic only shows two decoupling capacitors (and it
doesn't show the value). There should be one cap per Vdd (or AVdd)
pin on the PIC. Each cap should be placed very close to the PIC Vdd
pins. There should be a immediate connection to the ground plane
by each cap. The caps should be 100 nF (0.1 uF) ceramic.

[santosh.manicka]

Thank you for the suggestions!

None of the problems I mentioned earlier seem to occur when I comment out certain parts of the code (small sections though) that contain math operations like sqrt, pow, atan and floating point divisions. If that is the case, would you think there could be workarounds on the software side (like special compiler directives etc..)? My problem is that the guy who can help me fix the hardware is not around and I can deal only with software.

Cheers!

[PCM programmer]

1. If you are missing basic things, such as a bypass cap on every Vdd
pin, and proper power and ground layout for a motor circuit, the operation
can be erratic. It may appear to be code dependent, but you have to
clean up the basic hardware design first. Then worry about the code.

2. Post your #fuses statement.

[santosh.manicka]

Thanks a ton!!

#FUSES NOWDT //No Watch Dog Timer
//#FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
//#FUSES H4 //High speed osc with HW enabled 4X PLL
#fuses INTRC
#FUSES PROTECT //Code protected from reads
#FUSES IESO //Internal External Switch Over mode enabled
#FUSES BROWNOUT //Reset when brownout detected
#FUSES BORV27 //Brownout reset at 2.7V
#FUSES PUT //Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES NOSTVREN //Stack full/underflow will cause reset
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOWRT //Program memory not write protected
#FUSES NOCPB //No Boot Block code protection
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES LPT1OSC //Timer1 configured for low-power operation
#FUSES MCLR //Master Clear pin enabled
#FUSES NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#FUSES BBSIZ1K //1K words Boot Block size

[PCM programmer]

I don't see anything wrong with your fuses, except that I wouldn't use
PROTECT during development.

[Vintermute]

(I'm the guy who developed the hardware)

The motor power come into the board on a pin header and splits in two, one goes straight to a 5v regulator and the other to another pin header to a second board containing the motor driver. There are actually two power input headers, connecting to one means the PCB traces go to the regulator first, then the motor. Connecting to the other means the traces go to the motor first, then the regulator.

(Santosh, use the power connector marked secondary to get the power supply correct as indicated in the diagram that PCM Programmer linked to)

The capacitors in the circuit diagram are all 0.1uf ceramic. Unfortunately only one of them is close to the VDD pin, all are connected to a ground plane. The other polarised capacitors are all 10uf tantalum. The VReg is rated for 500mA and the motor stall current is about 800mA. It is not an ideal design but has proved reliable so far.

I have exactly the same hardware on my desk at the moment but so far I haven't replicated the problem (I haven't had much time though).

My first guess, given that the problem only presented after the hardware has seen quite a lot of use, is that either the voltage regulator is getting hot and failing, or that the power supply (a 12v plug in regulator) is failing.

There were some unusual (erratic) code problems that santosh had with a variable changing state for no apparent reason - this was fixed by moving the variable declaration to a different location !!! there may be a combination of compiler issues and hardware issues to contend with.