Part Number: AM5728
Tool/software: TI-RTOS
Hi,
this is the follow up question to the problem mentioned in the link below
we were able to address the problem by doing the code download from the ARM(linux) because it was very consistently taking around 4 sec for doing the same download but the DSP still has to communicate with the same slave device using I2C read,write which can't be done from ARM. This was achieved by the ARM side first doing the code download and sending a message to the DSP notifying the same. Upon receiving the this message, we pinmux the I2C bus from the DSP(given below) and carryout some periodic I2C transactions by pinmuxing the bus opening the bus performing read/write and closing the bus on each transaction. (Note: The ARM doesn't do any transactions after this to avoid conflict over the bus)
(PINMUX from DSP)
regVal = 0x60002;
((CSL_padRegsOvly)CSL_MPU_CORE_PAD_IO_REGISTERS_REGS)->PAD_GPIO6_10 = regVal;
regVal = 0x60002;
((CSL_padRegsOvly)CSL_MPU_CORE_PAD_IO_REGISTERS_REGS)->PAD_GPIO6_11 = regVal;
CSL_l4per_cm_core_componentRegs *l4PerCmReg =
(CSL_l4per_cm_core_componentRegs *) CSL_MPU_L4PER_CM_CORE_REGS;
CSL_FINST(l4PerCmReg->CM_L4PER_I2C3_CLKCTRL_REG,
L4PER_CM_CORE_COMPONENT_CM_L4PER_I2C3_CLKCTRL_REG_MODULEMODE, ENABLE);
while(CSL_L4PER_CM_CORE_COMPONENT_CM_L4PER_I2C3_CLKCTRL_REG_IDLEST_FUNC !=
CSL_FEXT(l4PerCmReg->CM_L4PER_I2C3_CLKCTRL_REG,
L4PER_CM_CORE_COMPONENT_CM_L4PER_I2C3_CLKCTRL_REG_IDLEST));
It is observed that the I2C read and writes are not consistent. We saw that 10 out of 100 write resulted in it failing almost 10-20 times with I2C_STS_ERR_TIMEOUT and the read are even worse with almost 10-30 read fails with I2C_STS_ERR_TIMEOUT.
We then tried to debug it by doing the some read transactions and capturing it using a logic analyzer to see what was going wrong and following was observed,
- Code download from DSP and read from DSP it was seen that the delay between the write and read frame varies from 50-600 us. No fails seen out of 1000 reads.
- Code download from ARM and read from ARM it was seen that the delay between the write and read frame is around 40-60 us every time. No fails seen out of 1000 reads.
- Code download from ARM and read from DSP it was seen that the delay between the write and read frame varies from 5-600 us, at times whenever read took <20us we saw that the read failed with the clock stretching untill timeout.
we noticed a peculiar observation from the captures, was that there is no clock stretching just after the address read block from ARM but it does stretch every time from DSP.
Conclusion
- If we were to perform the read from the same core where the code download happened the read never failed.
- When the i2c peripheral is shared i.e., we were to perform the read from the DSP core and the code download form ARM read becomes inconsistent and fails.
ideally the code download and read/write transactions should happen in the DSP but as mentioned in the link above we are not able to do it because the timing is inconsistent taken to download from DSP and hence download was moved to ARM and read write transactions done from DSP because it required do so.
I2c driver configurations from DSP ad follows,
bus_no = 2;
i2c_cfg.enableIntr = true;
I2C_socGetInitCfg(bus_no, &i2c_cfg);
I2C_socSetInitCfg(bus_no, &i2c_cfg);
/*
* AM5 DSP does not have a default Xbar connection for I2C
* interrupt, need the following Xbar interrupt configuration
*/
/* Use reserved DSP1_IRQ_86 for I2C bus 5 */
CSL_xbarDspIrqConfigure(DSP_INSTANCE, CSL_XBAR_INST_DSP1_IRQ_86, CSL_XBAR_I2C5_IRQ);
/* Use reserved DSP1_IRQ_87 for I2C bus 3 */
CSL_xbarDspIrqConfigure(DSP_INSTANCE, CSL_XBAR_INST_DSP1_IRQ_87, CSL_XBAR_I2C3_IRQ);
I2C_init();
I2C_Params_init(&i2cParams);
i2cParams.bitRate = I2C_400kHz;
i2c_bus_handle_st[bus_no].i2c_handle = I2C_open(bus_no, &i2cParams);
we are using ti provided I2C_Transfer to read/write from DSP and ioctl for I2C transfer from ARM.
bios version: 6_52_00_12
pdk ver: pdk_am57xx_1_0_7
IPC version: 3_47_00_00
Thanks
Ranganath
