a) Hi,
w a) We have imx6sl custom board where PMIC is connected on pin number G23 and G24 i.e. under PAD_KEY_COL0 (ALT1 —I2C2_SCL) and PAD_KEY_ROW0 (ALT1 —I2C2_SDA). We are trying to communicate with PMIC through u-boot i2c command to enable VGEN2 voltage , but we could not able to communicate with the PMIC, also tracked u-boot source code and found the issue which is as follows
b) b) We have imx6sl evaluation board where the PMIC is connected on pin number AC13 and AD13 i.e. under PAD_I2C1_SCL (ALT0 —I2C1_SCL) and PAD_I2C1_SDA (ALT0 —I2C1_SDA) where we are able to communicate successfully through u-boot i2c command. We could able to reproduce the above issue in evaluation board itself if we disable SION bit in pad mux register (1 ENABLED — Force input path of pad I2C1_SDA).
c)Also we have found the following information from reference manual at page number 1226
“Inputs of I2Cn_SCL and I2Cn_SDA also need to be manually enabled by setting the SION bit in the IOMUX after the corresponding PADs are selected as I2C function “
We cannot set SION bit in our custom board, since the default functionality is different (KEY_COL0), also what is the significance of forcing the PAD functionality to default with SION bit , rather selecting with MUX_MODE register and how to overcome this is issue in our custom board ? .
Thanks and Regards
Periyasamy R
Hi periyasamy
SION bit enables the forcing of an input path of the pad, it is
described in sect.30.3.2 SW Loopback through SION bit IMX6SLRM.
I2C module requires SION to be set for correct operation.
Default functionality of these pads is the same as shows
sect.30.4.83 Pad Mux Register (IOMUXC_SW_MUX_CTL_PAD_I2C1_SCL)
30.4.87 Pad Mux Register (IOMUXC_SW_MUX_CTL_PAD_KEY_COL0).
Necessary pad settings can be set with Uboot dcd header (flash_header.S).
Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Dear igor,
From your reply,
>> Sect.30.4.83 Pad Mux Register (IOMUXC_SW_MUX_CTL_PAD_I2C1_SCL)
We have to select I2C1_SCL signal for i2c operation and in the above Pad Mux register the default functionality is I2C1_SCL and if we set SION bit, it will select I2C1_SCL only.
>> 30.4.87 Pad Mux Register (IOMUXC_SW_MUX_CTL_PAD_KEY_COL0).
But in our case we have to select I2C2_SCL and in the above Pad Mux register the default functionality is KEY_COL0 and if we set SION bit, it will select KEY_COL0 only, not I2C2_SCL signal.
Hence in our case we cannot set SION bit to select I2C2_SCL and Also in the evaluation board if we disable SION bit and select I2C1_SCL through MUX_Mode register , the PMIC commination is failed (BUSY bit is always zero ) where as if we enable the SION bit, the communication is success . In short it seems the SION bit is needed for proper i2c operation.
Hence kindly explain that what is the significance of forcing the PAD functionality to default with SION bit in i2c? And how to overcome this is issue in our custom board, since we cannot use SION bit?
Thanks and Regards
Periyasamy R
Hi periyasamy
setting SION bit for pad named "KEY_COL0" will select not
only KEY_COL0 but also I2C2_SCL signal.
This is pad setting, not specific signal setting.
~igor
Dear igor,
As you suggested, I have set the SION bit, but still the behavior is same with and without setting SION bit. I hereby by described the register write sequence for the experiment .
// IOMUX settings
PAD_MUX I2C2_SCL = 0x20e016c data = 0x11 //IOMUXC_SW_MUX_CTL_PAD_KEY_COL0 forced SION bit
PAD_MUX I2C2_SDA = 0x20e018c data = 0x11 // IOMUXC_SW_MUX_CTL_PAD_KEY_ROW0 forced SION bit
PAD control SCL = 0x20e0474 data = 0x1b8b1 // Fast slew rate | Drive Strength Field 40 ohm | Speed medium 100 MHz | Open drain enabled |Pull/Keeper Enabled
// Pull enabled | 100k pull up | Hysteresis Enabled | Low voltage
PAD control SDA = 0x20e0494 data = 0x1b8b1 // same as above
// I2C initialization
ADD IADR = 0x21a4000 data = 0x0 // its Slave address = 0
ADD IFDR = 0x21a4004 data = 0x14 // Frequency Divider Register
ADD I2CR = 0x21a4008 data = 0x80 // IEN = 1, enable i2c
ADD I2SR = 0x21a400c data = 0x81 // “No acknowledge" signal was detected at the ninth clock
ADD I2DR = 0x21a4010 data = 0x0 // Data register = 0
I2C Communication
writeb(I2SR_IIF_CLEAR, &i2c_regs->i2sr) // Cleared pending interrupts in SR reg
wait_for_sr_state(i2c_regs, ST_BUS_IDLE) // Checking for ST Bus ideal State , the bus is ideal and this case passed
temp = readb(&i2c_regs->i2cr);
temp |= I2CR_MSTA;
writeb(temp, &i2c_regs->i2cr); // Setting MSTA bit in i2C_cr register to send the start signal
ret = wait_for_sr_state(i2c_regs, ST_BUS_BUSY) // Checking for the Bus Busy bit to be set , but the bit is not
We have probed the start signal in oscilloscope where we can see the start signal also. Hence advise that what could be the problem for the busy bit not set by processor?
Thanks and Regards
Periyasamy R
Hi periyasamy
I would suggest to check with bare metal test SDK
to avoid uboot/linux side effects
~igor