Color reversal problem

[dougli1sqrd]

The problem

Seemingly randomly (perhaps many times in a row?) the colors on monitor get warped, in a funhouse "inversion". So the picture is maintained, but all the colors are different. I'm pretty sure we know that the inversion itself is caused by chopping our color bytes in two and using the color byte formed by straddling two adjacent colors: so the end of byte 0 joined with the beginning of byte 1.

Just note that we produce color bytes using quad SPI where each nibble from the 4 SPI data bits get formed into 8 bits over two SPI cycles. This occurs in a GAL device which we programmed to perform this kind of quad shift register function.

Ready color bytes are then written into the FIFO memory after the 2 SPI cycles where they eventually get output to the VGA

Observations

• The picture is more or less stable either inverted or standard
  • This means the inverted colors never switch back to standard, and standard never switches to inverted
  • Only a reset of the chip or a power cycle of the whole board will correct (or cause) the colors
  • Picture quality is degraded when they are inverted: the screen wobbles more compared to standard colors.
• Power cycling or resetting the chip can cause the colors to invert (either to inverted or back to standard)
  • Sometimes many resets are required to get back to standard colors
• Did @sethp observe inverted colors on higher input voltage?

Hypotheses

The write signal

The problem could be with the write signal. It's historically been rather contentious in the build. The write signal is an active low signal that takes the built up 8 bit color byte from the GAL and writes the value into the FIFO memory. The signal must be low for a certain amount of time, but the value is actually "written" once the signal goes back high. So it's crucial that the write go high during the correct phase of the color byte. If the timing of the write ever become early or late for some reason then the color that would be written would be inverted.

We would have to explain why the write signal would be so consistently late/early across a power cycle though, or never correct itself. Why would it stay a certain way the entire time power is on? If the write signal could vary as much as ~15-25 ns in either direction, why would it stay late or early per power cycle?

This has been my normal casual explanation of the behavior since it was difficult to get the timing right, but I think the above shows how that could be in error.

The SIPO chip

If the SIPO GAL chip that turns our 4 bits into 8 over the course of two SPI cycles maintained some state or started its state in the half phase, then it would have no way of correcting itself except for a power cycle. How it maybe gets into this state I have no idea.

The CPU

The CPU issues SPI writes to the SIPO chip. We decide on the "Mode" of the SPI which determines where we should be observing the SPI clock pulses. Is it possible that the SPI gets "stuck" in a half phase state and our hardware either misses the first nibble of the first byte, making the entire frame and video output inverted until a reset?

Combination CPU and SIPO chip

Lastly it could be some combination. All we need is the initial nibble to be in a half phase somehow. Perhaps on reset, but with power maintained, the SIPO chip is in a half phase still and then subsequent writes to the chip cause all following colors to be inverted.

[sethp]

Did @sethp observe inverted colors on higher input voltage?

It's hard to say; when my input voltage was too high (because I was plugged into the USB ports in the back of the machine, which, I guess are more robust?), the VGA->HDMI converter I'm using decided it didn't like the signal enough to bother emitting a picture at all.

I do still see the color inversion in our hardware from time to time at my lower normal operating voltage (~3.9v); I haven't tracked how often it occurs, though.