Error programming 16F628

Status
Not open for further replies.
OK.

I can't recommend you one because I don't know which one can read the hex file with gaps in them.

The problem is mainly a gap in your hex file. The data from 0002 to 0007 is missing so the programming software(s) don't like it a bit.

Perhaps you can try another hex file or our Jay can provide you with one.

Or try the following one that I patched(filled in the gaps) by hand.

Edited: for correctness "The data from 0002 to 0007...."
 

Attachments

  • source.hex.txt
    371 bytes · Views: 240
I was watchnig this topic, but I didn't want to interfere until I heard my name here
Yes try Ic-prog, maybe that would help, or I can (as suggested before) make you a sample LED blinking program.
 
By all means try IC-Prog, it's always worth a try, but the problem is most probably your poor construction?.

In almost all of these types of programmers you need VERY! short wires between the buffer chip on the programmer and the actual PIC. This is because they use passive pull-ups, and any slight capacitance from longer wires will cause problems.
 
Nigel Goodwin said:
In almost all of these types of programmers you need VERY! short wires between the buffer chip on the programmer and the actual PIC. This is because they use passive pull-ups, and any slight capacitance from longer wires will cause problems.
Click to expand...

Even though I suggested trying IC-Prog, I am now convinced the long wires are at fault, especially since it appears that program memory is different after each try.

I am 85% sure the wires' length is guilty here.
 
gregmcc said:
i think the time has come for me to give up on this programmer and try another type :-(
Click to expand...

There's no point in trying another type of programmer if you don't make this one work.

You're very close to success, don't give up now. It's 99% done.

If I don't hear from you soon, I'm taking the next plane to wherever you live and I'll make sure you finish it :twisted:

Come on, you're almost there...
 
would the length of the wires from the parallel port connector to the board make a differnce. they're untwisted, but about 10 cm long. on the underneath of my verboard i've also used a bit of kynar wire to join tracks (30awg). could that also be a problem?

i've tried the blinking led program, but when i build the pic with the led, it doesnt do anything. the led doesnt come on.

its almost 1am here and if I dont put the programmer down now - its going to end up in little pieces. thanks for all the help - i'll try again tomorrow. its gotta be something simple
 
gregmcc said:
i've tried the blinking led program, but when i build the pic with the led, it doesnt do anything. the led doesnt come on.
Click to expand...

Forget about the LED blinking program for now. You want WinPicProg and/or IC-Prog to tell you that the program memory is fine after a programming session. It should verify program memory successfully.


I'd say that right now, any unshielded ~10cm piece of wire is a prime suspect.

Think about it, if every time you program the PIC, the memory content is close to your .hex file, with slight random differences. it's gotta be noise/interference somewhere on the signal path...

You're close to success...
 
Joel Rainville said:
Think about it, if every time you program the PIC, the memory content is close to your .hex file, with slight random differences.
Click to expand...

I cannot agree with you on this. There is no random difference in this case. All the bytes are programmed correctly except where there is a discontinuity in the hex file memory address where the bytes are then shifted.

The problem is the hex file or the ability of software to interpret the hex file properly.

I attached a proper hex file in the previous post for gregmcc to try but I guess he didn't.
 
eblc1388: thanks - I haven't tried your hex code yet. I'll try it asap before I make any other changes and let you know what happens.
 
gregmcc said:
eblc1388: thanks - I haven't tried your hex code yet. I'll try it asap before I make any other changes and let you know what happens.
Click to expand...

A even better orgainised hex file for you to try if the previous one still fails.
 

Attachments

  • source1.hex.txt
    358 bytes · Views: 214
eblc1388 :

gregmcc said:
It does seem to program something as the first few bytes are written although incorrect values.
I can then erase the device and reprogram it, and different bytes get written to the start.
Click to expand...

This is from gregmcc's first post. That's what I am refering to, and I am assuming this is still the case. Different random values get written where programming fails, other parts of program memory are fine. Maybe gregmcc can confirm this is still the case...
 

Yes. But then he posted the source and the result and it changes everything.

There are a lot of bytes in the programmed PIC. There is no value error in all of the bytes except two bytes is missing. This is anything but random.
 
eblc1388 said:
There are a lot of bytes in the programmed PIC. There is no value error in all of the bytes except two bytes is missing. This is anything but random.
Click to expand...

But this is only true for the one time he posted the results. How do you know the programmer behaves the same every time?

Also, Nigel Goodwin, from his post, doesn't sound like he thinks his software is at fault.

I think we're both assuming too much and gregmcc should clarify this : do you get similar/identical results everytime, or does the programed memory content jump around like crazy every time you try to program it?
 
at last I've got some good news!!

tried eblc1388's code on WinPicProg - the code programs and verifies 100% - everytime.

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%

Ive just programmed the original code and built the led blinker, and lo and behold the led blinks!!! Woooo Hooo!!!!

No sure why it doesnt work with WinPicProg though. But thanks for all the help for everyone.
 
Hmm strange, Nigel's SW should be OK. Have you tried Ic-prog ?
 
Congrats to Mr. Chung then. He correctly diagnosed the problem about 2 pages worth of posts ago!

gregmcc, you realize you had a working programmer all this time, n'est-ce pas?
 
Jay.slovak said:
Hmm strange, Nigel's SW should be OK. Have you tried Ic-prog ?
Click to expand...

I've just tried it here with WinPicProg, and the original HEX code posted, and it works fine!. As long as it's a valid HEX file it shouldn't make any difference, but strange things happen?.

As your programmer wouldn't work with IC-Prog I wonder if there's a hardware problem somewhere?. IC-Prog should work, assuming you have it configured correctly?.

WinPicProg is the fastest parallel port PIC programmer software, basically because it ONLY programs the bytes that are needed, so for your HEX file it programs the first byte (the GOTO), skips over the next three, then starts programming again from the GOTO target address.

I can only suspect that something in your hardware is preventing the first two bytes being written when it starts programming again?.
 
anythings possible - but I dont have a clue how to fix it

maybe sometime i'll build another programmer from scratch and see how it goes.
 
Status
Not open for further replies.

Similar threads

E
  • Question
High res cap meter with PIC 16F628
Replies
7
Views
5K
Elekktrishun
E
  • Question
programming a pic using pickit2/3
2
Replies
39
Views
6K
be80be
T
  • Question
Basic programming for a cubloc
Replies
4
Views
4K
rjenkinsgb
  • Question
Pic simulator IDE BASIC compiler error
Replies
19
Views
4K
DogFlu66
S
  • Question
Programming concepts
2
Replies
30
Views
7K
granddad
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…