• State
  • Locked Locked
  • Replies 21 replies
  • Subscribers 99 subscribers
  • Views 4233 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM437x I2C2 not working

g.f.
Guru 15520 points

Hi,

I'm having problem with AM437x I2C2.

On the customer board, RTC device is connected to AM437x via I2C2.

When I tried read access to RTC device register, it failed.

But when connecting via I2C0, it can access successfully.

After sending Start condition -> RTC slave address + Read,

AM437x detects NACK , the SCL/SDA goes High without Stop Condition .

I checked the I2C2 signal(SCL/SDA), the ACK was issued from RTC device.

I guess the connection is fine between AM437x and RTC device because RTC device are issuing ACK.

So, I don't know why AM437x detect NACK.

I'm using LINUXEZSDK-AM437X and modified the u-boot code to use L22/K22 pin as I2C2.

But when accessing to RTC device by omap24_i2c_read() defined in "omap24xx_i2c.c the following error occured:

***************************************************

i2c_read: error waiting for addr ACK (status=0x116)

***************************************************

What can be consider for this problem? Am I missing some configuration of I2C2?

best regards,

g.f.

  • 0
    TI__Guru**** 393215 points

    Hi g.f,

    Please provide more details: where does this happen - u-boot or kernel? Which SDK are you using? Please post logs.

  • 0 in reply to Biser Gatchev-XID
    Guru 15520 points
    Hi Biser,
    Thank you for the reply and I'm sorry about the details.
    This problem is occuring at my customer.
    It' happening at u-boot, and they are using Linux SDK v07.01.00.00.

    I will ask my customer for the logs, so please wait.

    best regards,
    g.f.
  • 0 in reply to g.f.
    TI__Guru**** 393215 points

    OK, but meanwhile you can ask them to try with the latest SDK 8.0.

  • 0 in reply to Biser Gatchev-XID
    Guru 15520 points
    Ok, I will suggest them to try with SDK 8.0.

    best regards,
    g.f.
  • 0 in reply to g.f.
    Guru 15520 points

    Hi Biser,

    I will post the log. Please take a look.

    best regards,

    g.f.

    Fullscreen i2c_errlog.txt Download 
    U-Boot SPL 0.2.2013.10-00189-g78d8ebd-dirty (Apr 08 2015 - 13:54:23)
SPL: Please implement spl_start_uboot() for your board
SPL: Direct Linux boot not active!
reading u-boot_ehv_sd.img
reading u-boot_ehv_sd.img


U-Boot 0.2.2013.10-00189-g78d8ebd-dirty (Apr 08 2015 - 13:54:23)

I2C:   ready
[gpmc_init]
[ope_history_save] err_code:8010 detail_code:0000 err_cnt:0
[rtc_gettime]
Could not probe the RTC at 0x51
[pmic_init]
[tps65218_init]
TPS65218[0x03]:0x3f
TPS65218[0x04]:0x3f
TPS65218[0x11]:0x0f
TPS65218[0x12]:0x13
TPS65218[0x14]:0x40
TPS65218[0x17]:0xb0
TPS65218[0x18]:0x92
[gpio_init] start.
[gpio_init] bd:bfb44fc0
[gpio_init] end.
[fpga_init]
[fpga_init] SD-card boot
[fpga_init] WDT Disable
[wdt_disable]
[ledctl_7seg] mode:01 err_code:00
- SDRAM diagnosis skipped.
DRAM:  1 GiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB, mapped at 30000000
*** Warning - bad CRC, using default environment

SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB, mapped at 30000000
Checking Inventory...[check_inventory] lan1mac  ff:ff:ff:ff:ff:ff
[check_inventory] lan2mac  ff:ff:ff:ff:ff:ff
[check_inventory] lan3mac  ff:ff:ff:ff:ff:ff
[check_inventory] crc  ffffffff
CRC NG!!
Use default MAC Address.
Net:   [board_eth_init]
cpsw
Hit space key to stop autoboot:  0
EHV # i2c dev 2
Setting bus to 2
EHV # i2c probe 0x51
Valid chip addresses:
EHV # i2c read 0x51 0 1 0x80200000
i2c_read: error waiting for addr ACK (status=0x116)
Error reading the chip.
EHV #

  • 0 in reply to g.f.
    TI__Guru**** 161600 points

    Hi,

    What is the output of

     U-Boot# i2c bus 

     U-Boot# i2c probe

    commands in u-boot?

    Best Regards,

    Yordan

  • 0 in reply to Yordan Kovachev
    Guru 15520 points
    Hi Yordan,

    Thank you for the reply.

    It seems there are no "i2c bus" command in u-boot.
    Is it "i2c dev" command ?

    Do you want to know the valid chip address for I2C2
    by following command?

    U-Boot#i2c dev 2

    U-Boot#i2c probe


    best regards,
    g.f.
  • 0 in reply to g.f.
    TI__Guru**** 161600 points

    Hi,

    Sorry for the delayed response, I was OoO.

    Actually on my setup (AM335x Starter Kit with SDK8.0) there is an i2c bus command:

    U-Boot# i2c                                                                                                                                      

    i2c - I2C sub-system                                                                                                                              

    Usage:                                                                                                                                            

    i2c bus [muxtype:muxaddr:muxchannel] - show I2C bus info                                                                                          

    crc32 chip address[.0, .1, .2] count - compute CRC32 checksum                                                                                    

    i2c dev [dev] - show or set current I2C bus                                                                                                      

    i2c loop chip address[.0, .1, .2] [# of objects] - looping read of device                                                                        

    i2c md chip address[.0, .1, .2] [# of objects] - read from I2C device                                                                            

    i2c mm chip address[.0, .1, .2] - write to I2C device (auto-incrementing)                                                                        

    i2c mw chip address[.0, .1, .2] value [count] - write to I2C device (fill)                                                                        

    i2c nm chip address[.0, .1, .2] - write to I2C device (constant address)                                                                          

    i2c probe [address] - test for and show device(s) on the I2C bus                                                                                  

    i2c read chip address[.0, .1, .2] length memaddress - read to memory                                                                              

    i2c write memaddress chip address[.0, .1, .2] length - write memory to i2c                                                                        

    i2c reset - re-init the I2C Controller                                                                                                            

    i2c speed [speed] - show or set I2C bus speed                                                                                                    

    And the result of U-Boot# i2c bus is:

    U-Boot# i2c bus                                                                                                                                  

    Bus 0:  omap24_0                                                                                                                                  

    Bus 1:  omap24_1                                                                                                                                  

    Bus 2:  omap24_2

    Shows available i2c buses configured in my board.

    Best Regards,

    Yordan

  • 0 in reply to Yordan Kovachev
    Guru 15520 points

    Hi Yordan,

    Thank you for the reply. 
     
    Our device is AM437x not AM335x, so I'm using Linux SDK v7 for AM437x.
    And the board is customer board not AM437x EVM.
    In Linux SDK, "i2c bus" isn't supported as far as I know.

    What should I check ?
    And I need an information for AM437x?

    best regards,
    g.f.

  • 0 in reply to g.f.
    Guru 15520 points
    Hi Yordan,

    It passed 10 days from the last post, and the problem remains.
    Can you please help with this AM437x I2C2 problem.

    best regards,
    g.f.
  • 0 in reply to g.f.
    TI__Guru**** 161600 points
    Hi,
    Sorry for the delayed response. I was OoO.

    I don't have AM437x evm at my disposal. So I checked this on my am335x evmsk with SDK7 u-boot (), and i2c bus command is not present.
    Looking at the i2c_core.c & omap24xx_i2c.c driver, this could be a problem with the i2c2 mux settings, typically this happens if pulls are not enabled.
    Can you check if pulls are enabled (PULLUDEN) on i2c2_scl & i2c2_sda pins (in board/ti/am335x/mux.c?

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Guru 15520 points
    Hi Yordan,

    Thank you for the reply.

    Yes, pulls are enabled.
    The customer dumped the value of CTRL_CONF_UART1_CTSN(mux setting for I2C2_SDA)
    and CTRL_CONF_UART1_RTSN(mux setting for I2C2_SCL).

    The value of these registers was as following:
    ///////////////////////////////////////
    CTRL_CONF_UART1_CTSN = 0x000E_0003 (I2C2_SDA is selected and PullUp is enabled)

    CTRL_CONF_UART1_RTSN = 0x000E_0003 (I2C2_SCL is selected and PullUp is enabled)
    ///////////////////////////////////////

    best regards,
    g.f.
  • 0 in reply to g.f.
    TI__Guru**** 161600 points

    Hi,

    Values 0x000E_0003 for CTRL_CONF_UART1_CTSN & CTRL_CONF_UART1_RTSN mean:

     bit4 = 0 -> pulldown selected

     bit5 = 0 -> receiver disabled

    When you configure the pad as I2C you need to set these device pads as I/O (so input enable bit, bit5, should be set).I think this may be the cause for your NACK.

    Also you need to enable the pullups for the pad, not the pull downs.  In some cases (with my experience with ti devices), when you use external pullup, you may need to disable the internal weak pullup.

    So as a first step, focus on enabling the INPUTENABLE bits - CTRL_CONF_UART1_CTSN[5]conf_<module>_<pin>_rx_active = 1 & CTRL_CONF_UART1_RTSN[5]conf_<module>_<pin>_rx_active = 1   AND select the internal PULLUP (not pulldown as you do now) - CTRL_CONF_UART1_CTSN[4]conf_<module>_<pin>_putypeselect = 1 & CTRL_CONF_UART1_RTSN[4]conf_<module>_<pin>_putypeselect = 1

    Best Regards,

    Yordan

  • 0 in reply to Yordan Kovachev
    Guru 15520 points
    Hi Yordan,

    Thank you for the reply and I'm sorry for the delay.
    I was out of office last week.

    Are you looking at AM335x Technical Reference Manual?

    In "AM437x" Technical Reference Manual, bit4 and bit5 are reserved bit.
    Values 0x000E_0003 for CTRL_CONF_UART1_CTSN & CTRL_CONF_UART1_RTSN mean:
    bit17 => Pullup Selected
    bit18 => receiver enabled

    So, PAD setups have been done as you mentioned at your last post.

    Should they try disabling internal pullup which you mentioned?

    best regards,
    g.f.
  • 0 in reply to g.f.
    TI__Guru**** 161600 points

    Hi,

    g.f. said:
    Are you looking at AM335x Technical Reference Manual?

     

    Yes, I've looked at the AM335x TRM.  Sorry for the mistake. You are right, your pads are set correctly. 

    Can you try changing the CONF_UART1_CTSN_SLEW_CTRL? 

    g.f. said:
    Should they try disabling internal pullup which you mentioned?

     

    As I said this was valid for other ti devices (omap4). Not sure if it will solve this issue. 

    Can you try defining 

    #define CONFIG_SYS_OMAP24_I2C_SLAVE1  1 

    #define CONFIG_SYS_OMAP24_I2C_SLAVE2  1 

    in include/configs/ti_armv7_common.h ? 

    Also is it possible to provide the settings of I2C_SYSC & I2C_CON registers? 

    Best Regards, 

    Yordan

  • 0 in reply to Yordan Kovachev
    Guru 15520 points
    Hi Yordan,

    Thank you for the reply.
    I'm asking to my customer now. Please wait for a while.

    best regards,
    g.f.
  • 0 in reply to Yordan Kovachev
    Guru 15520 points
    Hi Yordan,

    I'm sorry for the delay.

    The customer tried changing the CONF_UART1_CTSN_SLEW_CTRL to "0(fast)",
    but the problem still occuring.

    Also they defined the following to the "include/configs/ti_armv7_common.h" of u-boot:
    #define CONFIG_SYS_OMAP24_I2C_SLAVE1 1
    #define CONFIG_SYS_OMAP24_I2C_SLAVE2 1

    but there was no effect at all.
    By the way, what this defining for? What kind of effect does this defining give?
    The customer search those macros in the u-boot source code, but there was no such macros.

    And the registers of I2C(I2C_SYSC & I2C_CON)value was as follows:
    ////////////////////////////////////
    I2C_SYSC = 0x00000001
    I2C_CON = 0x00008200
    ////////////////////////////////////

    best regards,
    g.f.
  • 0 in reply to g.f.
    TI__Guru**** 161600 points

    Hi,

    The defines explicitly enable the I2C slave channels (1 & 2).

    Your I2C configuration seems correct.... I am not sure why you are not able to communicate through I2C2.

    In your first post you say that this works with I2C0. Do you use the same CONFIG_SYS_OMAP24_I2C_SPEED for both I2C0 and I2C2 in the i2c_init() function in board/ti/am43xx/board.c file? 

    Do you have any other devices connected to I2C2? If yes, then your problem could be caused of some race condition or conflict on the bus.

    Best Regards, 

    Yordan

  • 0 in reply to Yordan Kovachev
    Guru 15520 points
    Hi,

    I'm sorry for the delay.

    I'm asking to my customer about the CONFIG_SYS_OMAP24_I2C_SPEED, so please wait.
    By the way, they are not connecting other devices to I2C2.

    best regards,
    g.f.
  • 0 in reply to Yordan Kovachev
    Guru 15520 points
    Hi Yordan,

    The customer used the same "CONFIG_SYS_I2C_SPEED" (not CONFIG_SYS_OMAP24_I2C_SPEED) for I2C0 and I2C2.

    CONFIG_SYS_I2C_SPEED is defined as follows:
    ////////////////////////////////////
    #define CONFIG_SYS_I2C_SPEED 100000
    ////////////////////////////////////

    best regards,
    g.f.
  • 0
    Intellectual 420 points
    Hi,

    Just searched the forum and found your post as I am having the same issue. I know it's been six months and I am wondered whether you or your customer has managed to resolve it.

    Thanks