DIY PIC programmer (16F88)

On 2006-10-24, Damn Dan <rusttree@gmail.com> wrote:
> So here's my issue.  My program burns 4 words into the program memory,
> increments, then burns 4 more.  I then reset the device and attempt to
> read the 8 words that were just burned.  When I do this, it
> successfully reads the first 4 words, but not the last 4.

How are you powering the chip while it's being programmed?  If you're
relying on the internal charge pump to do the flashing, it needs good
power and decoupling.  I had a CPLD programming problem that turned
out to be bad power.

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Ben Jackson wrote:
> On 2006-10-24, Damn Dan <rusttree@gmail.com> wrote:
> > So here's my issue.  My program burns 4 words into the program memory,
> > increments, then burns 4 more.  I then reset the device and attempt to
> > read the 8 words that were just burned.  When I do this, it
> > successfully reads the first 4 words, but not the last 4.
>
> How are you powering the chip while it's being programmed?  If you're
> relying on the internal charge pump to do the flashing, it needs good
> power and decoupling.  I had a CPLD programming problem that turned
> out to be bad power.
>
> --
> Ben Jackson AD7GD
> <ben@ben.com>
> http://www.ben.com/

Stef, thanks for your suggestion.  I'll have to try loading a 0x00
beforehand like you said.  Maybe that'll be a magical fix.

Ben, the chip gets Vdd from a 6V AC-to-DC converter which is fed into a
5V regulator.  I have a capacitor (don't remember the capacitance off
the top of my head) from power to ground to smooth out the signal.  The
input pins (clock, data, etc) are driven by my parallel port through an
inverting buffer.  The grounds on the parallel port and the 5V
regulator are tied together.

Damn Dan wrote:
> Ben, the chip gets Vdd from a 6V AC-to-DC converter which is fed into a
> 5V regulator.

Typical 3-terminal regulators require a 2 to 2-1/2 drop to maintain
regulation (Vin around 7.5V for 7805/LM340).  There are low dropout
varieties, but this might be your problem.

-R

On Oct 24, 5:08 pm, "Rob" <sdl_pi...@yahoo.com> wrote:
> Damn Dan wrote:
> > Ben, the chip gets Vdd from a 6V AC-to-DC converter which is fed into a
> > 5V regulator.Typical 3-terminal regulators require a 2 to 2-1/2 drop to maintain
> regulation (Vin around 7.5V for 7805/LM340).  There are low dropout
> varieties, but this might be your problem.
>
> -R

Good advice, but I think I'm ok here.  My 6V wallwart actually clocks
in at just over 7VDC into the regulator.  It's not quite the 7.5V you
recommend, but I'm willing to bet I'm safe here.  Also, I've slowed my
program way down (put in time delays of several seconds in between
commands) and voltmetered the appropriate pins.  Voltages always check
out fine.  I'm not saying that that's definitely not the problem, but
from what I've tested, it doesn't seem to be.

Damn Dan wrote:
> On Oct 24, 5:08 pm, "Rob" <sdl_pi...@yahoo.com> wrote:
>>
>> Ben, the chip gets Vdd from a 6V AC-to-DC converter which is fed
>> into a 5V regulator.Typical 3-terminal regulators require a 2 to
>> 2-1/2 drop to maintain regulation (Vin around 7.5V for 7805/LM340). 
>> There are low dropout varieties, but this might be your problem.
> 
> Good advice, but I think I'm ok here.  My 6V wallwart actually
> clocks in at just over 7VDC into the regulator.  It's not quite the
> 7.5V you recommend, but I'm willing to bet I'm safe here.  Also,
> I've slowed my program way down (put in time delays of several
> seconds in between commands) and voltmetered the appropriate pins. 
> Voltages always check out fine.  I'm not saying that that's
> definitely not the problem, but from what I've tested, it doesn't
> seem to be.

Voltmeters often read peak voltage.  Have you checked the waveforms
on the voltage lines with a scope?

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>

