How does the PIC’s PMCON1.WRERR bit actually work

flashpicprogramming

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?

Best Answer

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).

Related Solutions

Electronic – How to overwrite flash memory on STM32L series

Some types of non-volatile memory device use error-correcting logic which adds an extra few bits to each programmable chunk (e.g. 5 bits per 16, 6 per 32, 7 per 64, 8 per 128, etc.) Generally the error correction code is chosen so that all bits blank is a valid representation; in some cases, but not all, it may also be chosen such that all bits programmed is also a valid combination. For simplicity, I'll assume a code with which guards each group of 4 bits with 3 guard bits. Compute the three guard bits guard bit as being the xor of either data bits 0+1+3, 0+2+3, or 1+2+3. I'll also assume that a blank word is zero.

The 16 possible code values are thus

3210 ABC    3210 ABC    3210 ABC    3210 ABC
0000 000    0100 011    1000 111    1100 100
0001 110    0101 101    1001 001    1100 010
0010 101    0110 110    1010 010    1110 001
0011 011    0111 000    1011 100    1111 111

When a memory nybble is read, the system can see what bits ABC should be according to the table. If one of the seven bits in the word is misread, the combination of ABC bits that don't match the computed value will indicate which bit was wrong.

Suppose a memory system used the 16-bit code shown above, and one wanted to overwrite a byte value of 1110 (ECC bits 001) with a value of 1000 (ECC bits should be 111). The net effect would be that the system would write 1000 with ECC bits of 001. When the data is read back, the system would see that for a value of 1000, the ECC bits should be 111 but are instead 001. The fact that bits A and B are wrong means bit 0 of the data was wrong and should be flipped; the system would thus read the value as 1001 (whose ECC is correctly 001).

In most cases, there should be enough flexibility in the design of an error-correcting code to permit both all-bits-clear and all-bits-set to be regarded as valid combinations. Some systems do not do so, however. If an error-correcting code would require an all-bits-programmed word to have two or more of the ECC bits blank, then an attempt to obliterate a word which has those bits programmed would likely visibly fail; attempts to program many other values would likely yield a state which was only one bit error away from failure rather than two.

I really wish memory designers would allow for data to be obliterated even if they don't allow most other overwriting patterns. Especially with NAND flash, it would make some operations a lot easier.

Electronic – Rewriting PIC configuration bytes at runtime

I did a bit more digging on the site, and this answer for PIC16 makes me think I can't write configuration bytes for dsPIC33E in a bootloader at runtime.

Best Answer

Related Solutions

Electronic – How to overwrite flash memory on STM32L series

Electronic – Rewriting PIC configuration bytes at runtime

Related Topic