AM3352: I2C Slave transmit length

What software is this?

It is on linux, with TI sdk released in 2018

We modified i2c-omap driver to support slave mode. For messages shorter than 32 the code work ok. We want  to understand how to send data over 32bytes in slave mode. 

Jeff

Hi,

a reminder, this is very urgent for us.

Thanks,

Nadav

Hi Jeff, Nadav,

As you already identified, the draining feature cannot be used with slave TX mode. Section 21.3.14.1 (FIFO Interrupt Mode Operation) of the AM335x TRM describes another option for handling the XRDY interrupts. This option supports slave TX mode and should be used instead.

Alternatively, if you chose to use FIFO DMA mode, there are some configuration comments in the TRM for when the I2C is in Slave TX Mode.

Regards,
Melissa

Hi Melissa,

I'm trying to follow 21.3.14.1 FIFO interrupt mode, but I don't seem to be able to get it working.
Here's what I'm doing.

Wait for XRDY interrupt
Read the request data sent from the master. Then construct the response (we do this in very short time), and send it inside the interrupt.
For response smaller than 32 bytes, I set tx threshold to the same as the response size.

Below is a dmesg dump of a small message response. And we have no problem with small messages, the master side receives this response correctly.
[ 155.551363] BB |XUDF|AAS | <- this means an interrupt is received>
[ 155.551371] BB |XUDF|XRDY|
[ 155.551381] [FUNC = ubmc_i2c_receive_data_multi LINE = 160]= Receiving 11 bytes, from idx 0, DCOUNT 0 <- this reading request
[ 155.551395] [FUNC = ubmc_ssif_parse_i2c_slave_msg LINE = 964]= netfn 0x28 cmdid 0x23 len 8
[ 155.551407] [FUNC = ubmc_i2c_slave_send_current_buf LINE = 295]= Start TX, len 11 <-This start of sending response
[ 155.551414] [FUNC = ubmc_i2c_resize_fifo_thresh LINE = 235]= TX threshold set to 11
[ 155.551422] [FUNC = __ubmc_i2c_slave_write_buf LINE = 182]= tx fifo size 53
[ 155.551433] SSIF MSG TX:00000000: 0a 2c 23 00 01 00 00 00 51 01 38
[ 155.551440] [FUNC = __ubmc_i2c_slave_write_buf LINE = 193]= tx fifo size 42 after
[ 155.551446] [FUNC = ubmc_i2c_slave_send_current_buf LINE = 325]= Finished tx

For a response larger than 32 bytes,
I'm setting the tx threshold to 16 bytes, and then write 24 bytes to the fifo, return from interrupt handler, and wait for another XRDY interrupt, in the second XRDY interrupt, I send the rest of data.
Below is a dmesg dump of transmitting a 39 bytes of data, it seems to finish the transmit, but the other side is not receiving the response correctly. I get a lot retry request from master, and master is reporting receive a short message.

[ 155.561251] BB |AAS |
[ 155.561282] BB |XUDF|AAS |XRDY|
[ 155.561295] [FUNC = ubmc_i2c_receive_data_multi LINE = 160]= Receiving 11 bytes, from idx 0, DCOUNT 0
[ 155.561310] [FUNC = ubmc_ssif_parse_i2c_slave_msg LINE = 964]= netfn 0x28 cmdid 0x23 len 8
[ 155.561321] [FUNC = ubmc_i2c_slave_send_current_buf LINE = 295]= Start TX, len 39
[ 155.561327] [FUNC = ubmc_i2c_resize_fifo_thresh LINE = 235]= TX threshold set to 16
[ 155.561335] [FUNC = __ubmc_i2c_slave_write_buf LINE = 182]= tx fifo size 53 <- this is
[ 155.561345] SSIF MSG TX:00000000: 26 2c 23 00 00 00 20 00 00 03 01 7f 68 01 01 00
[ 155.561351] SSIF MSG TX:00000010: 72 00 72 3f 3f 80 01 00
[ 155.561358] [FUNC = __ubmc_i2c_slave_write_buf LINE = 193]= tx fifo size 29 after
[ 155.561915] BB |XUDF|XRDY|
[ 155.561924] [FUNC = ubmc_i2c_slave_send_current_buf_continue LINE = 342]= Finishing TX, len 15, continue from 24
[ 155.561930] [FUNC = __ubmc_i2c_slave_write_buf LINE = 182]= tx fifo size 29
[ 155.561936] SSIF MSG TX:00000000: 00 01 00 00 00 00 00 07 28 59 fc 7f 80 5a 5a
[ 155.561942] [FUNC = __ubmc_i2c_slave_write_buf LINE = 193]= tx fifo size 14 after
[ 155.561948] [FUNC = ubmc_i2c_slave_send_current_buf_continue LINE = 366]= Finished tx
[ 155.562134] BF |


So, do you see any problem in the above procedure?
In first XRDY, Set TXTHRESH to 16, write 24 bytes, then return from irq
In second XRDY, write the rest 15 bytes,

Hi Jeff,

When are you configuring the TXTRSH bitfield?  The TRM has the following note in this bitfield description: "Note... the threshold must not be changed while a transfer is in progress (after STT was configured or after the module was addressed as a slave)."

Depending on when you're setting the TXTRSH bitfield, two suggestions to try:

1.  Make sure I2C_BUF.TXTRSH = 15h when you're setting it to 16.  Otherwise, you could be overfilling the FIFO and the last byte write to I2C_DATA may be getting ignored. 

2.   Set the TX FIFO threshold to 1 (I2C_BUF.TXTRSH=0), similar to the I2C Slave TX Mode instructions in section 22.3.14.3 (FIFO DMA Mode Operation) of the TRM.

Regards,

Melissa

Hi Melissa, 

We were setting the TXTRSH after addressed as a slave, but only at the beginning of TX. 

I followed your suggestion, using a global TXTRSH, and removed TXTRSH set in each transmit, 

And I tried both 16(15)  1(0) for TXTRSH values, and the results are the same as before.

Anything else you see that could be wrong here?

Best Regards

Jeff

One thing I notice, is that if I write 32 bytes(the fifo size), then I won't get a second interrupt. When I write shorter say 24 bytes, then I get the second TXDY interrupt. But on the master side it is the same behavior, I wonder whether in both cases only 32bytes are sent.

How does the i2c slave logic determine how many bytes needs to be sent? I don't see any place I can read this. The BUF_STAT.TXSTAT value seems totally irrelavant, but it does decrease on every valid DATA_REG write (when it is not full).