There are many ways I could just keep going with my project, use an additional SLG46826V module or just skip the OVLO but I want to find out why I can not write the first byte.

Like before I can not write the first byte of the SLG46826V greenPAK module.
Now why doesn't it work?

The LDO supplies stable power to the greenPAK and the decoupling caps are close to both VDD's. I noticed that there are small tiny decoupling caps on both VDD's on the module itself. Thus my extra caps are really not needed.

Datasheet says "The VDD pin requires a voltage ranging from 2.5 V to 5.5 V for Programming and Erase operations." I read 3.28 Volts.
It's only the first byte, I before tested to write all pages backwards same problem.

I tried flashing the NVRAM as well and did an hard reset, didn't work. Since the LUT has not be set up I have no interrupt at all.

I asked the GPT about it and it spitted out this markdown tech note for me.

# ChatGPT Tech Note: SLG46826V Byte 0 Programming Gotcha

## Issue
When programming the SLG46826V via I²C, all configuration bytes appear to update correctly except for byte 0 (address `0x00`) in page 0. Attempts to write to this byte in RAM or NVM appear to fail — readbacks show the old value.

## Root Cause

**Byte 0 is special.**

- It is the first register loaded from NVM into RAM at power-up.
- It often controls critical startup logic — sometimes related to I²C behavior, internal routing, or clock enable signals.
- To prevent accidental bus disconnection or logic instability, the chip blocks writes to this byte in RAM via I²C.
- Only a reset (power or software) will update RAM with the value from NVM at byte 0.

## Solution

To properly program byte 0:

1. Erase Page 0 using the standard NVM erase command (write `0x8E` to register `0xE3`).
2. Write your desired 16 bytes to Page 0, including byte 0 at address `0x00`.
3. Wait for the NVM write to complete (`tWR` max 20 ms or use ACK polling).
4. Trigger a reset:
   - Power cycle the chip
     **OR**
   - Send a software reset by writing `0x02` to register `0xC8` (RAM block 0)
5. After reset, byte 0 in RAM will now match what was written to NVM.

## Verifying Your Programming

| Address   | RAM write works instantly? | NVM write needs reset?                     |
|-----------|----------------------------|--------------------------------------------|
| `0x00`    | No (masked)                | Yes (requires reset to take effect)        |
| `0x01–0x0F` | Yes                     | Yes (effect visible immediately in RAM after write) |

## Example Reset Command (Soft Reset)

## Notes

- This behavior is not explicitly documented in a single section of the datasheet or ISP app note.
- It is inferred from testing, forum replies, and hardware behavior.
- Applies to the SLG46826V and similar GreenPAK devices.

I tried it and it didn't work. GPT's are scary.

It searched the web for quite a long time coming up with it, it's probably mixing data for greenPAKs.

I looked at the programmer and noticed that I had a 0.01uF decoupling cap for the mcp2221A so I switched that to an 0.1uF. Just to make sure there is no issue there.

I soldered a new slg46826V module and I have the same problem with that one, first byte can not be written to.

I'm pretty sure that it is a problem with my programmming. But I wrote the pages backwards and I had the same problem. There is perhaps a problem when setting the page address for page 0x00.

I'll refactor the greenPAK tool code and make a cli interface for it. Hopefully going through the code I might find the problem at least I will have a more easy to use programming software.