Hello, All, :)
I'm having tons of trouble controlling some simple I2C peripherals via a Marvell (nee Intel) PXA270 processor. This processor has a built-in I2C controller, with simple configuration via a few bits in a single register. When looking on a scope, I'm seeing the bus completely hang when placing the target slave address on the bus in a state where SDA=1 and SCL=0. The hang occurs after the first '0' bit is transmitted. So, if the slave address is 0x68 (as is the case for my RTC), then the bus will transmit b'110', SDA will rise, but SCL will never rise after the third bit, and the interface then hangs.
No interrupts occur. The buffer is never reported as empty (ISR[TIE]=0), the transfer never completes (ICR[TB]=0), the I2C unit stays busy (ISR[UB]=1), the bus never changes hands (IBB=0 and ALD=0), and none of the statuses are ever raised (BED, SAD, GCAD, ALD, SSD - in desperation, I'm checking for them all, even if they aren't relevant in master-transmit mode).
The first thing we did is pull the pins on the peripheral chips (a STMicro RTC and a DS I2C-to-1-Wire bridge) to allow the micro to drive the bus in isolation. The *same* behavior persisted!
The scope is registering "spikes" on the clock (SCL) line that occur ~320ns after the micro pulls SCL low. The spikes are on the order of
80ns wide. These spikes were present with the peripherals connected *and* without. Also, regardless of the bus rate (the PXA supports 100kbps and 400kbps), the spikes occur at the same time (~320ns) after SCL falls.I took some snapshots from our scope. The first picture is here:
/i2c_hang.jpg (SCL=yellow, SDA=green)
This shows the first three bits (and *only* bits!) of the slave address being placed on the bus. The START condition (SDA=0 while SCL=1) is clearly shown, and then b'110' is placed on the bus. You can also see the spikes I mentioned occurring at a regular interval after SCL falls, and then the bus just... stops.
The next image is a close-up of one of the spikes, here:
/i2c_hang_glitch_closeup.jpg (SCL=yellow, SDA=green)
This image shows the glitch rising (slowly) for 80ns and then falling again. Because these spikes occur in absence of any other peripheral on the bus, I can only assume that the I2C controller is releasing the SCL line to float and then reasserting it for some reason.
This has been incredibly frustrating and, naturally, Marvell has not been terribly forthcoming with aid. Any help would be *greatly* appreciated!
Thanks in advance!
---Jason St. Jude Medical