Hi,

did you time the write operation to the PIC EEPROM? One must wait until
the writing is completed.

Regards,
Imre

On Wed, 22 Sep 1999, Glenn Pure wrote:

> I'm seeking some help to solve a problem with a gadget I'm making.
>
> This is a long and detailed question so don't bother now if you haven't got
> 15 minutes to spare.
>
> First, here's what I'm doing...
>
> 1. I've built a 'controller' using a PIC16F84 to keep a real time clock and
> switch relays on and off according to program information stored in the
> PIC, in the 64 bytes of EEPROM data memory. This part is working fine
>
> 2. I need to update the program data in the EEPROM data memory from time to
> time. This will be done through an interface with the parallel port on a
> standard IBM PC running Windows 3.x or later.
>
> I'm writing the PC Windows application with Borland C. I can read the
> contents of my PIC EEPROM data memory without problem. I can also write
> fresh data to this memory with my software, but the latter process is
> unreliable. Sometimes it will write 64 bytes without a glitch, other times
> it will stop writing after an unpredictable number of bytes (from 1 to
> 63!). I can't fathom why. About 50% of the write operations occur without
> problem and the other 50% fail at some point.
>
> I'll describe the logic behind the software in my PIC and the Windows
> software with which it interacts in the hope someone might be able to give
> me clues about why my writes are unreliable. I'm sure lots of other people
> have done this sort of thing lots of other times before.
>
> The PIC is triggered to enter read or write mode with the RB0/INT pin
> (which is connected to D4 of the parallel port). As soon as the interupt is
> detected, the remaining software routines for reading and writing operate
> entirely on a 'polled' rather than interupt basis.
>
> If a write to the PIC is to occur, I send RB6 on the PIC low (connected to
> D0 of the parallel port). Next step is a 'handshake' so the PC can be
> convinced it is connected to the controller. This handshake is simply 50
> cycles of the following:
>
> * the PC sends RB1 high (configured as an input on the PIC, of course). The
> PIC loops for a few milliseconds waiting for this to happen
> * once the PIC sees RB1 go high, it sends RB2 low (configured as an
> output). The PC watches the relevant port pin to which RB2 is connected
> until it sees this then it sends RB1 low.
> * when the PIC sees RB1 go low, it sends RB2 high and the whole cycle
> repeats again.
>
> For added robustness, I make the PIC send out the two bytes "O" then "K"
> serially on RB2 (using the read process I have written).
>
> The above handshake appears to occur very reliably and errors are very rare.
>
> I won't bother explaining the read process as this is occurring reliably
> (it uses a variation on the handshake to clock data into the PC serially
> from RB2 on the PIC).
>
> The PC to PIC write process is also similar to the read except the data is
> clocked serially from PC to PIC as follows:
>
> * After the handshake process succeeds, the PIC is signalled to go into the
> write routine as RB6 is sent low by the PC. After this, RB6 is ignored.
>
> * Each byte is read in one at a time and written to the EEPROM memory in
> the PIC straight after it is received. That is, a byte is received, then
> written, then the next received then written (and so until until 64 bytes
> received). The PIC will exit from this process if the routine for receiving
> data from the PC times out while waiting for the correct signals from the
> PC for receipt of bits (see below for details).
>
> * As noted above, a byte is sent to the PIC serially and the following
> loops eight times, once for each bit. First, the PIC sends RB2 high to
> signal it is ready for a bit. The PC sends RB3 high when the output bit is
> ready (the bit is output to RB1). Once the PIC sees RB3 go high, it
> immediately sends RB2 low and then reads the bit. It then waits for RB3 to
> go low before starting the loop again for the next bit. The PIC and the PIC
> both loop for a set maximum amount of time (a few milliseconds) while
> waiting for the next signal from one another. If either of these loops
> times out, and error occurs and the routines are exited.
>
> * Once the PIC has received a byte, it is written and the PIC signals the
> write is completed by sends RA0 high (normally held low by the PC). The PC
> loops for up to 20 milliseconds until it sees this. If the PC times out at
> this point, the routine aborts.
>
> Through diagnostics I have built into the software, I can determine that
> the write failures are always occuring as a failure by the PIC to receive
> the first bit after a write operation is completed. Specifically, the PC
> fails to see RB2 go low.
>
> I strongly suspect a timing problem but have not seen *any* improvement by
> changing the length of time allowed for polling of signals. I can increase
> this by 5 or ten fold and see no improvement in reliability.
>
> I have tried lots of other things to try and solve this by adding software
> debouncing of signals, changing the pins used for signalling (and months
> worth of other things) without any improvement. I have just about given up
> trying to solve this. In fact, I have copped out by simply changing the
> software so I write until a byte fails, then pick up at this byte next
> time. By repeating this up to five times, I can get the data written to the
> PIC. But I hate fixes like this and would really like to know what I might
> be doing wrong.
>
> Glenn
>
>