SPI flash and FT2232H signal contention during the USB enumeration process

[Disasm]

Steps to reproduce:

1. Build and flash:

   git clone https://github.com/Disasm/icebreaker-litex-examples
   cd icebreaker-litex-examples
   git checkout serv
   git submodule update --init
   cd soc
   ./icebreaker.py --cpu-type serv --cpu-variant standard --sys-clk-freq 12000000
   iceprog soc_basesoc_icebreaker/gateware/top.bin
   cd ../r-riscv-blink
   cargo run --release

2. Unplug the board.
3. Plug the board back with the same cable.
4. Observe that it blinks for a while and then stops blinking.

You can also plug it slowly to connect USB power first and connect USB data lines in a few seconds. Then you can observe that the firmware works until you insert the connector to the end. Also when you use "charging only" USB cable, the issue doesn't happen and the firmware works all the time.

I tried to investigate the issue with a logic analyzer and found that SPI data lines are pulled up for a short period of time (about 2.7ms) during the USB enumeration process. This behavior can be reproduces with a more simple setup. I used an FTDI breakout board (FT2232H Breakout Board from Dangerous Prototypes) and hooked a 10k resistor between GND and ADBUS2. I chose ADBUS2 because it corresponds to the IO1 signal on iCEBreaker and this signal had the most distortion among others. The EEPROM on this breakout board was empty, so I flashed it with the configuration from my iCEBreaker board. When I captured signals from ADBUS2 and EEPROM lines (EEDATA, EECLK, EECS) I found exactly the same glitch on the ADBUS2 line: instead of being low all the time, it goes high for about 2.7ms. This time interval coincides with a long EEPROM read burst. If I erase the EEPROM, this read burst disappears and the glitch does not happen.

[smunaut]

The other contentions I have noticed are :

• When the EEPROM is not configured one of the line is driven constantly (can't remember if it's from boot or only after one iceprog cycle ...)
• After running iceprog, the reset line is released and the fpga configures but the data lines are still being messed with for a tiny amount of time. This doesn't seem to prevent the fpga from configuring because it overpowers it at "low speed", but when trying to run the flash at high speed (100+ MHz) the signal is too damaged and it makes it unreliable.