Some 16F84 burners are supposed to be able to burn 16F84A's.
They always state that the HEX file must be compiled for the appropriate chip, but then go on to state that programming them and using them is basically identical in practical terms.

I have a couple of questions concerning this:
(Please assume that no timing components are present - this is an out-of-circuit ICSP burner)
- The procedure for Bulk-Erasing of the 16F84 and 16F84A is described very differently by Microchip in their specs. Some Burner software doesn't have separate selections for the two devices - can I assume that these burner softwarez are only using the protocol for 16F84 and thus even though they may burn program data correctly, will not be able to erase the configuration data of a locked 16F84A?
- The specs also mention that the timing of the input pulses on the 16F84A should be about 5 and not exceed 8ms, whereas the 16F84 uses 10ms !!
- Some F84 burners tie the pic's pins together in pairs:
1. pins 12 and 16 (RB6 clock input with runtime clock input),
2. pins 1 and 14 (RA2 unused IO pin with VDD +5v switched logic),
3. and pins 13 and 17 (RB7 command and data IO pin with RA0 unused IO pin).

What the heck for ... and especially the first pair, because the specs don't mention the need for clocking the pic through its clocking pin, just through RB6... doesn't clocking it immediately put it into execution mode - or can it only execute when vppis at 5v rather than 9-14?
Regardless, unless Vpp is applied to !mclr in something like no more than 70ms from powerup, the pic will generate an internal reset and clock, and begin execution from 0, correct?
Ok so this brings me to my final question - if we are switching !mclr between roughly 0 and 13 volts, then why do some burners want an extra line for pulling !mclr low (to reset it) - and does simply pulling vpp low in this fashion really reset the pic if the other control lines aren't low as well? The burnspecs I read described pulling all the lines low, then throwing vpp high to initiate icsp programming mode...
Posted on 2003-06-21 22:26:40 by Homer
First, check out the detail programming spec (but it looks like you have it)

My guess about the extra connections is they are there to fit other models of PICs, and if they are not used in serial programming they don't get connected.

leaving pins high when VCC goes low probably isn't the best practice, but it should work, as VCC is the reset line.

I have a personal adversion to cheapie programmers. Tried them once, now stick to dedicated products (PICwriter, PICSTART, and now Pro Mate II)
Posted on 2003-06-22 09:38:08 by Ernie
Thanks Ernie, I came to the same conclusions regarding these extraneous connections - how do we feel about leaving cmos inputs floating?? (unconnected inputs are generally a bad idea - all the "cheapie" designs I've looked at never address this, and some don't even bother showing things like Earthing pin 5 - as electronic design engineers, we're expected to know this stuff, but the average net-user shouldn't)..

Here's what Microchip had to say regarding unlocking of a 16f84A ...
NOTE UNDOCUMENTED COMMANDS w00t

#1- All Bulk-Erase operations MUST take place at 4.5-5.5v
#2- NO Bulk-Erase function will unlock a codeprotected 16f84A
#3- The following procedure WILL unlock a codeprotected 16f84A, however it will also destroy the program and data areas, thus security is not compromised.

-Execute a "Load Config" command, with a "1" in bits 4 thru 13
-Increment the PC to 2007
-Execute undocumented command 000001
-Execute undocumented command 000111
-Execute a "Begin Programming" command 001000
-Wait at least 10ms
-Execute undocumented command 000001
-Execute undocumented command 000111

Microchip guarantee this will restore a codeprotected 16f84A to its factory state, allowing the ever-frustrated hobbyist to alter the contents.

Heh - now I can justify the lpt lab code I was messing with :)
Guess I'll be writing a lil tool for unlocking 16f84a's in the near future ;)

Hope this information helps someone out there - gotta love the search engine on this forum :)

As for the first step in the procedure, the LoadConfig command being 000000 and followed by the following bits , least significant first... considering that the data size is 8 bits, and that bit zero of the command data is the "Start" bit, bits 1-8 are considered data, 9-14 are supposedly ignored, and 15 being the "Stop" bit, I guess this must be a magical Microchip command because they're quite specific about setting some of the ignored bits !! Did I totally misinterpret them?
Posted on 2003-06-23 16:26:10 by Homer
Silly me, the configuration word is 14 bits - leaving just enough for Start and Stop bits in a 16 bit data word following a LoadCfg command ;)
Posted on 2003-06-24 02:15:27 by Homer