LPC11U67 I2C ROM Driver Bug?

[lpcware]

Content originally posted in LPCWare by Belias on Wed Jun 25 05:01:59 MST 2014
I am porting an CMSIS project (previously running on LPC1115) to LPCOpen, because the LPC11U67 is not supported in CMSIS.

But currently the ROM API gives me some headaches.

I dont know if this problem is directly connected to the ROM API Problem but:

I have a test loop, which does the following:

for (i = 0; i < 1000; ++i) {
if (sensorReadByte(MMA8451_ADDR, ACC_WHO_AM_I) != 0x1A) {
printf("Acc WhoAmI Register incorrect %d\n", i);
} else {
printf("Acc WhoAmI Register correct %d\n", i);
}
}

sensorReadByte calls the ROM API for I2C. With very strange effects. The variable i stays 0 all the time (and the code is stuck in the loop forever). After some investigation i found, that the compiler places i inside register r4. But when the I2C Rom API gets called, r4 gets reset to 0 (after it is indeed incremented by one).

If i comment out the call of the I2C ROM API, everything is fine, and the loop runs as expected, so the ROM API call to LPC_I2CD_API->i2c_master_tx_rx_intr(i2cHandleMaster, &param,
&result); screws R4, which should not be the case.

Is this a bug in the ROM API? AFAIK R4 (and above) must be preseved by the method that gets called.

Any Ideas? Thanks!

[lpcware]

Content originally posted in LPCWare by Belias on Thu Jun 26 04:58:36 MST 2014
Managed to fix this, passed a variable on the stack, and was mislead by the fact that you have to include the slave adress in the receive Buffer of I2C, but not include this value in the receive count.

So this was my fault (or the documentation could be a little better :/)

Does it only seem to me like this? The LPC11U6x datasheet is still filled wirthg wrong/hard to understand information?

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Wed Jun 25 06:28:25 MST 2014
You haven't provided any code to show how you are calling LPC_I2CD_API->i2c_master_tx_rx_intr

I assume it is in sensorReadByte, but you have not shown that code.

Also, how is "i" defined? Try making it volatile.

[lpcware]

Content originally posted in LPCWare by Belias on Wed Jun 25 05:40:28 MST 2014
It is LPC_I2CD_API->i2c_master_tx_rx_intr is indeed the guilty one. If I use the same code, but skip the actual call, the stack is healthy and the loop runs correctly. So is there a workaround for this?

[lpcware]

Content originally posted in LPCWare by Belias on Wed Jun 25 05:31:46 MST 2014
After some further testing, it seems like it is not direclty r4 which gets set, but when the encapsuling method returns (and restores r4 from stack) r4 has the value 0, not the one from "i" which it sould have.

So calling  LPC_I2CD_API->i2c_master_tx_rx_intr(i2cHandleMaster, &param,&result); somehow crashes the stack :/ possible?