Hi Everybody, I'm experimenting with Infineon's XC161CJ-controller on an Infineon SK-XC16x starter kit. Most of my routines work now, except the I2C-routines. Sending of data works OK, but the errors occur when I want to receive data. Has anybody on this forum written I2C-routines for this controller? And if so, are you willing to share them? Thanks in advance. :) Kind Regards, Dennis Ebben
Hi Dennis, I am currently working with the XC161CJ & the I2C Module. I am using the routines generated by 'Dave'. Haven't got it working yet though... Are you willng to share your code ?, maybe we can help eachother out. Regards, Rolf
Hi, I am FAE for Micro in Germany. I got the following feedback from our end costumer and think it may be usefully for you. Concerning the DAvE generated files there seems to be a "ugly" point. I translate the original message: "Concerning the I²C-interface there are two interrupts 'protocoll' and 'data' interrupt." The costumer was wishing only the data interrupt, "BUT DAvE is generating a interrupt handler for data interrupt with a JUMP to PROTOCOLL interrupt !" If you have first look at the generated code this not visible for you, because both interrupt vectors lay directly each one the other in memory. The first 'data interrupt ' mis initialized by the compiler with twice 0xFFFF what is equal to BSET R15, bit 15. If a data interrupt occurs than twice a BSET R15, bit 15 is executed, before the generated ISR handler is called." The costumer had not selected the register bank switch and so the register R15 was not saved (by the way: it was not used by handler routine). "What exactly happened ? All things went fine, but from time to time the most upper bit of R15 was changed to '1', what is not noted the first view, because this bit is used very seldom. Only if the compiler assume (assign ?) in function the register R15 a word variable (this istoo very seldom) the suspectly errors occur." To find this we needed 2 days. Than we noted an other thing. You need under some circumstances a extra dummy access to read back with the I²C-module. OK, that's is all I know about this, but may be it can help you to find the wrong code sequences. MESSAGE: Do not believe the DAvE can all do for you! We at this time work on a DAvE bug list. (Yes we really found some DAvE bugs ) The second: The I²C module was tested - I had contact to the developer and the test engineer, but with the hardware implementation there are some difficulties. Stefan
Hi Stefan! I'm also working with a XC161 and i didn't get my routines working. Can you please send me the routines. Thank you in advance. email: tinytove@gmx.at
Hi Ludwig, I sent it. Sorry for delay. Stefan
Hello Stefan, i have the same problem XC167 with 24LC16B serial eeprom. would you please send me the routines? Thomas
Hi Thomas, that is no problem, but I need your e-mail address to send it. Best regards - Stefan
Hello Stefan, my email address is thomas.schneider@berger-lahr.com thank you Thomas
Hi Thomas - done !! Stefan
Hi Stefan, could you (or someone who have also the code) please send me IIC-code? best regards, Karl E-Mail:koarl70(at)gmx.at
Hello Stefan: I'm working with XC167CI and want to change my bit banging routines from C 167 CS to the new hardware IIC Module. Reading the treads about this theme, I want to ask you if you could please send me the routines to use the IIC hardware. Thanks a lot! christian.winkler@winkler-urach.de Christian
Hi Karl, hi Christian, Do it in some minutes. Sorry for delay, I was on vacation. Stefan
Stefan, is it possible to share your I2C code? My e-mail address is georg(at)eunet.yu With best regards, Gyoergy Dozsa
I'm working on a Multimaster-system with 2 xc167 connected via i2c bus and i think i have a timing problem becouse the system is not very stable. If anybody got a working multimastersystem it would be nice to share some code with me. Thanks peter.scheuermann@ies-systems.com
Dear Stefan as many others I have problems to get the I2C routines on the XC161CS-32F working. I would appreciate if you could share your code. My email:dhandzic@plantron.se
Hello Dirk, I sent it, please check your account. Stefan
Really nice to see that this topic is still interesting for a lot of people. :)
Hallo Stefan, Könntest Du mir den Low-Level-Treiber von Infineon auch zukommen lassen. Habe auch Probleme den I2C-Bus ans laufen zu bekommen. Email: m.stahl@moba.de Danke im vorraus. Dear Stefan could you share your code. I have also some problems with the i2c-routines. email: m.stahl@moba.de Best regards
Hi Michael, I sent it. With german remarks ;-). Check your account. Stefan
hello, i'm working with xc167 an also had many problems with i2c. is it possible to share your code an send it to me? thanks a lot. e-mail: mo@mimot.de michael
Hi Michael, done.
Hi Stefan, although this thread is over 18 months old now, today I experienced exactly the same problems while implementing a serial eeprom driver. So, may I humbly ask you for your routines too? Thank you very much in advance. My email is uwe.roth@web.de Uwe
Hi Uwe, the routines are based on the hardware implemented I2C module of XC16x devices. So I am not sure, whether they would be usefull to you. If you want them still, however, I see no problem to mail them to you. Let me know Stefan
Yes, of course. I'm using (i.e. I'm trying to use) the IIC of a XC161CJ (in polling mode). Using the Pins of P9 with a software emulated I2C Bus would be an alternative, but I'd like to avoid this. Uwe
Hi Uwe, sorry for delay, I will mail it in some minutes. Good luck, Stefan
You may also find this useful: http://www.keil.com/download/docs/xc16x_i2c_ex.zip.asp
Hi Matthias, yes you are right. I will provide this link next time again too. Unfortunately I discovered this nice XC167 example, just few a days before. Thanks, for remember this, Stefan
Hi Stefan, could you please send me your sources too. I'm working on a project with the C161pi and looking for suggestions how to handle i2c communication. German comments are very welcome. Please send it to bazoon@arcor.de Thank you very much.
Hi Martin, I sent it. Stefan
Hello, I was just casually reading this thread because I have recently been writing some interrupt driven functions for the System management bus(similiar to I2C). I see requests for routines which "work" but no discussion of the root problem (in the hardware module?). Why does an extra read operation fix things up?
Hello Barry, Why does an extra read operation fix things up? This is a good question and I agree that it would be indeed more helpfull to know the root problem, but I do not know about any problems in the HW-modul as far as concerning XC166 family. As I found the DAvE bugs and that we need some times a dummy read I contacted the Infineon guys for this stuff. They gave me the low level driver and told me.... ( sorry for some mistakes in following translation )
" ...that an extra read is not so unusual, if one is looking to the I2C protocoll. One will see that only the master suplies the bus with a clock signal. If one is setting the slave into the read mode, this does not mean that at same moment valid datas are in the receive buffer. It (the slave) can only write datas onto the bus, if it get a clock from the master. That is why we need the dummy-read, to read after that the first valid data from the buffer." ....
Hello Stefan, Thanks for your informative post. Again I've just been working with SMB and don't know I2C at all but I've read they're quite similiar. At first I was confused by the 28 different sources for the interrupt vector but after sorting things out two things were apparent. The fardware modules have a state machine which manages the idle-address-data transfer-idle changes and that the ACK/NACK at the end of each transfer drove the interrupt requests. The most time critical part of the code was during a master read of a slave. You're right the master generates the clock and the slave hardware module shifts out whatever happens to be in the buffer at the time, so the slave had to have data ready in the buffer when the shifting starts! I rolled my own handler which uses dynamically sized packets, a dedicated isr packet buffer, and input and output circular buffers with interrupt protected read and write functions. NACK response includes a retry scheme with timeout error handler, this tolerates delay due to interrupt activity in the receiver module. It's set up for a multimaster connection and I'm still working on the arbitration scheme. Cheers, Barry
Hallo Stefan, I have also big trouble with the i2c-module on the xc161. It will help me a lot if you send me your i2c routines. Thank you very much. Ralf e-mail: winkelmann@eus.de
View all questions in Keil forum