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:

<blah blah>/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:

<blah blah>/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

I have used the PXA270 I2C interface and it works fine.  

One thing that will often make I2C peripherals hang is if the bus does not
have the right pull-up resistors on SCL and SDA.

If the SLC, SDA lines do not toggle correctly the PXA270 I2C peripheral is
likely to think it has lost bus arbitration to another master I2C
controller and so will back off to allow the other bus master to continue.

I could not see the pictures – but the PXA270 does tend to put a lot of
noise on its I/O pins, but an 80ns pulse should not affect I2C.  Its a long
time since I saw the PXA270 I2C waveforms so I can’t comment if we saw
the same type of glitch.

Hope that might help

Bocote

jasontiller wrote:

> 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.

I have had the same problem with this CPU. Even issuing a I2C reset, like
described in chapter 9.8 of the datasheet, doesn't work. Intel couldn't
help, they wanted a reproducable situation, but it occured very seldom
(though I was able to force it sometimes when applying a signal generator
to SCL with a resistor and adjusting the frequency) but then only power
down/up the CPU released the bus. I fixed it by connecting one of the GPIOs
of the PXA to SCL and forcing SCL to high for some short pulses when I
detected the bus stall.

Do you know if the PXA270 chip is still produced? Some time ago I heard
something about 2009 for last orders, but maybe this was Intel and Marvell
changed the plans?

-- 
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de