It's been a busy couple of months I've not had much time to work on this project which is a bit sad. I'll recap what I've been able to do on the project.

I had problems programming one of the SLG46826 greenpak's LUTs with my hacked together tool.

I made a better driver for it, I took a look at other projects that make use of the MCP2221A and the offical linux driver source code. I got to know some of the blackbox secrets from them, so I was able to make a pretty solid driver.

I used the eeprom again to test my driver it worked perfectly fine writing and reading even at the maximum amounts of bytes. HID which the mcp2221A is using is pretty slow when it comes to large datatransfers. 64 bytes per transaction.

I made it as fast as I could with my driver. The MCP2221A buffer is just 1 byte short to read an entire eeprom block in one go. It's fast reading the eeprom but getting the data out of the buffer takes some time using the HID protocol.

So then I started writing my greenpak cli tool and all of a sudden I was getting these NACKs when I should get ACKs. I guess I'll just use a logic analyzer to see what is going on. I used one of the rp2040 logic analyzer firmwares connected it up and tried capturing the traffic. I got a lot of garbage due to the fact I had no buffering or anything for the signals.

That didn't work so, I vagely remebered that I had read about a logic analyzer software for the beagle bone black. So I looked into that and I couldn't find the software image the link was dead. I tried compiling from scratch didn't work as the source didn't specify which version of linux it was using and since alot of the offical beagle bone versions of linux had changed how to access the bbb peripherals. It was just a waste of time.

This was the 3rd time I've tried using the beagle bone black for a project and just wasted time on getting it to work.

So I went for my oscilloscope and it work fine capturing the signal but I'm not good at decoding I2C by looking at the traffic so I hooked it up to the pulseview program and captured the data again. Since the signals are analog I can not attach a decoder to them.

I ordered one of those old saelae logic analyzer clones and when I used that I got the traffic just like that. I could even capture reading the entire block of the eeprom easily as it has tons of memory.

I quickly found the problem with my driver, I was using 7-bit addressing with the eeprom tests and the greenpaks datasheet specifies the addressing using 8-bits with the read and write bit attached which I assumed was needed so the address was shifted twice. 

So dropping the last bit from my control byte solved the issue. So it wasn't a problem with the driver, but rather me being confused that 8-bit addressing is a thing which is not since the last bit is part of the protocol framing. The more you know.

Then alot of things happened and I've finally secured a room for my lab. :)

Hopefully I can get something set up in there this month.