(copied here from my answer to Edwin's e-mail with the same content for
reference)

> At present I am trying to get the (un)ported Philips-I2C example for
> LPC2148 running, but the behaviour is flaky and very unreliable. (it
> came in the ZZZ-unported dir of your port of the Philips code
> examples). Although the interrupt routine reaches a 0x08 state
> (I2C-started), the I2Cstart routine always times out (so the
> I2CMasterState == I2C_STARTED) is never detected. The physical
> communication however appears to be correct (on scope) for roughly 8
> times out of 10. In those cases a valid response from the slave (a
> LM75 temperature sensor) can be seen. Also situations occur where the
> SCL keeps running continuously until the I2CStart routine times out.

Hmm, well, I have not used I2C with an LPC so far. And since I did not
have a test-setup at hand while porting the examples so I did not port
the I2C-example.

> I probably lack knowledge in the complex interrupt handling situation
> (although in this case I believe only the standard VIC interrupt is
> attached and running, so no complex wrapping or nesting is in place)

In lot of the Philips code of the examples I have ported volaties where
missing (this is mentioned in my readme-file). Check the code if there
are any variables accessed (read/write) inside the
interrupt-service-handler and the main-program . Add volatilies to these
variable and give it a try. Please report your findings also to the
forum so others can follow the and may provide addtional suggestions.

Can you monitor if the default interrupt-handler is called (increase a
counter inside the ISR)?
Can you try with increased stack-sizes?

> Do you have any suggestions about the main differences between the
> CARM compiler and the GNU-ARM compiler, and possible causes for the
> problem described above?  If you can't, won't  or lack time, could
> you point me into the direction of someone (or forum) where I can
> search for a solution?

I don't realy know the differences since I do not know enough about the
Keil Tools. For me it seems the optimization works or has been
configured differently. Obviously the code published by Philips/NXP did
work with the CARM. I don't think that they have published untested
code. But the missing volatiles in several examples broke the binary
since the GNU-compiler optimized so the variables have been kept in a
core-register (I have used -Os). Maybe the original test-code has only
been built with optimization turned off in the Keil-IDE.


Hope this helps,

Martin Thomas