Rob wrote:
> Damn Dan wrote:
> > Ben, the chip gets Vdd from a 6V AC-to-DC converter which is fed into a
> > 5V regulator.
>
> Typical 3-terminal regulators require a 2 to 2-1/2 drop to maintain
> regulation (Vin around 7.5V for 7805/LM340).  There are low dropout
> varieties, but this might be your problem.
>
> -R

What are you using for VPP?
LVP is a crap shoot and you lose an I/O pin.

William at MyBlueRoom wrote:
> Rob wrote:
> > Damn Dan wrote:
> > > Ben, the chip gets Vdd from a 6V AC-to-DC converter which is fed into a
> > > 5V regulator.
> >
> > Typical 3-terminal regulators require a 2 to 2-1/2 drop to maintain
> > regulation (Vin around 7.5V for 7805/LM340).  There are low dropout
> > varieties, but this might be your problem.
> >
> > -R
>
> What are you using for VPP?
> LVP is a crap shoot and you lose an I/O pin.

A parallel port pin through the inverter is driving Vpp/MCLR.  I don't
really mind losing an I/O pin, as the project I'm working on doesn't
need many I/Os.

>Bugs in your program or in uChip's specs  ;-)
>
> My advice, for delays take 2*uChip_max.
> I had realy bad experience with erasing,
> here is the protocol, which until now works perfect:
>
> <JAL>
> ----------------------------------------------------------------------------
> -- performs a chip erase (PC pointing to config memory),
> -- will erase everything (independant of protection bits)
> -- 16F87 / 16F88  (8msec)
> -- 16F87xA  (4msec)
> ----------------------------------------------------------------------------
> procedure erase_program_memory_3 is
>    -- pointing to config memory, will erase all
>    -- (pointing to program memory will not erase config words)
>    -- loading with data=0 works the best,
>    -- I had the fortune of having a "bad" 16F877A,
>    -- both pointing to program memory and config memory
>    -- the following result were obtained
>    --   data = 0        OK
>    --   data = 0x00FF   NOT OK
>    --   data = 0x3FFF   NOT OK
>
>    -- start trying to erase with preloading of DATA=0
>    -- according to the datasheets, the value of data shouldn't matter
>    -- but from my own experience a data value of zero worked best
>    data=0x00
>    PIC_write_cmd_word (cmd_load_configuration)
>    PIC_write_cmd (cmd_chip_erase)
>    delay_1ms(8)
>
>    if ! verify_full_erase then
>      -- if erase was not succesfull,
>      -- try to erase with preloading of DATA=0x3FFF
>      -- this suggestion was made by several programmer builders
>      data=0x3FFF
>      PIC_write_cmd_word (cmd_load_configuration)
>      PIC_write_cmd (cmd_chip_erase)
>      delay_1ms(8)
>
>        -- if erase was still not succesfull,
>        -- try to erase with preloading of DATA=0xFF
>        -- this value was suggested for "old" devices
>        if ! verify_full_erase then
>        data=0xFF
>        PIC_write_cmd_word (cmd_load_configuration)
>        PIC_write_cmd (cmd_chip_erase)
>        delay_1ms(8)
>      end if
>    end if
> end procedure
> </JAL>
>
> cheers,
> Stef

Stef, I tried your suggestion here and I wasn't met with immediate
results.  Although i wasn't 100% sure if I implemented it correctly.
Right now, my exact routine is (all delays are >10ms):
Reset
Delay
Load Configuration Command
Delay
Load Data For Program Memory Command
Delay
Write 0x00  (<-- cycle clock 16 times with 0x00 latched onto falling
edge of clock)
Delay
Bulk Erase Command
Delay
Begin Erase Command
Delay
End Programming Command
Delay
Reset

And then the rest of my writing and reading routine.  Is that how you
meant?  I didn't know if I had to reset again after loading the 0x00 in
the begining.

Also, would you mind showing me your reset routine?  I'm still very
confused if I'm resetting the address counter correctly during
programming.  For each and every reset I do, I set MCLR and PGM low,
delay, set MCLR high, delay, and then set PGM high.  Thanks!

