>> 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>
Reply by Damn Dan●October 25, 20062006-10-25
>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!
Reply by Damn Dan●October 25, 20062006-10-25
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.
Reply by William at MyBlueRoom●October 25, 20062006-10-25
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.
Reply by CBFalconer●October 24, 20062006-10-24
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>
Reply by Damn Dan●October 24, 20062006-10-24
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.
Reply by Rob●October 24, 20062006-10-24
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
Reply by Damn Dan●October 24, 20062006-10-24
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.
Reply by Ben Jackson●October 24, 20062006-10-24
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/
Reply by Stef Mientki●October 24, 20062006-10-24
Damn Dan wrote:
> petrus bitbyter wrote:
>> "Damn Dan" <rusttree@gmail.com> schreef in bericht
>> news:1161665972.499849.73430@k70g2000cwa.googlegroups.com...
>>> I've been working on a PIC programmer for my 16F88. So far I've met a
>>> mild degree of success, but I've run into a strange roadblock. I think
>>> it may have something to do with my reset routine. The Microchip
>>> documentation is... well... lacking, to put it generously. I've used
>>> the 16F88 Programming Specification document up until now, but I'm
>>> finding it more and more difficult to uncover specific answers.
>>>
>>> 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. During my
>>> investigation, I reset and attempted to read the 8 words a second time
>>> immeditately after the first read attempt. In other words I did this:
>>> 1) Reset
>>> 2) Burn 8 words
>>> 3) Reset
>>> 4) Read 8 words
>>> 5) Reset
>>> 6) Read 8 words
>>>
>>> I was able to see only the first 4 words from step (4), but none of the
>>> words from step (6). This is what made me think that something is
>>> wrong with my reset command, like maybe it is not setting the address
>>> counter to 0x00 correctly. My reset routine looks like this (using
>>> ICSP protocol):
>>> 1) MCLR and PGM low, then
>>> 2) PGM high, then
>>> 3) MCLR high
>>>
>>> Can anyone note a clear flaw in my program here? For thoroughness,
>>> here is the pseduo-code from my program so far:
>>>
>>> Reset
>>> Bulk Erase
>>> Begin Erase
>>> End Programming
>>> Reset
>>> For a = 1 to 4
>>> Load Data for Program Memory
>>> Burn(data[a])
>>> if (a != 4) Increment
>>> End For
>>> Begin Programming Only Cycle
>>> End Programming
>>> Increment
>>> For a = 5 to 8
>>> Load Data for Program Memory
>>> Burn(data[a])
>>> if (a != 4) Increment
>>> End For
>>> Begin Programming Only Cycle
>>> End Programming
>>> Reset
>>> For b = 1 to 8
>>> Read Data From Program Memory
>>> Read(data[b])
>>> Increment
>>> End For
>>>
>> Using the Oshon programmer:
>> http://www.oshonsoft.com/picprogserial.html
>> without any problem so far. So wy reinventing the wheel?
>>
>> petrus bitbyter
>
> That's far from the first time I've heard the "reinvent the wheel"
> line. Simply put, it is of interest to me exactly what's happening to
> the microchip as I'm programming it. Right down to the individual high
> and low bits. Besides, I've already gotten the engine for my code
> written. It's just a matter of working through some bugs now.
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