DIY PIC programmer (16F88)

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

Reply to
Damn Dan
Loading thread data ...

I had similar problems with my AVR programmer. I followed strictly the SPI procedure for programming the uC and , if I remember well, I had problems with erasing the damn thing. I finally managed to make it work by altering some timings (I cannot recall what exactly, but it was something like setting SCLK to L before setting !RESET to L, or something similar). I used a datasheet to learn about the programming sequence with the SPI. So, probably the programming part of that document had an error, but the question is, was it there on purpose or not?

Regards GM

Reply to
GM

Maybe to increase sales of overpriced programmers..? Though AVR tends to be reasonably priced compared to PIC ;)

Reply to
pbdelete

SPI

altering

used

Yeap, that I was thinking of :-) Who would buy uC prog. tools when he/she could just build it?

Reply to
GM

I had some problems with these (why cant Microchip just program all the chips the same?).

In looking over my code, I dont see anything like your "Burn(data[a])". Also there needs to be a 2ms delay between Begin and End programming.

Luhan

Reply to
Luhan

"Damn Dan" schreef in bericht news: snipped-for-privacy@k70g2000cwa.googlegroups.com...

Using the Oshon programmer:

formatting link
without any problem so far. So wy reinventing the wheel?

petrus bitbyter

Reply to
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.

As far as timing, I neglected to put in the delay functions in my pseudo-code above because I didn't want to clutter it up. But I do have them in my code, according to the Prog Spec. In fact, since the programming sequence uses a external clock (that I control with software), I have all the delays multiplied by 5 just to be sure the PIC has enough time to do everything it needs.

Luhan, the "burn(data[a])" is nothing more than the current data word latched onto the 16 clock cycles following a "Load Data for Program Memory Command".

Reply to
Damn Dan

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:

----------------------------------------------------------------------------

-- 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

cheers, Stef

Reply to
Stef Mientki

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

http://www.ben.com/
Reply to
Ben Jackson

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 to
Damn Dan

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 to
Rob

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

Reply to
William at MyBlueRoom

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 to
Damn Dan

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 (

Reply to
Damn Dan

I here use "chip erase" instead of bulk erase, because it makes the algorithm more easier.

here the start of programming, and indeed there's a special remark about the 16F88

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

-- --------------------------------------------------------------------

Reply to
Stef Mientki

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.