This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3220: Can I2S pins be left undeclared if not needed?

Part Number: CC3220

Team,

My customer needs an answer urgently to their question below as their HW development is on hold until resolved:

Is it possible to leave some of the I2S signals unconfigured on the CC3220?  We are very pin constrained but do not need the input side of I2S, and would like to free McAXR1 and McACLKX for use with another peripheral, however if these signals are left undeclared the I2S calls hang.  Is there an option for leaving pins unassigned?

Please advice.

Thanks and regards,

/ Wolfgang

  • Hi,

    I believe all 6 pins needs to be configured.
    See chapter 12 of linked document
    www.ti.com/.../swru465.pdf

    However, I will confirm if there is a work around.


    Regards,
    Charles O
  • Charles,

    Is it a SW or HW limitation that all 6pins needs to be configured?

    Can I2S be muxed individually or are they muxed as a group in the interface?

    Thanks,

    Fredrik

  • All,

    Just to clarify, you are only sending I2S data OUT of the CC32xx device?

    you will need three signals to do this. The Clock, the Frame Select, and Data. 

    If I understand our question, you want to disable McAXR1 and McACLKX. You need the clock signal for sending your data to the slave. The other RX pin in theory should be able to be muxed to a different pin.

    How are you currently handling your muxing? Are you manually do this with function calls, or changing things in the LAUNCHXL.h and .c pin configurations?

    Regards,

    VR

  • Hey all,

    I did some debugging and came up with something i think will help you.

    I Started with the I2S Echo example and did slight modifications for testing. This example is available in our SDK.

    If you look at the I2S configuration inside the CC3220xx_LAUNCHXL.c, you see we have 5 pins listed here. (xr0,xr1,clkx,clk,fsx). To transmit data out, you only need xr0,clk, and fsx pin. You can Commit out the configuration for ClkX and xr1.

    Now that these pins will not be configured when configuring the I2S, we can add them to another peripheral we want to use them for. For example, I will add them as GPIOs. Add these pins in the configuration in the .c and .h files. The order that you add them to each struct matters, so the first element in one struct/array corresponds to the first element in the other.

    Now that the configuration is setup, you should be able to go into the i2secho.c and start making a few changes. First thing I did was I wanted to toggle the GPIOs. Since we aren't using the i2s Receive, I went ahead and removed the i2s calls inside the thread, and in the last while loop, I added a GPIO toggle sleep cycle.

    This will now work as intended, but the data the I2S will be sending is nothing, since the TX expected to send the RX coming in from the I2S lines. You can play with the example some more to make it send meaningful data, or just use the example I attached to see it working.

    Here is a Logic Analyzer shot looking at the signals I generated.

    Channel 1 and Channel 5 are GPIOs Pin 50 and 62. There signals are opposites of each other with a period of 1 second. The I2S data is being transmitted, and I made the buffers first element have a value so I could see the spike when a new buffer was being sent.

    This should be how to accomplish what you guys wanted, but let me know if you have any questions! :)

    Regards,

    VR

    Project Link:

    /cfs-file/__key/communityserver-discussions-components-files/968/i2secho_5F00_CC3220SF_5F00_LAUNCHXL_5F00_tirtos_5F00_ccs.zip

  • Hi Vincent,

    I'm the original customer that contacted Wolfgang in the first place. Nice to meet you and thanks for helping out here. You are correct, we are only sending I2S data OUT of the CC3220S device, so only the following ports are being used:

    .xr0Pin = I2SCC32XXDMA_PIN_50_McAXR0
    .clkPin = I2SCC32XXDMA_PIN_53_McACLK
    .fsxPin = I2SCC32XXDMA_PIN_15_McAFSX

    We want to leave McAXR1 and McACLKX unused by the I2S driver, so they could be used as GPIOs. Currently we just tried commenting out those two pin definitions from LAUNCHXL.c, but the CC33220S just hangs trying to run this code. We haven't yet tried applying an alternative configuration for those two pins. Even commenting out just McACLKX is enough to hang the device, see: http://e2e.ti.com/support/wireless_connectivity/simplelink_wifi_cc31xx_cc32xx/f/968/t/640839

    Please advice on how to proceed.

    Thanks!

    Dan

  • Thanks Vincent, let me take a look
  • Hi Vincent,

    Which version of the CC3220 SDK are you using? We are with 1.40.01.00 and running IAR. Is it possible that something was fixed in the newer SDK that now allows partial configuration of the I2S port?

    Thanks,
    Dan
  • this is possible.

    I am using the latest SDK, version 1.50.0.6.
  • Hi Vincent,

    I figured out the problem here. Our system was actually hanging when trying to send I2C data. The reason is that when McAXR1 and McACLKX are commented out they get assigned 0x000. Then the I2S_open() initialize all 5 pins, and 0x000 is setting PIN_1 to PIN_MODE_0 which is incorrect as we need it to be in PIN_MODE_1 (0x100). The solution here is to assign McAXR1 and McACLKX the value 0xFFF, similar to what the UART is doing with UARTCC32XX_PIN_UNASSIGNED:

    #define I2SCC32XXDMA_PIN_UNASSIGNED   0xFFF
    
    I2SCC32XXDMA_Object i2sCC3220SObjects[CC3220S_LAUNCHXL_I2SCOUNT];
    
    const I2SCC32XXDMA_HWAttrsV1 i2sCC3220SHWAttrs[CC3220S_LAUNCHXL_I2SCOUNT] = {
        {
            .baseAddr = I2S_BASE,
            .intNum = INT_I2S,
            .intPriority = (~0),
            .rxChannelIndex = UDMA_CH4_I2S_RX,
            .txChannelIndex = UDMA_CH5_I2S_TX,
            .xr0Pin = I2SCC32XXDMA_PIN_50_McAXR0,
            .xr1Pin = I2SCC32XXDMA_PIN_UNASSIGNED,  //I2SCC32XXDMA_PIN_60_McAXR1,
            .clkxPin = I2SCC32XXDMA_PIN_UNASSIGNED, //I2SCC32XXDMA_PIN_62_McACLKX,
            .clkPin = I2SCC32XXDMA_PIN_53_McACLK,
            .fsxPin = I2SCC32XXDMA_PIN_15_McAFSX,
    
        }
    };

    Your example was helpful as it showed me that the I2S driver was capable of operating with only 3 pins.

    Thanks,

    Dan

  • That's great to hear!

    Let me know if you have any more questions!

    VR