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.

How to make I2C_Write triggers interrupt correctly when using DM388 as I2C slave

Other Parts Discussed in Thread: DM388

Hi,

We are building an I2C command channel between DM388 and a FPGA over I2C2, with the FPGA in the master role and DM388 as the slave. Our project uses IPNC 3.8 as the reference code base.

The issue we currently encountered is that although we can see the proper signal going over the I2C2_SDA wire, the expected interrupt never got triggered when the master issued an I2C_WRITE.

The following is a summary of what we have done so far to enable DM388 as I2C slave:

1. in psp_i2cdrv.c, we configured I2C2 with the parameters .isMasterMode = FALSE, .i2cOwnAddr = 0x20, and .opMode = I2C_OPMODE_INTERRUPT (the overlay I2C2 registers of I2C_CON and I2C_OA have been checked to make sure that appropriate values are set in those registers)

2. we reviewed soc_TI814x.h and found that CSL_INTC_EVENTID_I2CINT2 is set to 42u

    we enabled the code in iss_platformTI814x.c so the following is called to route the IRQ properly,

    int_mux = REG32(CSL_TI814x_CTRL_MODULE_BASE + 0x0f64);
    /* I2CINT2 value = 4, INT_MUX_19_SHIFT = 24 */
    int_mux |= (4 << 24);
    REG32(CSL_TI814x_CTRL_MODULE_BASE + 0x0f64) = int_mux;

3. we placed a debug statement on top of i2c_isr() in psp_i2cdrv.c, so we may be alerted when I2C_WRITE triggers the interrupt

But the I2C_WRITE never triggers the Vps_printf in i2c_isr(). What else must be done to enable I2C_WRITE triggering the interrupt? 

Thanks!

  • Hello,

    user4165218 said:
    Our project uses IPNC 3.8 as the reference code base.

    I am not familiar with IPNC RDK, but I will try to provide you some hints from I2C module side. Make sure you are using the latest version of the linux kernel:

    user4165218 said:
    The issue we currently encountered is that although we can see the proper signal going over the I2C2_SDA wire, the expected interrupt never got triggered when the master issued an I2C_WRITE.

    What about the I2C2_SCL wire, do you see proper signal going on this wire?

     

    user4165218 said:
    What else must be done to enable I2C_WRITE triggering the interrupt? 

    I would recommend you to verify first that everything regarding the I2C transfer is fine, in polling mode. See TRM, sections 15.2.13.2 FIFO Polling Mode Operation
    and 15.2.14.5 Receive Data


    If polling mode is fine, check if you enabled to interrupt events from I2C_IRQENABLE_SET register, and then check the status of I2C_IRQSTATUS register instead using printf function in the ISR.

    P.S. I will move this thread to the correct e2e forum (DM814x).


    Regards,
    Pavel

  • Hi Pavel,

    Thanks for the help.

    We checked the signals over SDA and SCL wires, and they both look okay to us. As a matter of fact, when we configured I2C2 as master, we were able to call Iss_deviceRead16() without any problem. That's why we were concentrated on the issue of interrupt event.

    In psp_i2cdrv.c, the original code in PSP_i2cCreate() from RDK reads,
    reg_val = I2C_IE_XRDY | I2C_IE_RRDY | I2C_IE_ARDY |
    I2C_IE_NACK | I2C_IE_AL;
    I2C_WRITE_REG_WORD(reg_val, &instObj->i2cRegs->I2C_IRQENABLE_SET);

    reg_val = ~(I2C_IE_XRDY | I2C_IE_RRDY | I2C_IE_ARDY |
    I2C_IE_NACK | I2C_IE_AL);
    I2C_WRITE_REG_WORD(reg_val, &instObj->i2cRegs->I2C_IRQENABLE_CLR);
    So we assume the proper interrupt events have been set and ready to receive interrupts.

    We will scan through the shortlog and look into polling mode. Will also check I2C_IRQSTATUS instead of using printf in the future. Although I wonder where would be a good place to check I2C_IRQSTATUS if i2c_isr() never got called (as indicated by the lack of printf on top of i2c_isr() in the log), any recommendation?

    Regards,
    Henry
  • Henry,

    user4165218 said:
    n psp_i2cdrv.c, the original code in PSP_i2cCreate() from RDK reads,
    reg_val = I2C_IE_XRDY | I2C_IE_RRDY | I2C_IE_ARDY |
    I2C_IE_NACK | I2C_IE_AL;
    I2C_WRITE_REG_WORD(reg_val, &instObj->i2cRegs->I2C_IRQENABLE_SET);

    reg_val = ~(I2C_IE_XRDY | I2C_IE_RRDY | I2C_IE_ARDY |
    I2C_IE_NACK | I2C_IE_AL);
    I2C_WRITE_REG_WORD(reg_val, &instObj->i2cRegs->I2C_IRQENABLE_CLR);
    So we assume the proper interrupt events have been set and ready to receive interrupts.

    I would recommend you to enable more interrupts in the I2C_IRQENABLE_SET register (bits 5,6,7,8,9,11,13), thus you will detect everything that might occur.

    user4165218 said:
    Although I wonder where would be a good place to check I2C_IRQSTATUS if i2c_isr() never got called (as indicated by the lack of printf on top of i2c_isr() in the log), any recommendation?

    Put the I2C_IRQSTATUS check right after you start that receive data transfer. See TRM, section 15.2.14 How to Program I2C

    1. Module Configuration Before Enabling the Module
    2. Initialization Procedure - Enable interrupt masks (I2C_IRQENABLE_SET), if using interrupt for transmit/receive data
    3. Initiate a Transfer
    4. Receive Data - check I2C_IRQSTATUS

    Regards,
    Pavel

  • Hi Pavel,

    Thanks for the suggestion. I will give it a try and see if it works out.

    Best regards,
    Henry
  • Hi Pavel,

    Thanks for your suggestion.

    Enabling more interrupts allow us to identify the minor issues with the incoming I2C signal from the master device, and we were able to tweak the signal and get the data from I2C_WRITE though.

    The instructions on TRM that you mentioned offered general guidance, which are very useful but seem sparse in the specifics that could be directly applied to our problem. 

    I did find another TI technical document DM643x I2C User's Guide that offers more specific instructions on the configuration of DSP both as I2C master and slave device, it is particularly more helpful in solving the issues we faced. Many details on I2C registers are different from DM388 and need to be thought through, but it does provide a great checklist in setting up a DSP as a I2C slave.

    Thanks for the help.

    Regards,
    Henry