PIC "Begin Erase/End Programming" question

[Rusttree]

I'm find a strange effect of using the "Begin Erase" followed by the "End Programming" commands in my PIC programmer code. I noticed that when I preempt the programming section with those two commands, the PIC doesn't appear to program correctly. If I leave out the erasing command, it works fine.

This is on a 16F88.

So, if I do this:
Bulk Erase
Begin Erase
End Programming
Load Data for Program Memory (-> Burn Data1)
Increment Address
Load Data for Program Memory (-> Burn Data2)
Increment Address
Load Data for Program Memory (-> Burn Data3)
Increment Address
Load Data for Program Memory (-> Burn Data4)
Begin Programming Only Cycle
End Programming

then it doesn't work. When I go to read the first line of data, it returns 3fff. But, if I do the same thing, but leave off the first two commands, it works ok and I can later read the data. Why does doing the erase command screw up the rest of the program?

Thanks,
Dan

 

[Nigel Goodwin]

You need to take it out of programming mode after the erase, then place it back in programming mode - entering programming mode resets the address counter, which the erase has changed.

 

[Rusttree]

Oh, I thought the "Load Data for Program Memory" command puts it back into programming mode.

So does that mean I have to reset the PIC and then load the data?

 

[Rusttree]

Ok, I'm starting to sense my root problem here. I think what I really need is something that explains the specific order of commands that need to be implemented during reading and writing the PIC. I'm finding Microchip's Programming Specification document (the main documentation I've been using up until now) is too high-level. I need something that explains the exact order of commands that need to be issued to accomplish a task.

As of now, I am able to successfully write and read back a single word, so I know I'm in the right ballpark. Is there documentation available that provides these specifics? So far, I haven't found anything better than the Programming Spec.

Thanks!
-Dan

P.S. I've been using the flow chart in the 16F88 Programming Spec (Figure 3-2) as my guide so far. It's proved, however, to be fairly inadequate.

 

[Nigel Goodwin]

The programming specs are VERY confusing, some of the methods WinPicProg uses bear very little resemblance to the programming spec sheets from MicroChip!. It's often a question of finding what works - but usually you have to exit programming mode and re-enter it to move to the next section.

 

[Rusttree]

I was afraid that'd be the answer. Is the command order I used in my first post good enough? I added a reset in between the End Programming and the first Load Data for Program Memory. I ask because when I try to read back the data, I can only ever read the first word. After that, it always returns 3fff.

Here's the complete pseudo-code I'm using so far:

-Reset-
Begin Erase
End Programming
-Reset-
Load Data for Program Memory (-> Burn Data1)
Increment Address
Load Data for Program Memory (-> Burn Data2)
Increment Address
Load Data for Program Memory (-> Burn Data3)
Increment Address
Load Data for Program Memory (-> Burn Data4)
Begin Programming Only Cycle
End Programming
-Reset-
Read Data From Program Memory (-> Read Data1)
Increment Address
Read Data From Program Memory (-> Read Data2)


When I do this, Data1 reads back correctly, but Data2 is 3fff. I've tried several variations of this code, but nothing else works. Is there something fundamental I'm missing?

Thanks!

 

[Nigel Goodwin]

If it's any help?, this is the Delphi code from WinPicprog that writes the data EEPROM memory.

ProgMode(POn);
i := 0;
Begin
    While i < n Do
    Begin
      v := Buf.Data[i];
      Command(LdData);
      OutWord(v);
      Inc(i);
      Inc(Total);
      Command(BegPrgOnly);        {Program word}
      Delay(2);
      Command(EndPrgA);
      Command(IncAdd);
    End;
End;
ProgMode(POff);

'i' is just an index to the data buffer, and 'Total' is a running count of how many bytes (both program and data memory) get written to the PIC. Outword() sends the data to the PIC, and Command() sends a command. ProgMode (POn) switches the PIC to programming mode - had to use 'POn' as 'On' is a reserved word. ProgMode(POff) obviously exits programming mode. Delay() is the delay time in milliseconds.

This is the program memory routine!.

While i < n Do
    Begin
      v := Buf.Prog[i];
      Command(LdProg);
      OutWord(v);
      Inc(i);
      Inc(Total);
      For x := 1 To Processor[ProcNum].Bytes-1 Do
      Begin
        v := Buf.Prog[i];
        Command(IncAdd);
        Command(LdProg);
        OutWord(v);
        Inc(i);
        Inc(Total);
        Delay(1);       {added 11/1/04}
      End;
      Command(BegPrgOnly);
      Delay(2);
      Command(EndPrgA);
      Command(IncAdd);
    End;

 

[Rusttree]

Ok, that's pretty much exactly what I have. Except for the presence of two loops. Why do you have a single OutWord(v) outside of the for loop and then the rest of the OutWord's are inside a for loop? Does that first OutWord have something special about it?

Also, does your ProgMode(POff) simply reset the PIC?

 

[Nigel Goodwin]

Ok, that's pretty much exactly what I have. Except for the presence of two loops. Why do you have a single OutWord(v) outside of the for loop and then the rest of the OutWord's are inside a for loop? Does that first OutWord have something special about it?

