I2c001

[#1]

Hi,
I am new at DAVE and I2C.

I would like to connect a SRF10 to my XMC4500 lite with I2C.
i got the I2C001 (1.0.28) app and wrote(for testing):

   I2C001_Type data1,data2,data3,data4,data5;
   data1.TDF_Type = I2C_TDF_MStart;
   data1.Data = (0xE0 | I2C_WRITE);
   while (!I2C001_WriteData(&I2C001_Handle0,&data1));

i assigned the pin 0.8(SCL) and 1.5(SDA), set them to open drain and connected them with pull up to 5V and to the SRF10.

the whole connection would not work, since i measrure just ~3.9V at SCL and SDA.
I also would like to test if the board sends signals. To what shall I connect the pins to test if they are sending signals?

Greetings
louisk

[#2]

> i assigned the pin 0.8(SCL) and 1.5(SDA), set them to open drain and connected them with pull up to 5V and to the SRF10.
> the whole connection would not work, since i measrure just ~3.9V at SCL and SDA.
> I also would like to test if the board sends signals. To what shall I connect the pins to test if they are sending signals?

I don't think you can pull up these pins to 5V.
According to the data sheet, these are class A pads.
They are limited to min(VDDP+1V , 4.3V), after that ESD protection kicks in.
So you must pull up to VDDP, i.e. 3.3V.

I think you are risking pad damage right now, depending on the current through the protection diodes.
There are bidirectional level shifters like the PCA9306 (Texas Instruments) you could use on SDA/SCL.


Miguel

[#3]

ok thank you. So i need some kind of a level converter to operate I2C on 3.3V and 5V at the same time? i thought there was a standatisation for voltage.

nevertheless. How can i test if there are signals coming out of the two pins?

[AndreasG]

As louisk says, level shifters are the safe way to handle this.

If the current is not exceeding the limits and the other operating conditions are met, the pins of your device currently "experiences" a so-called oveload condition, also described in the Data Sheet. You can do that as well, if you dimension the pull ups such that the specified current and voltage limits are not exceeded. But note that specified electrical and timing characteristics are not valid for this pin while under overload.

A footnote to the I2C timing definition in the Data Sheet mentions pull ups of approx. 10kOhm @100kbit/s and 2kOhm @400kbit/s. With such pull devices to 5V and calculating with the 3.9V you measured at the pin, that would result in a current of ~0.1mA and ~0.5mA via the pull device and into the ESD circuit - far from the specified limits.
When you operate the pin in overload condition, you still also have to check the case when the device actively drives the pin to make sure you do not exceed the short circuit current. With the described pull devices to 5V, currents of ~0.5mA and ~2.5mA respectively are drawn by the pin through the pull devices, not exceeding the specified limits either.

But again, as said above, level shifters are the better way to handle this problem. This also solves a potential problem at the receiver that may have a problem to reliably sense 3.9V as logic "1".
Also remember that while in overload, the constant current also results in an higher power consumption. With a pull up to 3.3V there is just the input leakage as long as the pin does not drive a logic "0".

Regarding your last question, I don't really know the App, but if you configured the USIC as I2C master, the pins as open-drain outputs (Pn_IOCR register), and the output drivers as strong-soft (default) or medium (Pn_PDR register), you should be able to observe low pulses when the device sends data.
Maybe you could also try and read the input value of the pin via software, as you can still use the input functions also while the pin operates as output. But it might be tricky to "synchronise" the software to the actual transmit operation. "Statistically" you should have a good chance to catch a low clock pulse if you just poll the respective Pn_IN bit. After you issue the transmit command, something like while(Pn_IN.x=1) { } should only continue if there is activity on the clock output, else it hang in the loop. But I haven't tested this myself, and it is only something for debugging; even if the transmission and this way of detecting is is working, depending on the transfer rate this loop stalls the CPU for a "while" 🙂


Edit: Added information on the increased power consumption when operating under overload condition.