1
\$\begingroup\$

I know from the datasheet that it gets set automatically on a rising edge of the WR bit and cleared automatically on a successful completion. Thus, if it's still on, then something went wrong. So far so good, but how closely should I watch it?

The chip that I'm using for this project (PIC16F1454) erases and writes its program memory in "rows" of 32 words each. A write to this memory actually goes to one of 32 transparent latches that corresponds to the lower bits of the address. Then, if the LWLO bit is off, the same operation then transfers all 32 latches simultaneously to the row specified by the upper bits. So the procedure, given a memory image, is to erase a row if it isn't already, set LWLO, fill the row except for the last word, clear LWLO, and write the last word.

During this process, I'm setting WR for each word as part of writing the latch, so WRERR should be on also. Then if the write is successful, WRERR turns back off again. The datasheet doesn't say if the latch has the success rate of ordinary RAM or what to do if it goes wrong. It does say that the latches are all reset to the erased value (0x3FFF) after being transferred. Is it a problem to blindly fill the row and transfer it, then check WRERR and repeat the row if necessary? If WRERR is good, then I'll verify the data itself and repeat if necessary.

In other words, is it possible to fail when writing a latch only?

\$\endgroup\$
1
\$\begingroup\$

According to the data sheet:

The WRERR bit is set when a write operation is interrupted by a Reset during normal operation. In these situations, following Reset, the user can check the WRERR bit and execute the appropriate error handling routine.

That means the only time you should really be looking at the WRERR bit is at the start of your program to see if a reset occurred during a write operation. If it did, then you know you can't trust the contents of the memory you wrote. You should then run an error handling routine, which might scan the area of memory that you write to looking for any rows that are part-written, don't have the right checksum, etc, and doing something "appropriate" with them, such as replacing them with valid data, erasing them, whatever is right for your software.

The proper way to know if the row you have written has been written correctly is to read the row in and compare it to what you have told it to write, and if they differ then something went wrong (typically you have worn out your flash and you need to replace the chip).

|improve this answer|||||
\$\endgroup\$
  • \$\begingroup\$ So it always succeeds, except for getting reset in the middle of the process? That would make the code a lot easier; just don't worry about WRERR at all. The PC side isn't all that smart, so it'll probably download the whole thing again anyway. And I'm already validating on startup because I expect to have bad code there at certain times. \$\endgroup\$ – AaronD Sep 16 '14 at 23:14
  • \$\begingroup\$ Yup. WRERR is "did it reset during write", not "did the write complete successfully". If it completed then it completed, but it doesn't know if what was written is what you told it to write - only you can determine that. \$\endgroup\$ – Majenko Sep 17 '14 at 11:39
  • \$\begingroup\$ I asked a Microchip support guy the same thing, and he agrees with you. Thanks for your help! \$\endgroup\$ – AaronD Sep 17 '14 at 16:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.