PDA

View Full Version : WRITECODE - How it works



Ioannis
- 17th June 2015, 10:07
Thanks for posting Henrik.

Reading this part "Fixed WRITECODE block size for 16(L)F1946, 1947" I wonder if PBP compiler does a block write as needed by the specific chip.

I mean does read the specific block, alters the data user wants and then write back the whole block?

I used to do this manually.

Ioannis

pedja089
- 17th June 2015, 10:15
As far as I could as i could see it when I was testing my bootloader, WRITECODE, stores bytes in tblr registers, and when you fill tblr, it write block at once.
And before writing to block you must erase that block.
So if block size is 128 bytes, WRITECODE takes just few cycles to execute first 127 times, and when it is used 128 time, it takes about 5mS.

Ioannis
- 17th June 2015, 11:24
So, if you just make a



WRITECODE random_address,random_data


it will NOT make an actual write untill the specific block for the specific chip is completed, right?

And if the power to the chip is cut before this happens, the data will NOT be stored.

So, according to the project, it might be better to wait or write immediatly (and manually) the data to flash.

Ioannis

pedja089
- 17th June 2015, 12:40
As far as I understand how it work, it won't save nothing to FLASH until page you write to last byte in table. So random write to code using WRITECODE might not be good idea.

ASM for WRITECODE Adr, FlashByte1 'Adr VAR LONG

Line Address Opcode Label DisAssy
63459 1EFC4 C02E Z0007E MOVFF Adr, TBLPTR
63460 1EFC6 FFF6 NOP
63461 1EFC8 C02F MOVFF 0x2F, TBLPTRH
63462 1EFCA FFF7 NOP
63463 1EFCC C030 MOVFF 0x30, TBLPTRU
63464 1EFCE FFF8 NOP
63465 1EFD0 502A MOVF _FlashByte1, W, ACCESS
63466 1EFD2 DEA9 RCALL 0xED26
First address is loaded to pointer registers(4 bytes), then your byte is loaded to work registers, and then WRITECODE is called with RCALL.
Here is code for WRITECODE macro for 128 byte page

Line Address Opcode Label DisAssy
63124 1ED26 6EF5 WRITECODE MOVWF TABLAT, ACCESS
63125 1ED28 000C TBLWT*
63126 1ED2A 28F6 INCF TBLPTR, W, ACCESS
63127 1ED2C 0B7F ANDLW 0x7F
63128 1ED2E E109 BNZ 0xED42
63129 1ED30 0E84 MOVLW 0x84
63130 1ED32 6E7F MOVWF EECON1, ACCESS
63131 1ED34 0E55 MOVLW 0x55
63132 1ED36 6E7E MOVWF EECON2, ACCESS
63133 1ED38 0EAA MOVLW 0xAA
63134 1ED3A 6E7E MOVWF EECON2, ACCESS
63135 1ED3C 827F BSF EECON1, 1, ACCESS
63136 1ED3E 0000 NOP
63137 1ED40 947F BCF EECON1, 2, ACCESS
63138 1ED42 EFE8 writecodedone GOTO 0x1EDD0
63139 1ED44 F0F6 NOP
....
63209 1EDD0 0100 DUNN MOVLB 0x0
63210 1EDD2 0000 DUNN5 NOP
63211 1EDD4 0012 RETURN 0


Then at WRITECODE byte from w is moved to holding register, and then table write is executed(TBLWT*).
This will check if your last adr is 127

63126 1ED2A 28F6 INCF TBLPTR, W, ACCESS
63127 1ED2C 0B7F ANDLW 0x7F
63128 1ED2E E109 BNZ 0xED42
If not it will branch to writecodedone, then goto to DUNN and finally RETURN to your code.
If last Adress was 127 then it will execute FLASH write(Same as EEPROM write, just bit EEPGD of EECON1 is set ) and go back to your code.
If you put address 127 and load only one byte page write will be executed, but what is in table you can't know, so table will be write with random data except byte at 127 location.
I hope that this will help you to understand how WRITECODE is done.
This might be separate topic, as it doesn't have much with new version.

HenrikOlsson
- 17th June 2015, 13:45
Hi,
From the manual:

For block accessed devices, like the PIC16F877a and PIC18F452, a complete block must be written at once. This write block size is different for different PIC MCUs

Note that block writes are not actually executed until the end location of the block is written to. If you write to random addresses within a block and neglect to write to the end location, the previously buffered data will not be written and will be lost.

Section 11.3 of the 16(L)F1946 datasheet (http://ww1.microchip.com/downloads/en/DeviceDoc/41414D.pdf) says that the block size is 32 words.

I suspect that PBP was treating the 1946/1947 as having another block size and that's now been fixed. The fix does not mean PBP handles preserving data within a block for you, just that it now knows the correct block size so that it DOES write the block once you initiate a WRITECODE to the last adress within that block - as per the manual.

With that said, I've never used WRITECODE so this is just my understanding after a bit of reading.

/Henrik.