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
DIY PIC programmer (16F88)
Started by ●October 24, 2006
Reply by ●October 24, 20062006-10-24
Damn Dan wrote:> 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. > >[snip] >Sequenece is one condition to fulfill, timing the other. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net
Reply by ●October 24, 20062006-10-24
"Damn Dan" <rusttree@gmail.com> wrote in message 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 >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 by ●October 24, 20062006-10-24
>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?Maybe to increase sales of overpriced programmers..? Though AVR tends to be reasonably priced compared to PIC ;)
Reply by ●October 24, 20062006-10-24
<pbdelete@spamnuke.ludd.luthdelete.se.invalid> wrote in message news:453ddd60$0$489$cc7c7865@news.luth.se...> >I had similar problems with my AVR programmer. I followed strictly theSPI> >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 byaltering> >some timings (I cannot recall what exactly, but it was something like > >setting SCLK to L before setting !RESET to L, or something similar). Iused> >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? > > Maybe to increase sales of overpriced programmers..? > Though AVR tends to be reasonably priced compared to PIC ;) >Yeap, that I was thinking of :-) Who would buy uC prog. tools when he/she could just build it?
Reply by ●October 24, 20062006-10-24
Damn Dan wrote:> 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 ForI 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 by ●October 24, 20062006-10-24
In article <453dc6a4$1_3@news.bluewin.ch>, Rene Tschaggelar <none@none.net> wrote:> Damn Dan wrote: > > 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. > > > >[snip] > > > > > Sequenece is one condition to fulfill, timing the other. > > ReneI use a PICPro16. I had some problems until I used a one foot cable for the parallel port connection. It works perfectly now. Al
Reply by ●October 24, 20062006-10-24
"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
Reply by ●October 24, 20062006-10-24
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 bitbyterThat'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 by ●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