pic programming help

Ok I've modified the origional circuit posted eailier.
Now i only have two connections to RB7(the data pin on the Pic16F84A) ,one is comming from a ls241 Tristate buffer the other is going to a Ls 245 Bidirectional bus driver ( to get data out of the pic).
let me explain how the circuit works for a second then my question.
ok I am using two LS 74 Flip Flops ( two FF's each) . the FF's drive the three pins needed to program the pic for (ICSP).
the top FF in the circuit posted eailier drives a IRF 510 n-channel Mosfet, which drives MCLR of pic. this FF is driven by the Ls 138 which is decoded to address 378H on the PC.
So to turn on MCLR i do a pascal port write Port[$378]:=B (where B is a dummy varible), and this Presets FF to a logic one. Similarly to bring MCLR low i do a pascal Port write to port 379, which Clears FF and brings MCLR low.
also during programming,RB6 must toggle , which i do by writing to ports 37C & 37D Respectivly.
To input data to Pic I write to port 37A which Sets the FF driving the Buffer high and bringing RB7 high.
To read from RB7 I tristate the 241 with a FF, not shown in origional post,so a port write to 37E tristates the 241 and a write to port 37F lets data pass from second FF from the top in origional circuit...
*Whew* ok Question when i did a ' Load data for data memory' command. Two ones followed by four zeros then a startbit then eight data bits then the remaining tics on Rb6 to finish the fourteen required data bits followed by a stop bit...
Then when i did a 'Read data from program memory' the first time i got all zeros, Not what i put in , but not the point of my question..after the first time all i am getting out of the pic is ones ????

*Abridged version*
wether i bulk erase , or not ,all i am getting from pic ,after first time, is ones HELP..!!
loosing hair fast.

You are likely to struggle, as you have two totally unknown factors - the hardware, and the software - and you've no idea if either of them is correct. One might be at fault, or the other might be at fault, or both of them may be at fault - but unless you can prove one of them is working OK I don't see any easy solution, you're just working in the dark.

To make matters even worse, you're trying to do something which (as far as I know?) no one else has done before, so there's no guarantee it will actually work at all (although I don't see any reason why it wouldn't).

when a 16f84A is erased , does it erase to ones or zeros?
and also, on the data sheet it says in section 2.3.1.8..
"A load command must be given before every begin programming command???What do they mean by this?

https://www.electro-tech-online.com/custompdfs/2004/09/30262e.pdf

page 7

Do i do a load command with no data? or what?


this is on page four.
Load Data for Program Memory X X 0 0 1 0 [ 0, data (14), 0 ]

or do i do a load command with the " begin programming " instruction embedded in it

they are very unclear on this point

any help would be greatly appreciated .

Hey it works !! 8)
i just did a Reset, then a load data , then a bulk erase , then a read .
and what i got back was what i put in !!! which was F0F3 hex..
i think that i erased The whole part to F0F3 , am i correct?.
this is sooo cool cuz it is the first Response that i got out of the part since i got it...!!!

things are going very well now
i am able to change a location (any location) in memory
by doing a reset
increment to where i want to change
do a Load data command
do a Begin erase programming cycle command
reset
increment
read..yay..
now i can start programming this controller.

williB said:

when a 16f84A is erased , does it erase to ones or zeros?

Click to expand...

Everything erases to all 1's, just like an EPROM, programming can only turn a '1' to a '0', so after erasure everything wil be 1's. Some of the bits in the config word are not used, and may be undefined - personally I mask off all unused config bits in my programmer software.

cool thanks

williB said:

Hey it works !! 8)
i just did a Reset, then a load data , then a bulk erase , then a read .
and what i got back was what i put in !!! which was F0F3 hex..
i think that i erased The whole part to F0F3 , am i correct?.
this is sooo cool cuz it is the first Response that i got out of the part since i got it...!!!

Click to expand...

One point I didn't notice earlier!, the highest value a memory location can have (and what it erases to) is 0x3FFF - a 14 bit value with all one's.

So you appear to have an error somewhere, which might be as simple as reading it backwards?.

no error , just my thought that i had erased the whole uC to F0F3.. That was an error.
what essentially happened was i had changed the first few program memory locationsto F0F3 hex and ' thought' that i had erased the whole part to that value.
At the time i guess i wasnt sure what was going on..

Another question If i Might...
is my perception of how the 16F84A operates correct?
what i mean is Do i have to reset the pic after a write , to read what i just put in there???

also can i do consecutive writes to consecutive locations without resetting??? these are things i am not sure of !?!
thanks again.

