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.

IWR6843: I2C Slave implementation problem

Part Number: IWR6843
Other Parts Discussed in Thread: MMWAVE-SDK

Hi!

I'm trying to implement I2C slave functionality to the IWR6843 but the I2C slave driver does not transfer data.  It detects start and stop condition, and I2CSlave_read() returns successfully when I write from a master to the IWR6843 slave with correct slave address, but no data is written to the buffer by I2CSlave_read().  Any ideas what could be wrong?

Here is my code simplified:

void Mmw_I2CInit (uint8_t taskPriority) {
    Task_Params     taskParams;
    Task_Params_init(&taskParams);
    taskParams.priority  = taskPriority;
    taskParams.stackSize = 4*1024;
    gI2CTaskHandle = Task_create(I2C_slave_task, &taskParams, NULL);
    return;
}

static void I2C_slave_task(UArg arg0, UArg arg1) {
    I2CSlave_Handle      handle;
    I2CSlave_Params      params;
    uint8_t              i2c_com_buffer[2];

    I2CSlave_init();
    I2CSlave_Params_init(&params);
    params.transferMode = I2CSLAVE_MODE_BLOCKING;  // This is the only mode available
    params.slaveAddress = 0x68;
    handle = I2CSlave_open(0, &params);
    if (!handle) {
       System_printf("ERROR: I2C Slave did not open\n");
       return;
    }
    while(1) {
        bool result = I2CSlave_read(handle, i2c_com_buffer, 2);
        if (!result) {
           System_printf("Unsuccessful I2CSlave read\n");
           continue;
        }
        System_printf("Received bytes: %02x %02x\n",i2c_com_buffer[0],i2c_com_buffer[1]);
    }
}

So my code prints "received bytes ..." to the console every time I write to the I2C slave but buffer only contains initialized 0xff data, not the data I wrote.
I also found that there has to be a delay (about 0.5 seconds ... 1 seconds) between writes, otherwise there will only be one "received bytes ..." message.
I debugged the driver by inserting breakpoints in the interrupt service routine and found that there are no interrupts other than start and stop conditions.
I also enabled DebugP Log and this is what is shown by Remote Object Viewer:


