• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 642 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.

AM5748: U-Boot early activate I2C2

Christian Leeb
Expert 1690 points
Part Number: AM5748
Other Parts Discussed in Thread: AM5728

Hi,

I'm using I2C3 in U-boot.

I2C1 to which PMIC is connected is working fine.

In U-Boot 2018.1 I was able to access devices on I2C3 by enabling the clock in the arch/arm/mach-omap2/omap5hw_data.c, by adding the bold line (as suggested by TI)

...

void enable_basic_clocks(void)
{
...

u32 const clk_modules_explicit_en_essential[] = {
...

(*prcm)->cm_l4per_i2c1_clkctrl,
(*prcm)->cm_l4per_i2c3_clkctrl,
#ifdef CONFIG_DRIVER_TI_CPSW
(*prcm)->cm_gmac_gmac_clkctrl,

I was able to access a chip on I2C3

i2c dev 2
Setting bus to 2

i2c mw 0x70 1.0 1

Now I migrated to U-Boot 2020.1 and I'm getting 

i2c mw 0x70 1.0 1
i2c_write: error waiting for data ACK (status=0x116)
Error writing the chip: -121

It seems that the related device tree entry

&i2c3 {
status = "okay";
u-boot,dm-spl;
clock-frequency = <400000>;

is correctly read:

i2c speed
Current bus speed=400000

Any clue what else I need to get I2C3 working?

BR, Chris

  • 0
    TI__Guru**** 162770 points

    Hi Christian,

    Can you make sure that pin muxing is done right on 2020.01? Are you not using the 6.03 SDK & using the latest mainline u-boot?

    I am using SDK 6.3 on beagle-x15 aka am5728 which has i2c3 enabled by default.

    => i2c bus
    Bus 0:  i2c@48070000  (active 0)
       58: tps659038@58, offset len 1, flags 0
    Bus 2:  i2c@48060000
    => i2c dev 2
    Setting bus to 2
    => i2c probe
    Valid chip addresses: 57 6F
    => i2c md 6f 0x0
    0000: 00 00 00 01 01 01 01 80 00 00 00 00 00 01 01 01    ................
    =>
    0010: 01 00 00 00 01 01 01 01 00 00 00 00 00 00 00 00    ................
    =>
    0020: 04 60 0c 40 90 64 83 90 3d 03 96 44 08 80 32 00    .`.@.d..=..D..2.

    I am able to read like above and write as below:

    => i2c mw 6f 0x0 0x1
    => i2c md 6f 0x0    
    0000: 01 00 00 01 01 01 01 80 00 00 00 00 00 01 01 01    ................

    Best Regards,
    Keerthy

  • 0 in reply to Keerthy J
    Expert 1690 points

    Hi

    I'm using same pinmux file as in 2018.1.

    Seems that all other pins are working.

    I double checked I2C3 clock and data and it's correctly set:

    {GPIO6_15, (M9 | PIN_INPUT)},        /* gpio6_15.i2c3_scl */

    => md 0x4A00368C 1

    4a00368c: 00050009                               ....

     

    {MCASP1_ACLKX, (M10 | PIN_INPUT)},        /* mcasp1_aclkx.i2c3_sda */

    => md 0x4A0036A4 1

    4a0036a4: 0005000a                               ....

    I also also tried migration 2018.1 to 2019.1 (as part of SDK6.3). Same issue.

    BR, Chris

  • 0 in reply to Christian Leeb
    TI__Guru**** 162770 points

    Hi Chris,

    What is the output of i2c probe for that instance? Can you paste that?

    Best Regards,
    Keerthy

  • 0 in reply to Keerthy J
    Expert 1690 points

    Hi Keerthy,

    We have a very strange behaviour:

    On working U-Boot 2018.1 we issue "i2c mw 0x70 1.0 1" and see the expected: 

    If we do the same with U-Boot 2019.1 we see this:

    The slave, a PCA9546 I2C mux responds with a NACK (the second "1" signal). 

    We have no idea why this happens on U-Boot 2019.1. We also do not see any jabber before this first transaction on this bus.

    Best regards, Chris

  • 0 in reply to Christian Leeb
    Expert 1690 points

    Found the issue. But somewhere else:

    Some gpio reset pin was not set: 

    The problem was that in 2018.1 I wrote “gpio@4805900016” and in 2019.1, “gpio@48059000_16” is required.

    BR, Chris