open() function causes MCP2221 to power off GPIO.

[EverythingElseWasAlreadyTaken]

Hi, I've noticed, that since commit #533aebd, the GPIOs are always set to LOW when you are establishing a connection to the MCP2221. I could trace this behavior to these lines, where you rewrite the SRAM settings:

https://github.com/vpaeder/pymcp2221/blob/cd84e337a94eaa4c0f1d32b596f99c7014cff659/mcp2221/__init__.py#L165C1-L167C61

It also doesn't matter if you write the temp state first or just the initial state again, the GPIO is always reset to low. If you remove these lines, the GPIO isn't reset.

I've also found this comment in your code, which could explain this behavior. https://github.com/vpaeder/pymcp2221/blob/master/mcp2221/__init__.py#L1313

[vpaeder]

Ok that's interesting. Turns out I cannot reproduce that. But anyway, it may be that the powerup values in flash are not copied properly. I changed https://github.com/vpaeder/pymcp2221/blob/master/mcp2221/__init__.py#L154 to take pin settings from flash. Please tell me if that helps.

[vpaeder]

Thinking of it that can't be a valid fix since one can re-open a connection to the same device without resetting it. I pushed another commit that should be more appropriate.

[EverythingElseWasAlreadyTaken]

Hi, thanks for the quick help, but sadly this code crashes, when it tries to rewrite the pin_data, since the values are to big for a byte datatype. It seems there is something wrong with the generation of pin_data:

            # merge pin values and directions with data from SRAM                        
            pin_data = [(v & 0xef) | (w<<4) for (v,w) in zip(pin_data, pin_values[2:9:2])
            pin_data = [(v & 0xf7) | (w<<3) for (v,w) in zip(pin_data, pin_values[3:10:2]

This is the output of my debugger, right before it crashes:

-> self._write(0x60, 0, 0, 0, 0, 0, 0, 0x80, *pin_data)

(Pdb++) p pin_data
[0, 2042, 2042, 8]

(Pdb++) p pin_values
[81, 0, 0, 0, 238, 239, 238, 239, 0, 1, 221, 0, 128, 50, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 2, 8, 243, 125, 243, 0, 0, 0, 48, 0, 27, 0, 0, 47, 51, 137, 5, 0, 0, 38, 144, 28, 65, 54, 49, 49, 0, 0, 0, 0, 0, 0, 138, 3, 139, 2, 0, 0, 0, 0]

[vpaeder]

Ok, I guess I overlooked the case of pins set to alternate functions, for which the pin value will read 0xee and the pin direction 0xef. I just capped them to 0xff. Since anyway the pin values for alternate functions won't be set in that way, this won't matter.

[EverythingElseWasAlreadyTaken]

Thanks a lot, this fixed the issue!