PIC "Begin Erase/End Programming" question

[Nigel Goodwin]

The 14 bits are padded on either side, making the whole "word" 16 bits long. According to the prog spec, after issuing a Read Data or Load Data command, the clock is cycled 16 times, with the first and last bits being "start" and "stop" bits.

I noticed that when reading a word in memory, the PIC always throws a "1" as the 1st bit and another "1" as the 16th bit. The 14-bit word I programmed is between those two 1's. When the MSB of my 14-bit word is a "0", it doesn't throw the "1" as the 16th bit. And everything after that fails to read.

I did confirm that the PIC is being programmed correctly by incrementing passed the troublesome word and continuing to read.

If it's any help?, here's the routine from WinPicProg that writes 14 bits out, notice that I don't consider it a 16 bit word, but just send clock pulses before and after.

Procedure OutWord(Data : Word);
Var
  x,
  BitPos : Word;
Begin
  ClockPulse(DLow);
  BitPos := 1;
  For x := 0 To 13 Do
  Begin
    IF (Data AND BitPos) = BitPos THEN
      ClockPulse(DHigh)
    ELSE
      ClockPulse(DLow);
    BitPos := BitPos Shl 1;
  End;
  ClockPulse(DLow);
End;

 

[Rusttree]

Thanks for the code post. My write routine actually seems to be ok. It's my read routine I'm suspicious of.

Good point about the 14-bit vs. 16-bit consideration. I guess I'm using the 16-bit mentality because that's how the hex file is constructed. They're all 16-bit values with 0's always as the first and last bit. But I might rewrite my code to think of it as a padded 14-bit word instead.

 

[Nigel Goodwin]

I guess I'm using the 16-bit mentality because that's how the hex file is constructed. They're all 16-bit values with 0's always as the first and last bit.

I didn't think so?, I thought they were aligned at one end? - although I must admit it's been MANY years since I wrote the routines.

 

[Rusttree]

Oh I think you're right. Geez, it's only been a few months since I wrote my code. How embarassing.

 

[Rusttree]

Well, you inadvertantly solved my problem. By having the logic treat the read as a 16-bit value instead of a 14-bit value with 2 extra clock cycles, I wasn't paying close enough attention to the 1st and 16th clock cycle during the read. After I rewrote my code, I realized the data pin was being inappropriately latched during the clock cycle. Still not 100% sure why that caused the problem, but by forcing the data pin low during the 1st and 16th clock cycles, it solved my problem.

Thanks Nigel!

 

[Nigel Goodwin]

Well, you inadvertantly solved my problem. By having the logic treat the read as a 16-bit value instead of a 14-bit value with 2 extra clock cycles, I wasn't paying close enough attention to the 1st and 16th clock cycle during the read. After I rewrote my code, I realized the data pin was being inappropriately latched during the clock cycle. Still not 100% sure why that caused the problem, but by forcing the data pin low during the 1st and 16th clock cycles, it solved my problem.

It needs to be low, I can't remember why? - it's over ten years ago since I wrote the basic routines! (under DOS then).

 

[williB]

Russ if you can read pascal , i submitted my whole programmer code not too long ago ..
https://www.electro-tech-online.com/threads/log-data-using-pic16f877a.23562/