williB said:

no error , just my thought that i had erased the whole uC to F0F3.. That was an error.
what essentially happened was i had changed the first few program memory locationsto F0F3 hex and ' thought' that i had erased the whole part to that value.
At the time i guess i wasnt sure what was going on..

Click to expand...

There's an error somewhere, F0F3 isn't a valid number, it can't be any higher than 3FFF - which I why I mentioned that you might be reading it in reverse - and it should really be 3F0F?.

Another question If i Might...
is my perception of how the 16F84A operates correct?
what i mean is Do i have to reset the pic after a write , to read what i just put in there???

also can i do consecutive writes to consecutive locations without resetting??? these are things i am not sure of !?!
thanks again.

Click to expand...

You simply write the location, read it back to verify it, then increment the program counter to the next location - there's no need to do any resets, unless you want to reset the program counter to zero.

If you would be interested in the Turbo Pascal source code for the last DOS version of PICProg (about 1994/5), drop me a PM with your email address and I'll send it you (if I can find it!).

you are right. my mistake.
from left to right MSB being far left, the number was 3F0F hex or 1 1 1 1 1 1 0 0 0 0 1 1 1 1 binary.

hi Nigel, thanks for the program
i hav'nt run it yet (dont know if i can as i have version 5) but i have been looking it over.. it is much larger than mine which is only 9K at the moment.
i think that i can use some of your functions and procedures though.
oh i hav'nt been able to sucessfully read the written data without resetting first..
here is My process:: after resetting and bulk erasing
i do a load data.
then either a begin programming only command or A begin erase programming command.
then inc address .
then another load.. ect..
the only way to read the part for me is to reset , read, inc address , read , inc ..ect..

oh you CAN bulk erase the part to whatever you want to.. ive done it..
if the load command before the bulk erase command has other than ' all ones ' the part will bulk erase to that number.. no kidding..!!

williB said:

oh you CAN bulk erase the part to whatever you want to.. ive done it..
if the load command before the bulk erase command has other than ' all ones ' the part will bulk erase to that number.. no kidding..!!

Click to expand...

I seem to remember that on some of the old 16x84 chips you can do that (because you have to supply a data byte), but you can't on more modern PIC's.

i have another question. of the general type..
this is the hex output for the 16F84A
my question concerns the confifuration data which is 3FF9 H (line 4)which sets up the oscillator for xt operation.& dissable power up timer.. all standard stuff..

on line 4 of the hex output is supposed to be the config data for location 2007H. but as you can see its not .. Why???
for explanation purposes the first two hex digits after the coln are the number of bytes in the line..the next four are the address where the data is supposed to go
but as you can see 0E40 Hex isnt even close to 2007 Hex so what is up??
Does the assembler think i am using a different chip? What is the signifigance of 0E40 hex...??

williB said:

on line 4 of the hex output is supposed to be the config data for location 2007H. but as you can see its not .. Why???
for explanation purposes the first two hex digits after the coln are the number of bytes in the line..the next four are the address where the data is supposed to go
but as you can see 0E40 Hex isnt even close to 2007 Hex so what is up??
Does the assembler think i am using a different chip? What is the signifigance of 0E40 hex...??

Click to expand...

If you read the MPASM helpfile, the appendix fully explains the hexfile format.

But basically, the Intel hexfile is intended for 8 bit only, so to accomodate the 14 bit PIC data they multiple all addresses by two, stored low byte first. You will find that 0x400E is double 0x2007.

thanks
you da man Nigel 8)

another question?
should i clear port B somewhere?
because once the LED's on port B go on they dont go out..
if so , where should i put the ' clrf ' instruction.?
should i clear the A register, i dont think so because it is an input, but i am not sure.?

oh yeah i got the programmer to work FINALLY !! yay !!!
and i put the 16F84A on a breadboard i am using port A for input and B for output.
on the input i have a nifty part i got somewhere that is a hex dial..
that is the only way to describe it... you hook 5volts up to the one side and the other side has four outputs ... as you turn the dial it outputs hex..
that is the input..
for the output i have the standard Port B sourcing voltage to four LED's, it works but not exactly as planned.. because the LED's dont go out..

williB said:

for the output i have the standard Port B sourcing voltage to four LED's, it works but not exactly as planned.. because the LED's dont go out..

Click to expand...

That's because your routine only turns LED's ON, it never turns them OFF, assuming you want the same sequence of LED's as the switch provides there's a very simple solution - simply change the 'CALL Test_Bits' to 'MOVWF PortB', this will copy the switch settings directly to PortB.