3	3206565	xdc.runtime.Main	    Debug: I2C Slave Driver(@08006d30) Registering HWI ISR for Interrupt 66	0	xdc.runtime.Log_print	52280	134245680	66	0	0	0	0	0
4	3207031	xdc.runtime.Main	    Debug: I2C Slave Driver(@fff7d400) opened in BLOCKING Mode	0	xdc.runtime.Log_print	52348	-535552	0	0	0	0	0	0
5	3218627	xdc.runtime.Main	    Debug: I2C Slave Driver(@fff7d400) Starting operation(Read)	0	xdc.runtime.Log_print	73192	-535552	73184	0	0	0	0	0
6	11850207783	xdc.runtime.Main	Debug: I2C Slave Driver(@fff7d400) ISR START DETECTED	0	xdc.runtime.Log_print	27912	-535552	0	0	0	0	0	0
7	11850210767	xdc.runtime.Main	Debug: I2C Slave Driver(@fff7d400) ISR STOP DETECTED	0	xdc.runtime.Log_print	28268	-535552	0	0	0	0	0	0
8	11850211063	xdc.runtime.Main	Debug: I2C Slave Driver BLOCKING MODE - posting transfer complete semaphore. Status : 1	0	xdc.runtime.Log_print	110084	1	0	0	0	0	0	0
9	11850212060	xdc.runtime.Main	Debug: I2C Slave Driver(@fff7d400) Transfer OK	0	xdc.runtime.Log_print	73244	-535552	0	0	0	0	0	0
10	11850228067	xdc.runtime.Main	Debug: I2C Slave Driver(@fff7d400) Starting operation(Read)	0	xdc.runtime.Log_print	73192	-535552	73184	0	0	0	0	0

  • Hi Tom

    The added delays are a good idea for debugging, keep doing that.

    Which code set are you running? Is this a demo or the I2C driver test code?

    Regards,

    AG

  • The radar code is proprietary but based on mmwave demo code.  I can show some of the I2C related code from mss_main.c here:

    #define MMWDEMO_I2C_TASK_PRIORITY                 2
    #define MMWDEMO_CLI_TASK_PRIORITY                 3
    #define MMWDEMO_DPC_OBJDET_DPM_TASK_PRIORITY      4
    #define MMWDEMO_MMWAVE_CTRL_TASK_PRIORITY         5
    
    static void MmwDemo_platformInit(MmwDemo_platformCfg *config) {
        Pinmux_Set_OverrideCtrl(SOC_XWR68XX_PING14_PADAI, PINMUX_OUTEN_RETAIN_HW_CTRL, PINMUX_INPEN_RETAIN_HW_CTRL);
        Pinmux_Set_FuncSel(SOC_XWR68XX_PING14_PADAI,SOC_XWR68XX_PING14_PADAI_I2C_SCL);
        Pinmux_Set_OverrideCtrl(SOC_XWR68XX_PINF13_PADAH_I2C_SDA, PINMUX_OUTEN_RETAIN_HW_CTRL, PINMUX_INPEN_RETAIN_HW_CTRL);
        Pinmux_Set_FuncSel(SOC_XWR68XX_PINF13_PADAH,SOC_XWR68XX_PINF13_PADAH_I2C_SDA);
    }
    
    static void MmwDemo_initTask(UArg arg0, UArg arg1) {
        MmwDemo_platformInit(&gMmwMssMCB.cfg.platformCfg);
        Mmw_I2CInit(MMWDEMO_I2C_TASK_PRIORITY);
    }
    
    int main (void) {
        Task_Params_init(&taskParams);
        gMmwMssMCB.taskHandles.initTask = Task_create(MmwDemo_initTask, &taskParams, NULL);
        BIOS_start();
        return 0;
    }

    My target is to control and get results from the sensor using I2C instead of the USB COM port.  I find the I2C slave driver a bit difficult to understand.  I would expect an API where a I2CSlave_wait() would return after the slave has been addressed and it would indicate if it is a read or write access.  Based on that read or write bit I2CSlave_read() or I2CSlave_write() can be called to read/write data.  Also, I2CSlave_read() should return number of bytes written by master before stop condition.

  • Hi Tom

    I'll need more time to look into this, please allow a few days.

    Regards,

    AG

  • Hi Tom

    I'll still need more time on this, please allow a few more days.

    Regards,

    AG

  • OK. No hurry. I'm on vacation this and next week.  After that I would need to get this working.

  • Thanks Tom

    I will have an update for you before the week of 9th August. Enjoy your vacation!

    Regards,

    AG

  • Thanks!  Looking forward to a solution/explanation.  Regards, Tom

  • Hi Tom

    I haven't been able to repeat this error.

    Does this also occur when you run the I2C test code? It is in the mmWave-SDK at the following folder location:

    C:\ti\mmwave_sdk_03_05_00_04\packages\ti\drivers\i2c\test

    The corresponding doxygen is at the following location:

    C:\ti\mmwave_sdk_03_05_00_04\packages\ti\drivers\i2c\docs\doxygen\html\index.html

    Regards,

    AG

  • Hi Akash,

    The unit test code does not check if data is transferred.  So it can not fail even if data is not transferred.  Is there any I2C master used with the I2C slave unit test?  I did not find instructions how to set up hardware connections to this unit test and assume it is just a dummy test not testing the actual communication.  And my understanding of unit tests is that you would not need hardware connections to an I2C master.  That would be called system testing.

    So have you been trying to repeat my error but you successfully receive data from an I2C master?  Can you share the code or point out how you do it differently than I do?

    In addition to solving the error I would be interested to get an explanation how this I2C slave driver can work at all.  These two questions are not explained in the documentation and I hope to get an explanation:

    1) How does one get the information if the master wants to read or write in a I2C slave implementation?  The master gives the read/write bit along with the address and the slave should react by  I2CSlave_read if the bit was write and I2CSlave_write if the bit was read.  But the I2C slave driver seems to ignore the read/write bit and the read/write bit seems not to be accessible over the driver API.

    2) Lets assume one knows in advance that the I2C master wants to write and I2CSlave_read is called.  How can one find out the number of bytes written by the master?  The I2CSlave_read takes as a parameter the read buffer size, but the master can write any number of bytes.  The number of bytes written by master would be critical information for an application to interpret the data correctly.

  • Hi Tom

    Can you confirm you are able to successfully run the I2C test for slave mode? This is what I have run on my device.

    Regards,

    AG

  • OK.  I spent some time and was able to run the I2C test.  Results are as follows:

    *******************************************************
    I2C Slave Unit Test Menu                    
    Please select the type of test to execute:  
    1. I2C Blocking mode test                   
    *******************************************************
    > Enter your selection: Debug: Blocking mode testing
    Debug: I2C Slave Open passed
    Debug: I2C Slave Control passed
    Debug: I2C Slave write passed
    Debug: I2C Slave read passed
    Feature: Blocking mode testing: Passed

    But I don't see the point of these tests as there is no test for the data transferred there is no guarantee that data is properly transferred.  I was using a I2C master emulator controlled by my laptop over USB.  I tried to read 3 bytes from slave address 0x68.  The I2C slave test should not even pass the write and reads because the address was wrong (slave address is 0x48 in the test) and as I only did reads by the master the I2C Slave read function should never get called, only the write, if correct address is matched.

    Regards,

      Tom

  • Hi Tom

    I'm looking into a solution with our Software team. I'll have an update for you tomorrow.

    Regards,

    AG

  • Hi Akash,

    Can you give an estimate when tomorrow is?

    Regards,  Tom

  • Hi Tom

    Sorry for the delay, I've flagged this issue and we have a few TI experts looking into this. I've just asked them to provide a timeline, I'll get you an update when I have one.

    Regards,

    AG

  • Hi Tom

    Our TI Sales Representative should have reached out to you with a solution. If this is still open then please let me know.

    Regards,

    AG

  • Hi Akash,

    No, I did not receive a solution yet.  Not even an estimate when the I2C Slave driver will be fixed.  I have been looking for other solutions than I2C as a work-around, but it seems there are no good other options.  So I need to wait for a fix to the driver.

    Regards, Tom

  • Thanks Tom will have an update for you tomorrow or Monday.

    Regards,

    AG

  • Hi Akash,
    It is Monday again.  Any estimate when there will be a fixed driver available?

    Kind regards,  Tom