Topic: [Solved] Bug in FPGA I2C slave in GPBB example
The example GPBB FPGA code has a bug where it slightly mangles the I2C bus - I think by tying the bus low when it's not being driven, although I can't see why as the IOBUF statement and constraints configuring it look right. Perhaps the level hold feature on the I/O pins on the Xilinx is stronger than the pullup on the board? I couldn't quickly see an obvious problem.
I noticed this because i2cdetect gives different answers before configuring the FPGA:
root@novena:/home/jamie/gpbb/novena-gpbb-example-master# i2cdetect -y 2
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
and after:
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10: 10 UU 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
Bunnie's FPGA code explicitly instantiates an IOBUF to handle driving the I2C data signal, basically setting it up to either pull low or tristate at any given instant. The code for that looked OK, as did the code to switch between I2C_ACK_DADDR vs. I2C_WAITSTOP (i.e. send an acknowledge for the address vs. ignore someone else's address) so I'm not at all sure why this breaks.
Anyone already spotted and fixed this?