Work has been very busy, and I caught mycoplasma pneumonia, so I've been down for a couple of days. I never catch any colds going around, but this thing is different, I guess.

I managed, however, to work on using the MCP2221A to access the SLG46826V for programming. However, I've had issues with the MCP2221A. For example, if I plug in the device and set the I2C bus speed, then directly call a cancel transfer command, the I2C engine inside locks up with the I2C state value: 98, and you need to either power cycle the device or do a reset through the reset command.

By sending a write command immediately after setting the bus speed and then issuing the cancel command, the I2C engine does not lock up, and you can use it. However, if you issue a cancel transfer command after a timeout—necessary if you try to read or write to a non-existent device address—then the result of the next command executed seems to be garbage. For example, a write command would report that it completed successfully, even if there is no device at the address. To address this, when implementing my scan bus command, I issue two 0 reads instead of one; the result of the first one is simply discarded. Now, it finds the EEPROM I use for testing at 0x50 and 0x51.

I now have reading and writing from the EEPROM working. Why am I not using the SLG46826V directly? Because you could permanently lock the device if you write bits in the wrong place. The write protection in the EEPROM is just controlled by a pin instead, so if I do something weird, it won't make the device unusable.

Apparently, when I send a read-zero command to the last address of the SLG46826V, the I2C engine in the MCP2221A locks up with the 98 state. I implemented a write-zero command instead, and if I use that to scan the bus, it does not lock up.

Since there is a non-I2C-compliant errata for the SLG46826V, managing issues like this is more difficult when using the MCP2221A. For future projects where I have to use I2C, I'll get a Bus Pirate instead. Having more control is better than having it abstracted away. Being able to see in real-time what the actual communication looks like would be very helpful for debugging and learning as well.

I managed to communicate with the SLG46826V. Now I just need to upgrade Slackware so I can use the software to make a test design. Then, I can write the software to set the registers of the device for testing, and later write software to write them to NVRAM once the design is finalized.