Protection of I2C inputs on XMC1000

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
User8683
Level 4
Level 4
First like received
Hello,

My application involves pluggable I2C components and I have found that I am burning out the pin fairly often resulting in the XMC1000 chip being able to be "pinged" via I2C but unable to respond to data read requests. As such, I am trying to figure out what sort of series resistance I can add to the SDA and SCL lines to limit the current. Based on my understanding, the pins can only handle 10mA OR 11mA (two different values are provided pages 24 and 27) in a short circuit which means that for 3.5V direct input, I would need >350 ohm resistors in series. If I use a 1.8Kohm pullup and 360ohm series resistor, this would mean the pulled down voltage would be 360/(1800+360)*3.5 = 0.58V.

I am wondering if this will work because I am trying to understand if the following applies:

0.19*Vddp given on page 26 for the "Input Low Voltage on Port Pins" which would be 0.19*3.5V = 0.67V if I am understanding this correctly.

from this document:

http://www.infineon.com/dgdl/xmc1100_ds_v1.4_2014_05.pdf?folderId=db3a30433580b3710135a47f3eb76c98&f...

If this is correct, I would also like to know what would be considered a reasonable buffer voltage to ensure that a low voltage is always read as low.

Thanks,

Jason
0 Likes
22 Replies
User8683
Level 4
Level 4
First like received
Hello,

Further to my question asked yesterday regarding protection of I2C inputs, I am using the same I2C pins for initial programming of the chip as well in ASC mode so I would like to understand what the limitations on series resistance into the UART pins are. I have managed to confirm that I can put 360 ohms in series into the clock pin P0.15 without issue, but I cannot seem to use even close to the the same resistance for the data pin P0.14.

Unfortunately, Memtool is very unstable in terms of its ability to connect even directly to the chip even on a TSSOP to DIP adapter with no other connections. Sometimes it can connect and reconnect over and over without error. Other times, it does not connect unless the board is reset and memtool is relaunched. It also provides no useful information as to which stage of the communication failed or the type of the failure. I have also found it unable to connect to the board at anything other than 28800 or19200 baud so I cannot slow the transmission down. Nor do I see any option to delay any timeout if that is what is happening. All of this is making for a very frustrating experience in trying to both find possible values of resistance to use to protect the pins and in just programming the chip.

Any suggestions would be appreciated.

Thanks,

Jason
0 Likes
User8683
Level 4
Level 4
First like received
Hello,

I am still having considerable problems with the I2C communications and I am not sure what the cause might be. I can successfully program the XMC1000 16pin chip using ASC on pins P0.14 and P0.15. I can "ping" the chip with I2C to get an ACK on the same pins but I cannot read from the chip using I2C. The SCL and SDA lines get pulled low and stay there. This does not happen in communicating with the XMC2Go. I have also noticed a difference in the signal between the XMC2Go and the XMC1000 16pin chip. The difference can be seen in the two attached captures. The XMC2Go has a small step highlighted by the red oval whereas that same step is missing on the XMC1000 16pin chip.





Can someone from Infineon please tell me what the step or its absence means?

Regards,

Jason
0 Likes
Travis
Employee
Employee
First solution authored Welcome! 500 replies posted
longtimer wrote:
Hello,

Further to my question asked yesterday regarding protection of I2C inputs, I am using the same I2C pins for initial programming of the chip as well in ASC mode so I would like to understand what the limitations on series resistance into the UART pins are. I have managed to confirm that I can put 360 ohms in series into the clock pin P0.15 without issue, but I cannot seem to use even close to the the same resistance for the data pin P0.14.



So sorry that I need to understand the issue that you are facing.

1. Do you mean that after connecting 360 ohms in series to both the data and clock pins, you are not able to establish communication with the memtool?
2. Are you using ASC for flash programming with memtool and reusing the same pins for I2C communication in your application software?
3. May I know why are you connecting the 360 ohms in series into the clock pin?
4. Which device are you using?
0 Likes
Not applicable
Hi Jason,

As mentioned in the other thread, the pins and configuration are the same for both device.
So could it be the problem from the your target board implementation?
For your target board with XMC1100, is the hardware have the similar configuration as XMC2Go?
0 Likes
User8683
Level 4
Level 4
First like received
Travis wrote:
So sorry that I need to understand the issue that you are facing.

1. Do you mean that after connecting 360 ohms in series to both the data and clock pins, you are not able to establish communication with the memtool?
2. Are you using ASC for flash programming with memtool and reusing the same pins for I2C communication in your application software?
3. May I know why are you connecting the 360 ohms in series into the clock pin?
4. Which device are you using?


