Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

MPLAB reset weirdness

Status
Not open for further replies.

Mosaic

Well-Known Member
Hi All,

I started this new thread although this issue was discovered in another coding thread.
Anyway here goes,

WITH MPLAB 8.5
While programming a debounced keypress counter I had problems with the 16f690 giving odd initial values upon reading RA3 (digital) controlled by a switch to ground (Pic kit 2 LPC). The switch when open delivers a high to to RA3.

After much fiddling, this bit of code(below) added a time delay and a Wait on RA3 high state. This 'solved' the apparent incorrect startup keypress count of 1 (should have been zero) . This code is executed only once before the main prg loop.

Code:
InitWait ; this loop adds a delay to handle fluctuating inputs upon activating the PIC.
	CLRF Delay1
	MOVLW .25 ; This value is the smallest delay @4MHz that allows proper init. Bigger is ok.
	MOVWF Delay2
				
Wait 	
	DECFSZ Delay1,F ; 1 inst cycle, when  delay1=0 => test = true skip next line.
	GOTO Wait		; 2 inst cycles, this  is looped 256 times before skipping to next line => 768 microsec at 1 MIP
	DECFSZ Delay2,F ; +1 inst cycle (1 usec/cycle) at 1 MIP
	GOTO Wait		; +2 inst cyles, by adding the loops = (25 * 768) + (25*3) = 19.2 millisec delay
	BTFSS PORTA,3 ; test RA3, skip if HI (Switch is OPEN)
	GOTO $-1 ; wait for RA3  input to go high (voltage pull up) otherwise init not complete.
	RETURN

Well, the issue is IF I use the Pic Kit 2 (v2.5) to write the same MPLAB compiled hex file into the 16f690, I DO NOT NEED to have that code snippet above at all. The problems do not exist with the pic kit 2 writing but they always occur with the MPLAB (v8.5) doing the writing. Now the MPLAB SIM does not require the delay loop above to show correct operation of the overall program .

So MPLAB SIM says no delay loop is required and the PiC Kit 2 can write the hex code without the delay loop and it works fine, however, when MPLAB writes the code (without the delay loop) to the 16f690 the "keypress count" display starts off (incremented) wrong UNLESS that delay loop above is used. It's as though RA3 is bouncing around hi/low for at least 20 millisec upon startup of the PIC.

What's even more curious is when I write the code to the 16f690 (no delay loop) with MPLAB , the count is wrong upon 'Release from reset". BUT, If I exit MPLAB, start up PicKit2 and activate the 16f690 Vdd, the count is RIGHT (zero) and all is well, with no alteration to the 16f690 code at all.

So this has to do with how MPLAB activates/resets the 16f690 pic, not the actual code.

Can anybody shed some light as to what settings in MPLAB can 'fix" this?

I am using the "Connect on Startup", "3-State on Release from Reset" and" use Prog Exec if available"
In the MPLAB (V8.5) Program settings.
 
Hi All,

I started this new thread although this issue was discovered in another coding thread.
Anyway here goes,

WITH MPLAB 8.5
While programming a debounced keypress counter I had problems with the 16f690 giving odd initial values upon reading RA3 (digital) controlled by a switch to ground (Pic kit 2 LPC). The switch when open delivers a high to to RA3.

After much fiddling, this bit of code(below) added a time delay and a Wait on RA3 high state. This 'solved' the apparent incorrect startup keypress count of 1 (should have been zero) . This code is executed only once before the main prg loop.

Code:
InitWait ; this loop adds a delay to handle fluctuating inputs upon activating the PIC.
	CLRF Delay1
	MOVLW .25 ; This value is the smallest delay @4MHz that allows proper init. Bigger is ok.
	MOVWF Delay2
				
Wait 	
	DECFSZ Delay1,F ; 1 inst cycle, when  delay1=0 => test = true skip next line.
	GOTO Wait		; 2 inst cycles, this  is looped 256 times before skipping to next line => 768 microsec at 1 MIP
	DECFSZ Delay2,F ; +1 inst cycle (1 usec/cycle) at 1 MIP
	GOTO Wait		; +2 inst cyles, by adding the loops = (25 * 768) + (25*3) = 19.2 millisec delay
	BTFSS PORTA,3 ; test RA3, skip if HI (Switch is OPEN)
	GOTO $-1 ; wait for RA3  input to go high (voltage pull up) otherwise init not complete.
	RETURN

Well, the issue is IF I use the Pic Kit 2 (v2.5) to write the same MPLAB compiled hex file into the 16f690, I DO NOT NEED to have that code snippet above at all. The problems do not exist with the pic kit 2 writing but they always occur with the MPLAB (v8.5) doing the writing. Now the MPLAB SIM does not require the delay loop above to show correct operation of the overall program .

So MPLAB SIM says no delay loop is required and the PiC Kit 2 can write the hex code without the delay loop and it works fine, however, when MPLAB writes the code (without the delay loop) to the 16f690 the "keypress count" display starts off (incremented) wrong UNLESS that delay loop above is used. It's as though RA3 is bouncing around hi/low for at least 20 millisec upon startup of the PIC.

What's even more curious is when I write the code to the 16f690 (no delay loop) with MPLAB , the count is wrong upon 'Release from reset". BUT, If I exit MPLAB, start up PicKit2 and activate the 16f690 Vdd, the count is RIGHT (zero) and all is well, with no alteration to the 16f690 code at all.

So this has to do with how MPLAB activates/resets the 16f690 pic, not the actual code.

Can anybody shed some light as to what settings in MPLAB can 'fix" this?

I am using the "Connect on Startup", "3-State on Release from Reset" and" use Prog Exec if available"
In the MPLAB (V8.5) Program settings.

Upgrade to 8.53 and recheck the results.
 
8.53 is the same.

BUT i have new info. It has to do with the MPLAB Mclr (Hold/release Mclr) . Seems that RA3/ Mclr/Vpp shares the same pin with the pushbutton switch in the LPC board. Now, if I am in MPLAB, and I keep ' releasing' and then 'holding' the Mclr the count of Keypresses goes up. So the mere act of releasing the the PIC from reset (after blowing the chip) causes the count to increment and causes untold confusion with the implication that the counting code has a prob. Thus the code snippet above adds enough delay to discount the MCLR toggle and things work after that.

I can verify this MCLR toggle in PicKit2 as well, by toggling the Mclr box after activating Vdd....the count increments every toggle. The MCLR toggle comes from the PC and makes RA3 behave as though a keypress sent it to ground.

So I ask again, how can I get my PIC to run the code without using MCLR in MPLAB? Just activating VDD does not work as it does in the Pickit 2 programmer.
 
I have not read the threads above but I have been asked to make a comment. I will make a point that the debounce should be fairly long to prevent false readings and then you should have a flag to detect when the key is not pressed. You must have a long debounce time - not matter what else you do. You will find the "mechanical" faults of the project are the most difficult to discover.
 
Last edited:
This is one of the problems when using ICSP with MCLR turned off. When it's turned off it, rather obviously, doesn't work.

Possible solutions,
Change to a different pin.
Keep the delay.
Use the Pickit2 software.

Mike.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top