Maybe to use emulate mode, you need to set the I2C address to something other than the default? The slave address is set using the register byte CA. The first 4 bits are set if you want to use I/O pins to set it, like an EEPROM, for example. The last 4 bits are used to set the slave address; then you can have up to 16 unique addresses.

Well, it doesn't seem to have anything to do with it.

Reading through the datasheet, there is a section on read and write protection of the registers...

reg[1793:1792]: 2k Register Read Selection Bits RPRB[1:0] -> 00: 2k register data is unprotected for read; 01: 2k register data is partly protected for read; 10: 2k register data is fully protected for read; 11: reserved <-- this is interesting.

reg[1795:1794]: 2k Register Write Selection Bits RPRB[3:2] -> 00: 2k register data is unprotected for write; 01: 2k register data is partly protected for write; 10: 2k register data is fully protected for write; 11: reserved <-- this again.

Could these configuration bits lock the set mode? Apparently not; this is from the datasheet.

"Protect Lock Bit (PRL): The Protect Lock Bit is used to permanently lock the current state of the WPR, as well as RPR and NPR (see Section 15.5). A Logic 0 indicates that the WPR, RPR, and NPR can be modified, whereas a Logic 1 indicates the WPR, RPR, and NPR has been locked and can no longer be modified. The PRL register bit is located at register [1824] address."

Setting the PRL register bit will permanently set the current state of the RPR. So reg [1824] is a scary bit. Now, is this only scary if you write it to NVRAM? I do not want to test this either.

I should be able to safely set anything in the RPR [E0] register byte. There are 2 bits for read and 2 bits for write modes, and 4 singular bits that are reserved in the datasheet. This byte could have something to do with emulate mode.

I set both read and write to 11 (reserved), but it had some effect as writing to registers didn't work. I tried setting each of the other bits individually with no effect. Then I tried combinations of these 4 registers with no effect either. I set all bits with no effect. I simply cannot write these 4 bits at all.

I found a document ("In-System Programming Guide SLG46824/6/7-A") that mentions what the last page is for:

"Service Page Page #15 inside the 2Kbits NVM Registers memory space contains reserved information that is preprogrammed during device final test. The information on this page can be read but not written by the user. As this page cannot be altered by the user, the programming algorithm does not need to address this page."

Now, is this why the GPD just wants all these to be 0, since they don't write that last page? I can ignore these? Still doesn't explain why I can't write to the other register bytes required by the design.

It's a good find; I can just ignore the last page for now.

I will start by looking at the datasheet registers table under the reserved portion for singular registers that are not part of the last page. This leaves us with 2 register bytes: CE and CF, with 10 registers to try. E0 I already tried. I'll leave E1 (NPR) and E3 (ERSE) alone.

CE: 4 singular bits CF: 6 singular bits

E0: 4 singular bits (already tried here) E1: 6 singular bits (NPR, probably nothing to do with emulate mode, will leave these alone) E3: 2 singular bits (Erase registers, will not touch these for now)

So if emulate mode is a single settable register, it would be highly likely one of these 10 registers.

The CE register byte doesn't respond to writes, so those 4 registers have nothing to do with emulate mode. CF register doesn't respond to writes either, so those 6 bits are probably not related to emulate mode.

They also refer to emulate mode as (sync). What does this mean?

In the datasheet, there is an 'I2C serial command register map.' It specifies the exact behavior I have. That, reg[74~79];[7B] are read-only even with the RPR in unlock. In the table, there is no mode in the RPR that unlocks these registers. The current values for the counters, reg[7C~7F, can be read but not written to; that makes sense. The table mentions a test mode. Now, what is this? Everything seems to be read-only except for reg[00~47], which shows no read or write. This could be the reserved mode for RPR. I tested it and was not able to write to anything; it probably has nothing to do with emulate (sync) mode.

There is a note that is numbered, but it's not mentioned anywhere else, so there is no context for it: "Note 2 R/W Readable/writable depend on the 'Trim mode enable' bit. If 'Trim mode enable' bit value = 1, then trim bits are enabled." Now, what is trim mode? This is the only line in the datasheet where it is mentioned at all.

There is a note below the other notes: "It is possible to read some data from macrocells, such as counter current value, connection matrix, and connection matrix virtual inputs. The I2C write will not have any impact on data in case data comes from macrocell output, except Connection Matrix Virtual Inputs. The silicon identification service bits allow identifying silicon family, its revision, and others."

The last page contains the silicon identification service bits.

Reading through the Power-On Reset pages in the datasheet, I found something that might be a clue: "The POR system generates a sequence of signals that enable certain macrocells." and "First, the on-chip NVM memory is reset. Next, the chip reads the data from NVM and transfers this information to a CMOS LATCH that serves to configure each macrocell, and the Connection Matrix which routes signals between macrocells. The third stage causes the reset of the input pins and then enables them. After that, the LUTs are reset and become active. After LUTs, the Delay cells, OSCs, DFFs, LATCHES, and Pipe Delay are initialized. Only after all macrocells are initialized, the internal POR signal (POR macrocell output) goes from LOW to HIGH (POR_OUT in Figure 89). The last portion of the device to be initialized is the output pins, which transition from high impedance to active at this point."

Does the emulate (sync) mode set something with the Power-On Reset, so it skips a step and leaves these macrocells configurable?

The official debug tool for multiple-time programmable devices is just connected by VDD, SCL, SDA, and GND. Perhaps the official debug tool is not just an MCP2221A device with tons of protection stuff; there is actually a PowerPAK and a GreenFET on it.

The GPIO from the MCP2221A is used for ACMP, ERROR, SEL0, and SEL1. These are connected to a SLG46582V. Looking at the datasheet and the circuit diagram for the official debug tool, the PowerPAK SLG46582V has 2 LDOs; one of them is connected to the GreenFET. Another pin is connected to the GreenFET (FET_ON). After this GreenFET, there is a circuit with a voltage divider connected to ACMP and a transient voltage protection circuit. Now, is this all only for the over-voltage protection? Or are SEL0 and SEL1 used to enable emulate mode?

The problem is, if I don't use emulate mode, I only have 1000 writes, so if I have problems with the design, I could go through these quickly.

Maybe I'm just searching for a needle in a haystack?

Happy new year!