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.

I2C behaves funny

Other Parts Discussed in Thread: EK-TM4C1294XL

I am communicating with an I2C peripheral using an EK-TM4C1294XL. I modified the existing I2C example. The peripheral understands the following protocol: START [address] ACK [reg addr] ACK [reg val] ACK STOP, where the ACKs are generated by the peripheral, and the rest by the Tiva master.

I observe two different scenarios intermittently - proper and erroneous, and I am not able to understand why the erroneous scenario occurs. 

Here is my code in main() (excuse formatting):

    volatile uint32_t ui32Loop, ui32clock;
    uint32_t pui32DataTx[NUM_I2C_DATA], i2c_cmd[NUM_I2C_DATA];
    uint32_t ui32Index;
    uint8_t err;



    ui32clock = MAP_SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
            SYSCTL_OSC_MAIN |
            SYSCTL_USE_PLL |
            SYSCTL_CFG_VCO_480), 120000000);


    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C0);
    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);


    MAP_GPIOPinConfigure(GPIO_PB3_I2C0SDA);
    MAP_GPIOPinTypeI2C(GPIO_PORTB_BASE, GPIO_PIN_3);


    MAP_GPIOPinConfigure(GPIO_PB2_I2C0SCL);
    MAP_GPIOPinTypeI2CSCL(GPIO_PORTB_BASE, GPIO_PIN_2);



        MAP_I2CMasterInitExpClk(I2C0_BASE, ui32clock, false);


        MAP_I2CMasterSlaveAddrSet(I2C0_BASE, SLAVE_ADDRESS, false); // initiate Write operation


        // delay a bit
        for(ui32Loop = 0; ui32Loop < 8000000; ui32Loop++)
                {
                }

        //
        // Initalize the data to send.
        //
        pui32DataTx[0] = 0x00; // ISL23318 wiper register - holds current wiper position
        pui32DataTx[1] = 0x40; // current wiper position to set
        i2c_cmd[0] = I2C_MASTER_CMD_BURST_SEND_START;
        i2c_cmd[1] = I2C_MASTER_CMD_BURST_SEND_FINISH;


        ui32clock = 0;
while(1)
{
	ui32Index = 0;
	ui32clock++;

	pui32DataTx[1] = (0x40)*(ui32clock%3);

        for(ui32Index = 0; ui32Index < NUM_I2C_DATA; ui32Index++)
        {


        	MAP_I2CMasterDataPut(I2C0_BASE, pui32DataTx[ui32Index]);


        	MAP_I2CMasterControl(I2C0_BASE, i2c_cmd[ui32Index]);


            while(MAP_I2CMasterBusy(I2C0_BASE))
            {
            	UARTprintf(".");
            }

            err = MAP_I2CMasterErr(I2C0_BASE);
            if (err != I2C_MASTER_ERR_NONE)
            	UARTprintf("error: %d\n", err);

        }
        UARTprintf(" Complete\n");
        
        for(ui32Loop = 0; ui32Loop < 10000000; ui32Loop++)
                {
                }
}

Here are the two different pictures I get without any apparent cause for why one is received rather than the other:

In the first case, the first data byte (reg addr) is nowhere to be seen! In the second scenario, I can verify that the transfer is complete and the peripheral responds properly, but why the delay between the 2-nd and 3-rd data bytes?