1. Yes that is correct.
2. I am using the ASC for flash programming with memtool and reusing the pins for I2C communication
3. The 360 ohm resistors are to protect the SDA and SCL pins from overcurrent since my application involves pluggable XMC1000-based devices on the I2C bus.
4. I am using the 16pin 64K XMC1100 with the following markings:
1100 X
064AES
015
GE345
0 Likes
User8683
Level 4
Level 4
First like received
The target board has been reduced to the simplest implementation with only Vdd, Vss, SCL and SDA (using P0.14 and P0.15) connections. The software is the exact same on both boards. Since I was having problems with my target boards, I moved to a protoboard (TSSOP to DIP) in order to isolate the problem. I see the same difference in electrical characteristics on both the target and protoboards, but not on the XMC2Go.
0 Likes
Travis
Employee
Employee
First solution authored Welcome! 500 replies posted
longtimer wrote:
Hello,

Further to my question asked yesterday regarding protection of I2C inputs, I am using the same I2C pins for initial programming of the chip as well in ASC mode so I would like to understand what the limitations on series resistance into the UART pins are. I have managed to confirm that I can put 360 ohms in series into the clock pin P0.15 without issue, but I cannot seem to use even close to the the same resistance for the data pin P0.14.


Hi longtimer,

1. Do you mean you are only able to see the clock pulses but not the data from the oscilloscope for the above mentioned resistor connection?
2. Can you please share the circuit diagram for this connection?
3. Did you switched to user mode after flash programming?

BR
Travis
0 Likes
User8683
Level 4
Level 4
First like received
Hi Travis,

1) I can see both the SCL signal and the SDA signal on the oscilloscope. It is just that the communication does not work. However, there is nothing about the logic levels that would suggest the signal is affected. The highs and lows are at the right location. I have also observed that I can use the 360 ohm protective resistors on an XMC2Go but not with a TSSOP-16 XMC1100 using only the Vdd, Vss, SCL and SDA lines.
2) The circuit diagram is attached. It is as simple as it gets. To test, I am only using Vdd, Vss, SCL and SDA.
879.attach
3) I have switched to user mode and the I2C communication works alright without the protective resistors. It still gets stuck low on either the SCL or SDA lines fairly regularly, however.

Regards,

Jason
0 Likes
User8683
Level 4
Level 4
First like received
Its been a week since the last update on this and I was the one who made it. Can I get an update on this?

I would have preferred to use the VQFN24 chip which seems to work but was told it was unavailable until 2014Q4. It is now 2014Q4 and there is still no update as to when the VQFN24 version of the chip will be ready and there are differences in chip operation for I2C that I have not seen documented making for a lot of wasted effort.
0 Likes
User8683
Level 4
Level 4
First like received
Is there any update on this?
0 Likes
Travis
Employee
Employee
First solution authored Welcome! 500 replies posted
Hi longtimer,

we tested the memtool with the below connection and it is working good. Maybe you can remove your I2C master to narrow down the problem.

Best Regards
Traivs
0 Likes
User8683
Level 4
Level 4
First like received
Hi Travis,

Please elaborate on your testing. Your short response does not tell me enough and your diagram does not make sense to me. When I am using memtool, the XMC device is not connected to the I2C master. At the point of programming, I only have the XMC 16 pin device with resistors in front of the P0.14 and P0.15 inputs. The ASC communication goes through these resistors.

Can you tell me:
1) Did you test with a XMC1100 16 pin device?
2) Can you tell me what the XMCOBD is supposed to be in contrast to the XMC1100 device on the right of the image. I would be programming the XMC1100 device
3) Did you have ~350ohm resistors on the P0.14 and P0.15 pins between the PC memtool and the device on the ASC lines. What you showed just looks like another XMC device with connection to the bus being programmed directly without any protective resistors

Thanks,

Jason Kania
0 Likes
Travis
Employee
Employee
First solution authored Welcome! 500 replies posted
Hi longtimer,

So so sorry for the short response and I shall try to be more detail this time.

Hardware connection
We did hardware setup exactly the same as what is being described in the picture with the 4.7K and 360 resistor with Vdd = 5V. The XMC OBD (On Board Debugger) SD is connected to P0.14 and SC is connected to P0.15 for ASC flash programming. Currently we are using XMC1100 TSSOP38pins as we do not have 16pins package.



Can you tell me:
1) Did you test with a XMC1100 16 pin device?
No, we do not have any 16 pins package. Which XMC evaluation kit to you have at yourside?

2) Can you tell me what the XMCOBD is supposed to be in contrast to the XMC1100 device on the right of the image. I would be programming the XMC1100 device
The XMC OBD (On Board Debugger) serve 2 purposes for debugging and flash programming with Memtool. For ASC flash programming it basically translate the ASC signal to USB signal.

907.attach

3) Did you have ~350ohm resistors on the P0.14 and P0.15 pins between the PC memtool and the device on the ASC lines. What you showed just looks like another XMC device with connection to the bus being programmed directly without any protective resistors
We connected the resistor as shown in the picture and we did not include any I2C master.

Lastly I hope we are on the right track to investigate your issue.

Best Regards
Travis
0 Likes
User8683
Level 4
Level 4
First like received
Travis,

Thanks for the detailed response.

