Power SDK DPM interfering with I2C slave messaging

Announcements

Live Webinar: USB-C adoption. Simple & Cost-efficient solutions | April 18th @9am or 5pm CEST. Register now !

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
JoLo_4180566
Level 2
Level 2

I've modified the Power SDK to work with a custom power delivery design. Our design uses an external processor acting as a master with some I2C voltage regulators attached to it. The processor continuously polls the CCG3PA (CYPD-3175) and if the CCG3PA stack requires a voltage to be delivered, it will respond to the poll with the desired voltage. This works most of the time but occasionally, I get a dropped packet or a duplicate packet.

I am using the I2C example for the CCG3PA and have tried both polling and interrupt modes. It is part of the main loop. I instrumented the packets with a sequence number and when the dpm/app tasks are not running, it works fine, i.e. packets are in sequence. When I start the DPM, it affects something in the I2C stack that causes the phenomena described above. Without any sources to the DPM, I can't tell if the dpm task call or the app call are causing some time delays that would affect the I2C. My loop is something like this:

main calls process loop

process loop pseudo code:

if (dpm_enabled)

{

     dpm_task(port);

     app_task(port);

}

if (I2C_1_I2C_SSTAT_WR_CMPLT)

{

     respond to master request

     i2c read buffer gets data

     I2C_1_I2CSlaveClearWriteBuf();

     (void) I2C_1_I2CSlaveClearWriteStatus();

}

if (I2C_1_I2C_SSTAT_RD_CMPLT)

{

            I2C_1_I2CSlaveClearReadBuf();

            (void) I2C_1_I2CSlaveClearReadStatus();

}

return to main

Does the DPM or the APP task do any blocking or anything else that might cause an occasional delay? Are there any timing tricks that I can try to help alleviate this problem?

0 Likes
1 Solution
ShifangZ_26
Moderator
Moderator
Moderator
10 likes given 250 sign-ins 1000 replies posted

Hi ,

Recommend you add a GPIO as INT and dessert after dpm_task is entered, and assert after dpm_task(port);

Best Regards,

Lisa

View solution in original post

0 Likes
3 Replies
ShifangZ_26
Moderator
Moderator
Moderator
10 likes given 250 sign-ins 1000 replies posted

Hi ,

Recommend you add a GPIO as INT and dessert after dpm_task is entered, and assert after dpm_task(port);

Best Regards,

Lisa

0 Likes

Not a practical answer since it would require a hardware change.

Would the EZI2C have any advantages as far as latency? It sounds like the EZI2C operates asynchronously to the application code in which case, I can set a location to the desired voltage in vbus_ctrl and let the application loop continue. The master can read that voltage and send it to the voltage regulator. Am I reading the documentation correctly in assuming that it is an asynchronous operation?

0 Likes

Hi ,

Your understand is almost correct. You may cause time out of I2C master, in this case, you can slow down your read loop.

Best Regards,

Lisa

0 Likes