I'm having some issues with using Master I2C on a PSoC5LP. I'm working with a FM24C16B I2C FRAM and I'm finding that my I2C bus with this FRAM is sometimes coming up with either one or both signals low. The problem comes when I'm running with debugger attached (MiniProg3) then attempt to reset (Shift-Alt-F5) , it will frequently result in I2C being stuck with either both lines or one line (usually SDA) being held low, and I can't seem to get the bus back into idle state until I power cycle the entire board.
I have 2k resistors for pull-ups and the I2C pins are both set as Bidirectional Open Drain Drive Low with Initial Drive State set to High. The FRAM is the only device on this I2C bus, so the only thing I can imagine happening is maybe the reset is occurring during a transmission and the FRAM is holding SDA low. This should not be occurring though, as the only time I am accessing the FRAM is on bootup, or when I send serial commands to write it from a host PC.
Does someone maybe have a way I could ensure SDA and SCL are initialized to a correct idle state upon startup? I tried doing a "dummy" transmission (just a start condition to address 0x00 followed by a stop condition) after calling I2C_Start() thinking that would get the bus back to idle but this has not worked. This in theory should not be an issue in production as there is no situation (other than maybe entering the bootloader) where the PSoC will be resetting while the system keeps power, but in testing it's proving to be rather annoying to have to constantly power cycle the system when I only want to reset the PSoC in the debugger.
Any suggestions would be appreciated,
I have found (via logic analyzer) what looks to be happening is that when I attach the debugger or reset via debugger, some code runs before it brings the PC back to 0 and breaks at the beginning of main(). It looks like sometimes this can occur in the middle of an I2C transaction with the FRAM, leaving the bus in a non-idle state. Presumably the FRAM is holding SDA low while waiting for a clock from the PSoC. Putting a 1 second delay before I2C traffic begins looks to "solve" the issue, but any other suggestions to ensure the bus is idle on bootup would be appreciated.