PicoCore™MX8ULP I3C sgtl5000 info

    Good day to all!

    I use PicoCore™MX8ULP and I have some questions about the sgtl5000 and I3C0 bus, I hope for your support.


    I'm trying to control an audio codec from the m33 core.

    Standard sgtl5000 control functions from fsl drivers (for example SGTL_Init() and some others) use i2c entities, however on my board the codec is connected to i3c0, I know that i3c is backward compatible with i2c, but I don't quite understand how to do this using functions from fsl drivers.

    Question. To use i3c0 with the codec, will it be necessary to rewrite the existing functions using i2c for interaction? If not, maybe there are some examples of code using i3c0 for sgtl5000 on PicoCore.


    Thank you in advance.

    Hi Saturnion ,

    The M33-FREERTOS has its own fsl_i3c driver for I3C. The driver has similar interfaces to the I2C driver.


    We have already been able to implement I3C with I2C functionality. I would like to refer you to a section of code that we use in our FREERTOS programme in our releases.


    https://github.com/FSEmbedded/…/master/board/board_i2c.c


    The following functions can be analysed for the configuration and operation of the interface:

    https://github.com/FSEmbedded/…2.1/board/board_i2c.c#L39


    https://github.com/FSEmbedded/….1/board/board_i2c.c#L132


    https://github.com/FSEmbedded/….1/board/board_i2c.c#L174


    It is also important that the value I3C_RETRY_TIMES is set. Without this definition, reading via I3C can be prone to errors.



    Code
    1. #ifndef I3C_RETRY_TIMES
    2. #define I3C_RETRY_TIMES 500
    3. #endif

    The define can be set before include


    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    Thanks for the answer.

    Your materials helped me understand a little, but now when I try to read or write data to the codec registers I get kStatus_I3C_Nak in response, and it doesn't matter whether I try to access it at address 0x0A or at any other address.

    I used your advice about changing I3C_RETRY_TIME, maybe there are some other pitfalls associated with something similar?