TMS320F28379D: how continue transfer on i2c

Hello Piotr,

I don't believe this is possible, based on how the I2C peripheral works it requires sending a start bit for each transfer; the closest configuration that might fit is the free data format which only requires 1 start condition and then subsequent data bytes. The problem with trying to have delayed transfers for the same 'transaction' is that even if you hold the line low and don't send anything, most likely the EEPROM/device will still clock those values and just read 0s and expect/send an ACK.

Is each transaction 128 bytes or is the overall data that you sequenced above 128 bytes? If it's the latter, I'm not sure why you need to continue the transaction without another START condition.

Best regards,

Omer Amir

Hello,

Omer Amir said:

The problem with trying to have delayed transfers for the same 'transaction' is that even if you hold the line low and don't send anything, most likely the EEPROM/device will still clock those values and just read 0s and expect/send an ACK.

The clock (signal on SCL line) is generated by master, here CPU. I see no reason that the eeprom will not wait. 

Omer Amir said:

Is each transaction 128 bytes or is the overall data that you sequenced above 128 bytes?

I use 24LC512. It has page 128 bytes long. Taking into consideration address bytes (two for this chip) it requires maximum 130 bytes in one full i2c transaction (from START to STOP). This is a problem of programming time optimisation. One page is programmed in the same time as each separated transaction (5ms). If I sent the data in separated i2c transactions intead of one it takes almost 10 times longer.

The question is is it possible to force this CPU module to continue transmisstion without generating the START condition.

Regards,

Piotr Romaniuk

Piotr Romaniuk said:

The clock (signal on SCL line) is generated by master, here CPU. I see no reason that the eeprom will not wait. 

Unless you're bit-banging the clock, I don't see how it would stay low once your data count reaches zero and the FIFO is empty. The  I2CCNT data count register is what is used to determine the number of bytes which are transmitted/received, although based on how many bytes should be configurable (up to 65,536) there should be a way to read large amounts of data. I will ask some of the design experts what workaround may exist for this and get back to you by the end of next week at the latest.

Omer Amir said:

I don't see how it would stay low once your data count reaches zero and the FIFO is empty

void i2c_t::mode_start_write_nostop(void){
this->error = status_ok;
i2cregs->I2CMDR.all = I2CMDR_MST_MASK | I2CMDR_IRS_MASK | I2CMDR_TRX_MASK | I2CMDR_STT_MASK;
}

It is used for reading data. First i2c write transaction is performed, where address in eeprom memory is transmitted (no i2c STOP here), next i2c read transaction is executed (finished by STOP condition). 

Omer Amir said:

The  I2CCNT data count register is what is used to determine the number of bytes which are transmitted/received, although based on how many bytes should be configurable (up to 65,536) there should be a way to read large amounts of data.

The FIFO in this processor is small - only 16 bytes. If one want to send more, need to monitor FIFO threshold flag and send next part to the FIFO. Unfortunately, I cannot provide fast enought monitoring nor use interrupts. The FIFO would underrun in my case.

Omer Amir said:

I will ask some of the design experts what workaround may exist for this and get back to you by the end of next week at the latest.

Thank you.

Regards,

Piotr Romaniuk

Piotr Romaniuk said:

Unfortunately, I cannot provide fast enought monitoring nor use interrupts. The FIFO would underrun in my case.

Yes, I'm unfortunately also seeing the same situation on my side. I'm still in discussions with the design experts regarding a method of doing this if possible. From my understanding so far though, because there is no DMA access it will be difficult to actively transfer data to memory from the I2C receive buffer/FIFO.

Based on my discussion with other experts, if you read the data after the RSFULL status is set (you can poll this status bit), you can continuously read the data and the clock should stretch automatically to allow you to keep reading the data.