Does PSP IIC Driver Support Slave Mode Operation or not?

It seems that this topic is not very interesting, and nobody answered this question.

I think it is not a good practice to develop my IIC slave code based on CSL level. It is time consuming. I am willing to use some kind of software packages where the provided code is fully verified.

Hi Vcar,

DM648 PSP 1.10.01, IIC driver does not support IIC slave operation.

You could start with ddc_i2c.c.

Pointers are

•  use Flag member of the dataparam->I2ctrans strucure.
• While processing the IO request in submit function, program the I2C registers appropriately for slave operation after checking the flag.

regards

Vichu

Lead Engineer

PSP team

Texas Instruments

PasupathyVisuvanadan said:

Hi Vcar,

DM648 PSP 1.10.01, IIC driver does not support IIC slave operation.

You could start with ddc_i2c.c.

Pointers are

•  use Flag member of the dataparam->I2ctrans strucure.
• While processing the IO request in submit function, program the I2C registers appropriately for slave operation after checking the flag.

regards

Vichu

Lead Engineer

PSP team

Texas Instruments

Thank you for your reply!

Need I make use of the callback functions? I think the traditional procedure should be set an interrupt service routine(or callback function based on the DDC layer), when the IIC slave is addressed, my ISR/Callback function will be called and begins the proper IIC transactions.

According to your remarks, I can modify the minidriver submit function, but my application still does not know whether to read or write, because the master will decide the bus operation.

Joe Coombs said:

I've had some success using the PSP I2C driver in slave mode on the DM6437.  That driver should be very similar to the one on DM648.  I didn't need to modify the driver; the key is selecting the correct flags to pass to GIO_submit.  It boils down to using a couple different lines while setting up the I2C request object:

PSP_I2cRequest  i2cBuf;
// typical master mode setup goes here
i2cBuf.i2cTrans.flags = PSP_I2C_IGNORE_BUS_BUSY | PSP_I2C_READ; // use PSP_I2C_WRITE if writing
i2cBuf.i2cTrans.slaveAddr = 0x28; // self slave address
// ready to call GIO_submit

There are two tricky points that the driver can't handle without modification:

1. You have to know how many bytes the next transfer will be
2. You have to know whether the next transfer will be a read or a write

It should be possible to handle the first one with a modified driver, but the second one is harder.  It may be possible using the peripheral's address-as-slave interrupt (see the interrupt handler function in ddc_i2c.c), but I suspect there would be quite a lot of new and restructured code involved.

In my opinion, it's better to (if possible) create a protocol for master requests to eliminate ambiguity at a higher level.  In my use case, I was simulating an I2C EEPROM, and the I2C master used a very predictable pattern: write a two-byte offset address, then read two bytes of data.  Your use case is probably more complicated, but it may still be possible to anticipate the I2C master's next action.

Hope this helps.

Thank you for your suggestions! I will try this and if I make any progress, I will post it here.

Your solution is very OK. I made my I2C slave operation working now. In most common occasion, this kind of working flow is enough!

Thank you for your help.