Error programming 16F628

Hi gregmcc,

I'm glad you have finally got your LED blinking. Everybody here shares the happiness with you. Just tell others why you are so happy seeing a LED blinks and people would say you are out of your mind.

gregmcc said:

Then tried the original blinking led code - its writes the same values everytime, but fails on verify. (on WinPicProg)

I've just downloaded a programmer called PicAllW - the original code and eblc1388's code programs and verifies 100%

Click to expand...

Ok. Gregmcc now its your chance to help with one final important piece of information before this thread can offically close.

1. Using Winpicprog, programs the PIC with your original blinking LED code and expect failure in verify. Exit program.

2. Startup PicAllW and just read the PIC. Post the content of the HEX file read from the PIC.

Can you do that for us?

No prob - I'll do it tonight and post my results.

True - people must think I'm completely mad because I'm jumping up and down about finally getting my led to blink

gregmcc said:

True - people must think I'm completely mad because I'm jumping up and down about finally getting my led to blink

Click to expand...

No, we've all been there :lol:

i've attached the results.

the original file (b628-1.hex) was written using WinPICProg.

I then used PICAllW to read the pic - the results saved to written_with_winicprog.hex

I also wrote the original file and read it back using PICAllW - the result is written_with_picallw.hex

Hi gregmcc,

Thanks for the results. I have checked them and found the error a liitle different to those previously mentioned. The data is shifted together with a 4 bits error.

The image shows the error location.

I'm afraid the problem is somewhere in between the communication of the PC and your programmer where there is a short break in programming activities. WinPicProg does not program the "empty" bytes so it is possible that the above error occurs during this time. By using a file with no gaps in it, I'm forcing WinPicProg to continously occuplying the CPU time without break so the programming is sucessful. The file works OK with PicAllW because all the bytes in the buffers, including those "3FFF" are being send to the PIC regardless so there is no break in the programming activities also.

This is only my guess. Yesterday, I have done some experiment too using the same file and WinPicProg on my PC. I cannot recreate the problem you've met and all the programming is sucessful. You can see the thread here:

PIC programmer & WinPicProg: my findings

This type of problems are common and happens with unique PC/OS/software combinations. Just sticks with one that works with your current setup and you are fine.

eblc1388, what's that tool you're using, "LC PIC Hex File Viewer"? Where can it be found? I asked Google, said he never heard of it Did you write it?

All this time I assumed HEX files were binary files. I just realized they were specially formatted text files, and not particularly easy to read...

Get it at the download area of the following webpage:

PIC n Mix - our monthly PIC column

The file you are after is PICnMix_OCT04.ZIP

thanks for the excellent article (PIC programmer & WinPicProg: my findings) - some very useful info in there.

one of these days when I have more time I'll fiddle with the software/hardware and see if I can figure out whats causing the problems. I'll let you know what I find.

Thanks again for all your guys inputs - really appreciated.