Home/Support/Support Forum/I2C on RCM6700
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

I2C on RCM6700

0 votes
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?

asked Apr 25, 2017 in Rabbit by andyfung New to the Community (3 points)

Please log in or register to answer this question.

3 Answers

0 votes
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.
answered Apr 25, 2017 by TomCollins Veteran of the Digi Community (2,305 points)
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...
0 votes

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.

answered Apr 27, 2017 by andyfung New to the Community (3 points)
0 votes
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:
#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
answered Aug 9, 2017 by TomCollins Veteran of the Digi Community (2,305 points)
edited Aug 9, 2017 by TomCollins