I made a function to read the GPD project file and extract the nvmData portion into a vector which is then used by a function to sequentially write to all registers. When trying to write to all registers of the device in one go, it seems like some of them could not be written to.

I reset the device, read all registers, program the device, read registers and then compare the before, after and the wanted register settings. Putting a diff next to each where after and wanted does not match. Now I can see which bytes that could not be written to, at least those that should have a different value than 0.

Perhaps you have to do 16-byte page writes to RAM as well. I made a new function to 16-byte Page write all 256 bytes. Results were better but I'm are still missing some critical registers for some reason.

Here is a list of the register bytes that could not be written to. I looked at the data sheet to see what they are used for.

Address    Before     After      Wanted
---------------------------------------------
 0x00       00         00         86  <- Diff!  :  Matrix output 0
 0x78       01         03         00  <- Diff!  :  Matrix inputs 32 to 39  <-- Here we have a totally different value.. ??
 0x7B       C0         C0         00  <- Diff!  :  Matrix inputs 56 to 63
 0x7C       00         01         00  <- Diff!  :  CNT0(16-bit) Counted Value  <-- Are these just the current counter value?
 0x7E       00         FF         00  <- Diff!  :  CNT2(8-bit) Counted Value
 0x7F       00         01         00  <- Diff!  :  CNT4(8-bit) Counted Value

 Are the registers below sort of settings or manufacturing code? left over test stuff? since GPD wants to reset them all.

 0xCE       0E         0E         00  <- Diff!  :  Reserved with split register bits in data sheet
 0xF0       3D         3D         00  <- Diff!  :  Reserved with split register bits in data sheet
 0xF1       11         11         00  <- Diff!  :  Reserved with split register bits in data sheet, 1 unspecified bit (unused bits?)
 0xF2       0D         0D         00  <- Diff!  :  Reserved with split register bits in data sheet, 3 unspecified bits (unused bits?)
 0xF3       29         29         00  <- Diff!  :  Reserved with split register bits in data sheet, 2 unspecified bits (unused?)
 0xF4       25         25         00  <- Diff!  :  Reserved with split register bits in data sheet, 2 unspecified bits (unused?)
 0xF5       1F         1F         00  <- Diff!  :  Reserved with split register bits in data sheet, 2 unspecified bits (unused?)
 0xF6       10         10         00  <- Diff!  :  Reserved with split register bits in data sheet
 0xF7       FF         FF         00  <- Diff!  :  Reserved full byte
 0xF8       FF         FF         00  <- Diff!  :  Reserved full byte
 0xF9       02         02         00  <- Diff!  :  Reserved with split register bits in data sheet
 0xFA       B8         B8         00  <- Diff!  :  Reserved with split register bits in data sheet, 4 unspecified bits (unused?)
 0xFB       06         06         00  <- Diff!  :  Reserved full byte
 0xFC       84         84         00  <- Diff!  :  Reserved full byte

Some reserved bytes have their listing split in the data sheet with some of the bits not reserved. There is several ways to think about these reserved register bits. They have some functionality that GPD use, they are non functioning macrocells (silicion that doesn't work or part of it), there are some registers that aren't marked with reserved, are these unused registers?

The critical ones are these for the matrix output and inputs. I do successfully write to other matrix registers. So I'm not sure what is going on. Since I can not even do just a single byte write to the first register byte. The code is pretty much the same to write to the reset register and resetting works. I reset the device each time before I try to set the registers. Something else is going on.

I tried adding a 100ms delay before writing each page but that doesn't make any difference. I tried removing the connected switch and LED. I disconnected the EEPROM and  the level shifter from I2C bus. No difference.

It's very easy to just change the control byte and write to NVRAM instead. I'm going to do some further troubleshooting before committing to that. I pretty sure you should be able to just write to RAM since the offical tool does it. Maybe you have to write in a different order. I'll try writing the pages backwards. Nope writing the pages from last to first made no difference at all. Is there a magic bit?

Looking through the datasheet there is a register bit 1600, I have no idea what it does but it's close to the reset bit. It's a long shot but I'm going to set this bit to 1 before writing. This bit can not be set. Nothing happens.
I'll try to disable IO latching. This bit can not be set either.

To write to the NVRAM it first has to be erased. Looking at the notes for register [1823] Erase Enable(ERSE) it says "0: erase disable
1: cause the NVM erase: full NVM (4k bits) erase for
ERSCHIP = 1 (reg[1973]) if DIS_ERSCHIP = 0
(reg[1972]) or page erase for ERSCHIP = 0 (reg[1973]).".

So reg[1973] ERSCHIP: Erase chip selects if you should erase all the NVRAM pages with the ERSE register.
reg[1972] DIS_ERSCHIO: Does this disable erasing the whole chip? but allows erasing pages? or does it disable erasing all together?

Interesting, that it mentions two reserved registers. So there might be something that has to be done to enable "Emulation mode" where you can write to all RAM registers. I only found 1 library to write to the SLG46824/6 that mentions a emulate mode command but no code for it. So it is probably safe to say that it will not work without doing something special. Now if this is a secret bit? or something else I do not know.

If I had an offical tool and a tool to analyze the I2C traffic, I could find out. Setting reserved register bits until it work is probably not a very good idea. However since I'm operating on RAM any changes should be erased when I cut the power, but ERSE and other commands are executed through setting RAM registers. I can probably not write to anything critical without the emulate mode enable anyway? Should I try and perhaps sacrifice a SLG46826V module? 

Emulate mode is important if I want to use any other greenPAK's since most are just one-time programmable. I could ask on the forums, but would they answer? If it's not in the datasheet is it a secret?