The 16F88 is a FLASH device (not all so called FLASH are!), as such you can write more than one byte at a time, which is what makes them faster to program. The inner loop writes a block of bytes, how many depends on the particular device, and I store the value in the data entry for the particular PIC.

Also, does your ProgMode(POff) simply reset the PIC?

It turns OFF programming mode, in the reverse order that you turn it ON.

 

[Rusttree]

Ok, I think I follow that enough to figure this out.

I'm still having unexplainable issues with reading the data. If I read a single word, it works fine. But no more than one word at a time. For example, if I read the 1st word, increment, and read the 2nd word, the 2nd word comes back blank. However, if I increment first and then read the 2nd word, then I can see the 2nd word. Is reading a word, incrementing, and then reading the next word not the way to do it?

 

[williB]

Ok, I think I follow that enough to figure this out.

I'm still having unexplainable issues with reading the data. If I read a single word, it works fine. But no more than one word at a time. For example, if I read the 1st word, increment, and read the 2nd word, the 2nd word comes back blank. However, if I increment first and then read the 2nd word, then I can see the 2nd word. Is reading a word, incrementing, and then reading the next word not the way to do it?

yes that is the way to do it.
i have had that problem more than once with my programmer , as Nigel said , with chips like the 16F877A you can load 8 words at a time IIRC, the F88 is similar if not exact to the way you have to program the 877A,but you dont have to load 8 at a time , there is also the single word load which requires the end programming command , because the single word load is externally timed , where the multi word load is internally timed.
there is a data sheet which specifically addresses the programming steps to take,and why.
unfortunately i dont have access to it at the moment

 

[Rusttree]

Ok, I figured it out. My logical was holding the RB7/PGD pin high after the PIC had relinquished it's hold on the pin (after I cycled the clock 16 times for the data read). This was intentional, as I needed to set that pin of my inverter high during the data read so it acts as an open collector. If I "reinitialize" RB7 to a low state after the data read and then let the code continue, it works as expected.

Thanks all for your help.

-Dan

 

[Rusttree]

I'm running into some very strange behavior now. And I think it might be my reset mechanism. Here's my setup:

Reset
Run Erase Command
Reset
Load 4 words (increment in between the first 3)
Run "Begin Programming/End Programming"
Increment
Load 4 more words
Run "Begin Programming/End Programming" again
Reset
Read all 8 words of data by running Read Data/Increment commands

When I do that basic program, the "Read Data" commands appropriately show the first 4 words, but not the second 4 words. And then I noticed something weirder. If I reset and run the "Read Data" loop again immediately following the first "Read Data" loop, I get absolutely nothing the second time around (all x3fff's).

So my theory is my reset mechanism is not correctly reseting the device. Or, at least, the PC is not being set back to 0x0000. I'm using the ICSP technique, so my program does the following every time it resets the 16F88 during code execution:

Set RB3/PGM and MCLR to low
Set RB3/PGM high
Set MCLR high

Is that the appropriate way to put the PC back at 0x0000 during programming?

 

[Pommie]

Have you looked at the Programming specification for the 16F88?

Mike.

 

[Rusttree]

Thoroughly. That's where I've gotten all of my circuit and software design from so far (except for the few things I've asked on this forum). The spec very clearly states how to enter programming mode initially, but it's rather vague on how to just reset the PC during programming. I've always just taken the assumption that you reset the PC in a similar manner as you enter programming mode initially (the procedure I outlined in my post above). But based on the behavoir of my programmer, I'm starting to suspect otherwise.

 

[Rusttree]

I'm still very confused whether I've got this reset routine correct. Does anyone have a good code example (source code or pseudo-code) that shows a reset during programming? Right now, every time I want to set the address counter back to 0x00, I set both MCLR and PGM low, then bring PGM high followed by MCLR high. The spec document shows this as the correct way to enter programming mode, but doesn't explicitly state how to reset once you're already in programming mode.

Thanks!

 

[Nigel Goodwin]

Taking MCLR low will reset the PIC just as it would normally - personally I turn off Vdd as well, but that obviously depends on your hardware.

 

[Rusttree]

I'm hoping to get some troubleshooting advice. I've traced my problem to a very bizarre culprit. Apparently, if the MSB of a loaded 14-bit word is not a "1", then the PIC won't throw the stop bit of that word during a Read Data From Program Memory. And, it won't read any more words after that. If a Read Data command is issued after that, it'll always return 0x3FFF.

For example, if I program a 0x2000 (b0000000000000010 <-LSB first in 16-bit form), the MSB is a "1" and so it'll read it perfectly and be able to increment and read the next word. If I program a 0x1000 (b0000000000000100), it'll read the word, but not allow anymore reading to be done.

Oh, and I confirmed that all of the words are definitely being programming successfully. I tested that by resetting and incrementing directly to a word immediately following a problematic word, and it reads fine.

I've been working on this problem for a while now. If anyone can throw a suggestion at me, I'd appreciate it.

Thanks!

 

[Nigel Goodwin]

What do you mean by 'stop bit'?, it's a syncronous format so doesn't have them.

It sounds like you're probably not writing to the PIC correctly?, I notice you give a 16 bit word as an example, but I thought you were using a 14 bit PIC?.

 

[Rusttree]

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.