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.
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.
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.
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).
Last edited by Archangel; - 11th December 2014 at 20:31.
If you do not believe in MAGIC, Consider how currency has value simply by printing it, and is then traded for real assets.
.
Gold is the money of kings, silver is the money of gentlemen, barter is the money of peasants - but debt is the money of slaves
.
There simply is no "Happy Spam" If you do it you will disappear from this forum.
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:
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".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
Last edited by Archangel; - 16th December 2014 at 20:02.
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
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 :
AlainCode:SLEEP GOTO $-1 ' or goto the label corresponding to the sleep command,
************************************************** ***********************
Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
************************************************** ***********************
IF there is the word "Problem" in your question ...
certainly the answer is " RTFM " or " RTFDataSheet " !!!
*****************************************
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
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?
Last edited by Cyberdove; - 17th December 2014 at 13:33.
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
this code is rather strange : you send clear and bell , Then place your chip in sleepmode ???Code:mainloop: end 'NEVER use "end"!!!! it destroys the chip!
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 :
???Code:N9600 CON $4054 'value for 9600 baud setting
Alain
************************************************** ***********************
Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
************************************************** ***********************
IF there is the word "Problem" in your question ...
certainly the answer is " RTFM " or " RTFDataSheet " !!!
*****************************************
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 :
Code:' 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
Last edited by Acetronics2; - 17th December 2014 at 20:07.
************************************************** ***********************
Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
************************************************** ***********************
IF there is the word "Problem" in your question ...
certainly the answer is " RTFM " or " RTFDataSheet " !!!
*****************************************
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
Last edited by Acetronics2; - 18th December 2014 at 12:45.
************************************************** ***********************
Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
************************************************** ***********************
IF there is the word "Problem" in your question ...
certainly the answer is " RTFM " or " RTFDataSheet " !!!
*****************************************
Bookmarks