At present I am trying to get the (un)ported Philips-I2C example for
LPC2148 running (from the ZZZ-unported dir of Martin Thomas' port of the
Philips-LPC 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.

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 (is
this assumption correct?)

Has anyone any suggestions about the main differences between the CARM
compiler and the GNU-ARM compiler, and possible causes for the problem
described above?

Does anyone knows the source for correct functioning interrupt driven
I2C routines working with ARM-GCC?

Thanks in advance,
Edwin

(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