Using "END" Fries PICS?

[Cyberdove]

I discovered that placing an "end" statement in the middle of a program rendered my 16f819 useless. Somehow it prevented the chip from ever programming again. I used up 7 chips while tracing this down.

[Cyberdove]

I discovered that placing an "end" statement in the middle of a program rendered my 16f819 useless. Somehow it prevented the chip from ever programming again. I used up 7 chips while tracing this down.

[Archangel]

Ok questions: What programmer are you using? Which programmer software are you using? Can you post your "config" statement? Have you made sure you are not setting code protect on?

EDIT: So, I just tried to duplicate your problem in one of my programs . . . I put end in a subroutine where it should not be and as expected it stopped the program there (that's what it does) but I am able to restart the pic, AND I was able to reprogram it with no problem. I think you should post your code for forensic examination.

I have had many times where the programmer just wanted to give me a hard time and code protect the chip and not want to reprogram the chip using a PICKitII, and this I found works:

Step 1. make sure to turn off code protect.
try to erase if fails select the Wrong chip, I repeat, select the wrong chip
this will clear the program area.
Step 2. Select the correct chip and then click WRITE this will program the chip with hex 3FFF at every location, effectivly erasing the PIC
Step 3.ClickAuto Import Hex + Write Device select the hex you wish to program and it will program properly (hopefully).

[Cyberdove]

I'm using an old MELabs USB Programmer and melabs Programmer V 4.51 beta software. I have NOT write protected the 16F819 chip. I have it configured such:
osc = INTRC
WDT = enabled
Power up timer = Enabled
MCLR pin funct = input pin
Brownout reset = Enabled
Low voltage programming = Disabled
CCP multiplex = RB2
Flash prog mem write enable = All
code = Not Protected
Data EEPROM = Not Protected

Here is my code:

 INCLUDE "modedefs.bas"
define osc 4
osccon= %01100000

DEFINE	ADC_BITS	8	'this sets number of a/d bits, using 10 gives much higher resolution
DEFINE	ADC_CLOCK	2	'choose clock source for a/d, 2 gives a stable reading
DEFINE	ADC_SAMPLEUS	50	'sample wait time 50 microseconds
'LCD declarations-------------
CR	CON	13	'carriage return
LF	CON	10	'cursor down one line keeps horiz position
crsrH	CON	1	'home cursor
bell	CON	7	'beep
clrlcd	CON	12	'clear the lcd
poscmd	CON	16	'position cursor
N9600	CON	$4054	'value for 9600 baud setting

 PORTA = 0
 PAUSE 1
 PORTB = 0
 PAUSE 1
 
 trisa = %11000001
 trisb = %00000000
 ADCON1 = %00001110
 commpin		VAR	porta.4	'serial pin to LCD
 
 Button1 var porta.1
 
  MuxOutput var byte
  SwSelect var byte
  SwSelect = 8
  
pause 1000

GoSub kls

 SerOut2 commpin,n9600,[CLRLCD,bell]

 pause 100

mainloop:

end 'NEVER use "end"!!!!  it destroys the chip!

portb = swselect

adcin 0,muxoutput

gosub lcdtext

gosub SelectSwitch

gosub button1NOTpressed

goto mainloop
   
SelectSwitch:
Swselect=swselect + 1
    if swselect = 16 then
        swselect = 8
    endif
return    

lcdtext:
SerOut2 commpin,n9600,[crsrh,"T",dec (portb-7),"=",dec muxoutput,"   REQ=",bin portb,"     "]
SerOut2 commpin,n9600,["                    ",lf]
return

button1NOTpressed:
adcin 0,muxoutput
gosub lcdtext
	IF button1 = 1 Then 
        GoTo button1NOTpressed 		'hold here until button released
	EndIF
	gosub button1pressed
Return



button1pressed:
	IF button1 = 0 Then 
        GoTo button1pressed 		'hold here until button released
	EndIF
Return

 'Clears LCD screen --------------

KLS:
SerOut2 commpin,n9600,[clrlcd]
Return

beep:
	SerOut2 commpin,n9600,[bell]			'tech 8 beep
Return

End

After programming the chip, it never programs again. All I get when trying to reprogram is the error message "Target Device does not match selected device".

[mark_s]

I had that problem with the pic18f45k80. It had something to do with using the MCLR pin as an input.
Melabs was able to help me by updating the programmer software. I don't believe the END statement
is your problem. Read this article it may help.

http://www.gooligum.com.au/tutorials...rog_issues.pdf

[Acetronics2]

Hi,

I often place END statement @ the bottom of EACH subroutine when programming some device that must not reach " la la land " ... or accidentally fall into the next sub ...

NEVER got any problem , especially about reprogramming ...

by the way ...

the END statement place a never ending SLEEP LOOP @ the locations of the program you type it, like that

in asm :

SLEEP
GOTO $-1 ' or goto the label corresponding to the sleep command,

Alain

[ruijc]

Hi there,

I agree with Mark_S.

I learned the hard way with 16f88 MCUs and the MCLR issue.

The problem is not the fact of using the MCLR pin as input, but as a combination of MCLR as input and internal OSC option.

Everytime i design some circuit that will use the internal osccilator i know i will lose the MCLR pin.

About the MCUs mentioned, i was never able to recover them.

Regards
Rui

[Cyberdove]

I had that problem with the pic18f45k80. It had something to do with using the MCLR pin as an input.
Melabs was able to help me by updating the programmer software. I don't believe the END statement
is your problem. Read this article it may help.

http://www.gooligum.com.au/tutorials...rog_issues.pdf

The problem went away when I removed the "end" statement. It looks to me that having MCLR as an input pin and then declaring it as an output and then writing "end" in the mainloop causes the MCLR pin to be pulled low when it is powered up, thereby ignoring MCLR when trying to program it. That is a curious state of affairs. I wonder if there is a way around this?

[Demon]

Look at the datasheet and confirm the MCLR pin can be used as an output. MCLR on the 18F44K22 can only be an input; making it an output can have unexpected results.

Robert

[Cyberdove]

Look at the datasheet and confirm the MCLR pin can be used as an output. MCLR on the 18F44K22 can only be an input; making it an output can have unexpected results.

Robert

I was able to program the chip by pressing the "program" button on the meProgrammer about a half second after the chip powered up. This prevented the program from reaching the "end" statement.

[Acetronics2]

mainloop:

end 'NEVER use "end"!!!!  it destroys the chip!

this code is rather strange : you send clear and bell , Then place your chip in sleepmode ???

I hope you have left the Watchdog ON ...

to me, you should use STOP command here ...

now, why include " modedefs" and after place this line :

N9600	CON	$4054	'value for 9600 baud setting

???

Alain

[Acetronics2]

last news ...

using MPLAB + Picstart for programming cause an ICD CRASH !!!

buuuut ....

Everything goes fine with MPLAB + ICD2 ...

just CR and BELL generate compiling errors ( WHY ??? ), changing them for CR0 and BELL0 clears any reported problems.

answer is in the modedef.bas file :

 ' Debug / Serial Constants
Symbol CLS = 0
Symbol HOME = 1
Symbol BELL = 7
Symbol BKSP = 8
Symbol TAB = 9
Symbol CR = 13

Memory is well programmed and erased ...

so your chips are not dead ... probably it is a programmer issue in the end.

Alain

[Acetronics2]

a very intersting post ...

http://www.microchip.com/forums/m532131.aspx
http://www.microchip.com/forums/m303686.aspx

I had somewhere in my brain the "Vpp first" option was to use with some chips ...

also think you have some errors to clear in your program ... ( double definitions ...)

Alain

[Cyberdove]

mainloop:

end 'NEVER use "end"!!!!  it destroys the chip!

this code is rather strange : you send clear and bell , Then place your chip in sleepmode ???

I hope you have left the Watchdog ON ...

to me, you should use STOP command here ...

now, why include " modedefs" and after place this line :

N9600	CON	$4054	'value for 9600 baud setting

???

Alain

The program was under development and being debugged when this problem cropped up. The "end" was part of the search for the cause of the chips becoming non-programmable.