Damn Dan wrote:
>> Bugs in your program or in uChip's specs  ;-)
>>
>> My advice, for delays take 2*uChip_max.
>> I had realy bad experience with erasing,
>> here is the protocol, which until now works perfect:
>>
>> <JAL>
>> ----------------------------------------------------------------------------
>> -- performs a chip erase (PC pointing to config memory),
>> -- will erase everything (independant of protection bits)
>> -- 16F87 / 16F88  (8msec)
>> -- 16F87xA  (4msec)
>> ----------------------------------------------------------------------------
>> procedure erase_program_memory_3 is
>>    -- pointing to config memory, will erase all
>>    -- (pointing to program memory will not erase config words)
>>    -- loading with data=0 works the best,
>>    -- I had the fortune of having a "bad" 16F877A,
>>    -- both pointing to program memory and config memory
>>    -- the following result were obtained
>>    --   data = 0        OK
>>    --   data = 0x00FF   NOT OK
>>    --   data = 0x3FFF   NOT OK
>>
>>    -- start trying to erase with preloading of DATA=0
>>    -- according to the datasheets, the value of data shouldn't matter
>>    -- but from my own experience a data value of zero worked best
>>    data=0x00
>>    PIC_write_cmd_word (cmd_load_configuration)
>>    PIC_write_cmd (cmd_chip_erase)
>>    delay_1ms(8)
>>
>>    if ! verify_full_erase then
>>      -- if erase was not succesfull,
>>      -- try to erase with preloading of DATA=0x3FFF
>>      -- this suggestion was made by several programmer builders
>>      data=0x3FFF
>>      PIC_write_cmd_word (cmd_load_configuration)
>>      PIC_write_cmd (cmd_chip_erase)
>>      delay_1ms(8)
>>
>>        -- if erase was still not succesfull,
>>        -- try to erase with preloading of DATA=0xFF
>>        -- this value was suggested for "old" devices
>>        if ! verify_full_erase then
>>        data=0xFF
>>        PIC_write_cmd_word (cmd_load_configuration)
>>        PIC_write_cmd (cmd_chip_erase)
>>        delay_1ms(8)
>>      end if
>>    end if
>> end procedure
>> </JAL>
>>
>> cheers,
>> Stef
> 
> Stef, I tried your suggestion here and I wasn't met with immediate
> results.  Although i wasn't 100% sure if I implemented it correctly.
> Right now, my exact routine is (all delays are >10ms):
> Reset
> Delay
> Load Configuration Command
> Delay
> Load Data For Program Memory Command
> Delay
> Write 0x00  (<-- cycle clock 16 times with 0x00 latched onto falling
> edge of clock)
> Delay
> Bulk Erase Command
I here use "chip erase" instead of bulk erase,
because it makes the algorithm more easier.
> Delay
> Begin Erase Command
> Delay
> End Programming Command
> Delay
> Reset
> 
> And then the rest of my writing and reading routine.  Is that how you
> meant?  I didn't know if I had to reset again after loading the 0x00 in
> the begining.
> 
> Also, would you mind showing me your reset routine?  I'm still very
> confused if I'm resetting the address counter correctly during
> programming.  For each and every reset I do, I set MCLR and PGM low,
> delay, set MCLR high, delay, and then set PGM high.  Thanks!
> 
here the start of programming,
and indeed there's a special remark about the 16F88
<JAL>
procedure start_program_mode_Vdd_before_HV is
   -- if HighVoltage is on,
   -- programming mode is already entered
   if !HV then
     -- be sure both data and clock lines are low
     data_pin = low
     clock_pin = low
     data_pin_dir = output
     clock_pin_dir = output

     -- HV On, wait >5usec
     -- But in practice we need at least 70 usec ??
     -- to start a 16F88 reliable we even need more delay
     Power_on
     delay_1ms(10)
     HV_on
     ;delay_10us(10)
     delay_1ms(10)
   end if

   -- we always assume that during program mode,
   -- the data-pin is in tri-state
   data_pin_dir = input -- disable data output
end procedure
-- --------------------------------------------------------------------
</JAL>