I2C on RCM6700

Question

I am using Dynamic C 10.72B and tried to run I2C sample code. When I compiled the code, I got the following errors:

line 536 : ERROR I2C_HW.LIB : Value 150 is out of range, valid values are between -128 and 127
line 648 : ERROR I2C_HW.LIB : Value 201 is out of range, valid values are between -128 and 127

Can you please give any suggestions?

Thanks,

Answer 1

Thanks for reporting that error -- if you change the "jr" on those two lines to a "jp", it should resolve the issue. I'll push a change up to the GitHub repository. Please let me know if you have any failures after that change.

"jr" is a relative jump but has a limited range.

"jp" is an absolute jump and can cover greater distances.

Comments

That is not related to stretching.  Based on searching the libraries and Rabbit 6000 manual for "stretch", I don't believe the I2C interface supports clock stretching.  You can read about the capabilities of the Rabbit 6000's hardware I2C interface in section 35 of the Users Guide (http://ftp1.digi.com/support/documentation/90001108_H.pdf).

---

I think the I2C interface does at least support clock stretching in slave mode as the TB_EN bit is cleared automatically when a byte is transferred and is then set when we are ready to transfer another byte. This causes clock stretching at the byte boundary as clk is held low until this bit is set.
I'd suspect that it is also supported on the master side (i.e. waiting for slave to release clock) but you would need to do some simple testing with a scope to determine this for certain.

---

So what is the time limit of the Rabbit master can wait for salve for reading from salve? I checked the document it does not have this value.

---

I'm sorry, but I don't know.

---

In my experience, for normal I2C operation this is usually unspecified and can be infinite! You are advised to check for this condition by other means in most cases (e.g. checking port pin levels periodically etc). Only I2C devices supporting SMBUS or similar protocols are required to have an upper bound on this and it is supposed to be monitored by the master and slave. "Normal" I2C will usually lock up if the bus is never released...

Answer 2

Hello,

After the change jr to jp, still getting other errors:

line 564 : ERROR I2C_HW.LIB : Undefined (but used) global label isWrite
line 577 : ERROR I2C_HW.LIB : Undefined (but used) global label I2C_ISR_State
line 591 : ERROR I2C_HW.LIB : Undefined (but used) global label .i2c_unknownInt

Please advise.

Thanks,

Answer 3

Note that I am currently investigating an error in I2C_HW.LIB from the 10.72B release, related to how we processed the slave address in calls to I2CRead() and I2CWrite().

Previous versions of those calls for software-based I2C expected the slave address as the upper 7 bits of a byte, but a change to 10.72B expected them as the lower 7 bits.

I intend to revert the change for the upcoming 10.72C release. To write code compatible with both 10.72B and 10.72C, you'll need to use conditional code to define the device addresses, like so:

Code:

#if defined(I2C_USE_RABBIT_HW) && !defined(CC_REV)
	// Unlike other releases, DC 10.72B expects the address in lower 7 bits.
	#define ADP5585_ADDRESS					0x34
#else
	// I2CRead() and I2CWrite() expect slave address in upper 7 bits.
	#define ADP5585_ADDRESS					(0x34 << 1)
#endif