I am not currently using a development kit as I am trying to create the same setup that I have for my in-circuit MCU where I have the same problem. All I am doing is using a null modem cable from the PC to a high speed RS232 buffer chip. From this buffer chip, the connection goes to the P0.14 and P0.15 pins of the XMC through the resistors. I am using 3.5 V to drive the lines so the first thing is whether this voltage is too low? Secondly, does the XMC OBD do any signal conditioning or buffering to make the communications more robust?

In addition, I wanted to point out that I use the same RS232 buffer chip and null modem cable for programming another type of MCU in the system and it works fine there. The only difference is that there are no protective resistors in front of the inputs to the other MCU.

I will try programming with a 5V input to see if that works, but is it possible from your end to test a scenario with just an RS232 chip and the resistors in between the PC and the XMC1000? From my understanding, this is the most basic way that a person should be able to program the MCU in circuit.

Thanks,

Jason
0 Likes
Travis
Employee
Employee
First solution authored Welcome! 500 replies posted
longtimer wrote:
Travis,

Thanks for the detailed response.

I am not currently using a development kit as I am trying to create the same setup that I have for my in-circuit MCU where I have the same problem. All I am doing is using a null modem cable from the PC to a high speed RS232 buffer chip. From this buffer chip, the connection goes to the P0.14 and P0.15 pins of the XMC through the resistors. I am using 3.5 V to drive the lines so the first thing is whether this voltage is too low? Secondly, does the XMC OBD do any signal conditioning or buffering to make the communications more robust?

In addition, I wanted to point out that I use the same RS232 buffer chip and null modem cable for programming another type of MCU in the system and it works fine there. The only difference is that there are no protective resistors in front of the inputs to the other MCU.

I will try programming with a 5V input to see if that works, but is it possible from your end to test a scenario with just an RS232 chip and the resistors in between the PC and the XMC1000? From my understanding, this is the most basic way that a person should be able to program the MCU in circuit.

Thanks,

Jason


Hi Jason,

I believe this is a hardware related issue and I might have to check with my colleague.
So sorry. We only take reference from our evaluation board to troubleshoot problems.

Travis
0 Likes
Travis
Employee
Employee
First solution authored Welcome! 500 replies posted
Hi longtimer,

We just received a XMC1100 16 pin socket board and the first thing we did was to find out if this issue actually exist. We did the same connection on the XMC1100 16 pins package with Infineon memtool and it is working good.

Did you change the BMI setting of the XMC1100 to ASC BSL mode before making connection with the Infineon memtool?

Please also note that you have to switch back the BMI to user mode after flash programming.

Best Regards
Travis
0 Likes
User8683
Level 4
Level 4
First like received
Hi Travis,

The BMI setting is set with the ASC BSL with timeout. That said, the issue is not the BMI setting as I previously mentioned that the issue occurs mostly with the resistors inline and occurs for some types of I2C traffic but not all.

Were you able to test with the serial 350-360 ohm resistors in line and using the 16 pin device?
Can you see the differences in signal that I mentioned previously and included an image for? Can you explain these?
Were you able to test with the XMC2Go and 16 pin device in parallel on the same I2C bus with an XMC master?
Could you please diagram your connection from PC to board?

These sorts of answers might help to explain any differences.

Thanks,

Jason
0 Likes
Not applicable
Hi Jason,

With our current available setup, we have tested with the I2C communication with 10K pull-up resistor instead of 4.7k.
With the 10k pull up, the communication is working well and I could say is quite stable (no communication error so far during our testing).
However, we have yet to test with the 360ohm series register.
We will try it and get back to you on our result at the soonest.

In the mean time, do you mind to try with 10K pull-up resistor and see if the communication improved?
0 Likes
User8683
Level 4
Level 4
First like received
Hi Jackson,

Can you elaborate on your test setup?

In my case, the 10K resistor is not possible because the I2C master requires more current than that to operate and I have multiple I2C slaves on the bus. 10K is fairly high to use for I2C in any case. Did you find that 4.7K did not work in your case?

Thanks,

Jason
0 Likes
Not applicable
Hi Jason,

We managed to test with 360ohm series register and 10K pull-up.
From our test, the communication is working fine.
Currently we only test with 10k pull up as that is what available on our test board.
We did not try with 4.7k pull up yet, so I can't really comment on the behaviour if 4.7k is used.
Let me see what I can do to test it with 4.7k pull up.
I will update you on our result.
0 Likes
User8683
Level 4
Level 4
First like received
Jackson,

Sorry, to make it clearer, can you show me a diagram of your test setup so that we are comparing similar setups? Do you have a XMC2Go on the same bus as a 16 pin XMC1100 chip with another chip acting as the 12C master?

Thanks,

Jason
0 Likes
Not applicable
Hi Jason,

We use XMC1200 as Master and directly connected with XMC1100 TSSOP16 as slave.
The Master will send a read request and Slave return with a data.
959.attach

Can you give it a try by just connecting to one slave instead of two?
This could narrow down the finding of the root cause.
0 Likes