search

karo-electronics / karo-tx-uboot

U-Boot for TXCOM modules
GNU General Public License v2.0
6 stars 5 forks source link

I2C1 with non-default PADs setup does not work until command line #5

Closed fernandez85 closed 5 years ago

fernandez85 commented 5 years ago

Hello community :)

I have a really big problem with I2C. I'm developing a product which uses Karo TX6S-8135 chip and using latest sources that are placed here on Github (master branch - to be precise, this is my dev starting point CLICK ). I have request to do a U-Boot modification. I need to detect at U-Boot init time if button was pressed (it's non-stadard keypad), which is controlled by I2C1. The problem here is our product uses different pins (_CSI0DAT9, _CSI0DAT8) than default ones (_EIMD21, _EIMD28). The defaults are used for internal I2C to control PMIC, but chip specification shows that I2C1 module can work with pin numbers 161 and 162, which are mentioned _CSI0DAT8 and _CSI0DAT9 pins. This is also mentioned here in Karo datasheet: TX6S-Datasheet.pdf (pages 11-12)

First I wanted to check if I have any connection with the slave module that controls my keypad (TCA9539 in my case). Here is what happens. When I2C Probe is executed while initializing it fails - currently i use _board_lateinit, but goal is to do it earlier. When I execute i2c probe after initialization, at U-Boot command line state, then it's OK and whole communication is working correctly. I tried different approaches, but nothing helps here. All this situation can be seen in this logfile: tx6s_log.txt

Here are necessary changes (trimmed to minimum) to reproduce problem: git_diff.txt

Unfortunately, I don't have any circuit diagram of the device. It was supposed to be easy change, and all necessary info was provided to achieve this. Now I'm stuck at this point and can't go through. I don;t understand why i2c probe works from console and not while initializing. I can also add that reset command (CPU reset) makes that my code works as expected, but that is just a different state. I appreciate any help with this topic as I'm out of ideas now :(

hsdenx commented 5 years ago

Hello fernandez85,

very strange ... no real idea, without the posibility to dig on the hardware. May its time to use an oscilloscope...

Hmm.. may you try to set the pins EIM_D21, EIM_D28 to gpio function?

bye, Heiko

fernandez85 commented 5 years ago

Hello,

yes very strange, and I'm struggling with this for a long time. Already tried to set GPIO mode to EIM_D21 and EIM_D28 - no success :( As for the oscilloscope , I don't have such device on my side, but I asked a developer who is responsible for this project and he did a bunch of measurements for me. All these where done on SDA line of the I2C module. This was done when slave module wasn't connected. image From what I was informed same measurement was achieved while U-Boot init and while in U-Boot command-line. Situation is little different when slave controller is connected to SDA,SCL lines. This is from U-Boot init time: image And this from U-Boot command-line: image This doesn't say anything to me, as I'm not a specialist in this area. I'm only seeing that the graph is different a little. But I don't know if this fits measurement error margin or if not what does it mean?

Kind regards, Piotr K (fernandez85)

fernandez85 commented 5 years ago

Hello, With help of guys from KaRo support crew I've found he solution here. Long story short. All I needed is to set up PAD for Reset-Pin of the controller that I wanted to use. The reason why it worked in command-line was that this pin was actually set when PADs for Starterkit Eval board were setup, but at that moment I didn't know that one of those PADs was my Reset-Pin ;) So the problem is solved here. Cheers, Piotr K (fernandez85)