TI E2E Community
Digital Signal Processors (DSP)
OMAP-L13x, AM1x and C674x Processors Forum
OMAP L138 Switch/LED Control
I'm not sure what happened to my previous post (got lost in the TI Forum "Upgrade"), but somebody out there in the community wanted my sample code to read the S2 switch and write the User LEDs from the ARM side. This post is to let everyone know that I've put a file in my profile called i2c_app.tar.gz. This file contains that sample application. If you have questions, just post them back to the forum.
I can succesfully run your code when the program is compiled with Code Sourcery and TI_DVSDK_4_02 is used.
However, now I use TI_DVSDK_4_03 and when I compile the program and try to run, it gives some errors:
Initializing I2C Port...
IOCTL Failed at addressI2C Read Failed!Switch = ff
I checked the kernel config parameters in TI_DVSDK_4_03 and everything looks fine. Could you help me with this?
Jeez, talk about a "blast from the past"! I'd all but forgotten about that app. Consider yourself lucky I'm still around! I have never used the TI_DVSDK_xxxx proper, I use TimeSys for my OMAP-L138 Distribution (and love them!). However, if I had to guess as to what the problem is, it is most-likely that sometime after I wrote that app, the I2C port was switched from an I2C device to a bit-banged I2C implementation. I think that coincided with a change from a 2.6.32-rc6 to a 2.6.33 Kernel rev. I would imagine that my app somehow depends upon it being an I2C device, and that is the cause of the problem. Personally, I did not need/like the bit-banged I2C, so I fumbled my way through a patch to revert to I2C device in the 2.6.33 Kernel. You might want to check your kernel .config. It is likely that with the 4_02 CONFIG_I2C_GPIO is "not set" but in 4_03, it is "y", and vice-versa for CONFIG_I2C_DAVINCI. I think that is likely the cause of the problem.
The program fails at
if (ioctl(i2c_file, I2C_SLAVE, dev_addr) < 0) statement
if I change I2C_SLAVE to I2C_SLAVE_FORCE then the program runs.
Sorry I'm not able to help you more. I don't have either SDK, so can't do a direct comparison for you. However, looking at the Kernel source, the define of I2C_SLAVE_FORCE indicates that it should be used to "/* Use this slave address, even if it is already in use by a driver! */". I infer from that that the new SDK assigns a driver to the IO Expander module. Would that be somewhere in the RootFS configuration? Not sure. Did you ever check the I2C settings of "device" vs. "bit-bang"? What (if anything) did that tell you? You might also try to modify the app to not perform switch reads (temporarily) and instead just control the LEDs to see if you have ANY control over the I2C bus or not. Like I said, sorry, but it has been 4+ years since I posted that app and have long-since forgotten about the details. Best of luck!
OK. For now, the problem is solved. Thanks for helping me.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.