Error programming 16F628

[eblc1388]

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

 

[Joel Rainville]

Try IC-Prog.

 

[Jay.slovak]

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.

 

[Nigel Goodwin]

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.

 

[Joel Rainville]

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.

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.

 

[Joel Rainville]

i think the time has come for me to give up on this programmer and try another type :-(

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

 

[gregmcc]

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

 

[Joel Rainville]

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.

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.

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

 

[eblc1388]

Think about it, if every time you program the PIC, the memory content is close to your .hex file, with slight random differences.

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.

 

[gregmcc]

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.

 

[eblc1388]

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.

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

 

[Joel Rainville]

eblc1388 :

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.

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

 

[eblc1388]

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.

 

[Joel Rainville]

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.

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?

 

[gregmcc]

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.

 

[Jay.slovak]

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 ?

 

[Joel Rainville]

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?

 

[gregmcc]

yip - cant get it to work at all with icprog.

Yip - I now realize it Oh well - its goes towards learning

 

[Nigel Goodwin]

Hmm strange, Nigel's SW should be OK. Have you tried Ic-prog ?

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

 

[gregmcc]

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.