I2C on RCM6700

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,

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.

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,

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,

Which sample are you trying to compile, what hardware are you using, and what configuration macros have you defined? Are you trying to run as an I2C master or slave?

Hello,

Thanks for replying.

I am using MiniCore 6700 module. I am trying to compile the sample C:\DCRABBIT_10.72B\Samples\I2C\I2C_24LC16.C.
In Dynamic C 10.72B Option->Project Option->Targetless, “162MHz, RCM6700, 1M+32K RAM, 1M serial program flash” is highlighted. I am trying to run as an I2C master.

Thanks,

Try defining “I2C_OMIT_SLAVE_CODE” in your project defines, or at the start of the .C file. I’m investigating this now, and it appears the slave code wasn’t included in an earlier update. I’ll look into disabling it by default, but adding that macro definition should resolve the compilation problems.

Thanks for your solution. The HW I2C is working. Can you also suggest a way to configure it to 400kbps? Thanks.

Take a look at _I2C_initClk(). The library defines I2C_DEFAULT_CLK to 807 for 100kHz, so you should be able to define it in your code as 807/4 (202) and see a 400kHz clock. I’d be sure to confirm that using a logic probe or scope.

Thanks.
I have another question on port B. I am trying to set PB0 as an output. The following code is to set PB0 to output:

WrPortI(PBDDR,&PBDDRShadow,0xC1);

And I try to toggle it by:
BitWrPortI(PBDR, &PBDRShadow, 0, 0);
BitWrPortI(PBDR, &PBDRShadow, 1, 0);

However, PB0 does not toggle. Do I need set PB0CR to set a pull up resistor to PB0? If yes, what is the shadow register for PB0CR?

Thanks

Please create a new forum post with this question and I’ll answer it there.

If the I2C slave do not response back to Master (RCM6700) and the SCLK signal is held down, does RCM6700 support clock stretching?
Thanks

There is a time out config I2C_SLAVE_CHECK_TIMEOUT_MS (default 10ms) in I2C_HW.lib. Is this time out used for clock stretching?

Thanks

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).

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 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.

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…

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