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.

SK-AM64B: MCSPI Chip Select when slave runs polled mode.

Part Number: SK-AM64B
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hi, I 'am implementing a SPI Single Slave and now I want to know if chip select (CS) is used in polled mode. As far as I can tell, everything is still working when I disconnect CS (so i suspect its not used).

So my questions are:

Is CS used in polled mode? 

Is callback interrupt mode working as Polled with regards to CS?

 

  • Hi,

    As far as I can tell, everything is still working when I disconnect CS

    Are you trying to operate the MCSPI as a Slave and there is an external Controller? Or as a Controller and there is another external slave?

    Regards,

    Vaibhav

  • I'm operating MCSPI as a single slave. An external controller sends data and when it sends it pulls CS. I was excepting it to break when i unplugged CS (just for test) but it continues without any problems. 

  • Hi,

    Please look at the software code along with SysConfig configuration to configure MCSPI as a slave: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1305146/sk-am64b-r5f-spi-dma-in-mcspi_ms_mode_peripheral/5064289#5064289

    Regards,

    Vaibhav

  • Ok, thanks.

    The thing i want to know is if "The CS pins to 24 and 12 ( RPI_SPI0_CS0, RPI_SPI0_CS0)" needs to be connected for the example to work. Do the slave actually use the pin when it act as a single slave?

  • Hi Tobias,

    Thanks for your response.

    Before we move forward, can you let me know if you see your parameters configured as follows: 

    MCSPI_MS_MODE_PERIPHERAL

    Post your response, I can comment on the chip select part.

    Looking forward to your response.

    Regards,

    Vaibhav

  • This is the code that gets generated. Note that i don't have a problem that needs to be solved. I just want to know how the driver handles chip select so i don't get a surprise later on.

     

    /*
     * MCSPI
     */
    /* MCSPI Driver handles */
    MCSPI_Handle gMcspiHandle[CONFIG_MCSPI_NUM_INSTANCES];
    /* MCSPI Driver Open Parameters */
    MCSPI_OpenParams gMcspiOpenParams[CONFIG_MCSPI_NUM_INSTANCES] =
    {
        {
            .transferMode           = MCSPI_TRANSFER_MODE_BLOCKING,
            .transferTimeout        = SystemP_WAIT_FOREVER,
            .transferCallbackFxn    = NULL,
            .msMode                 = MCSPI_MS_MODE_PERIPHERAL,
            .mcspiDmaIndex = -1,
        },
    };
    /* MCSPI Driver Channel Configurations */
    MCSPI_ChConfig gConfigMcspi0ChCfg[CONFIG_MCSPI0_NUM_CH] =
    {
        {
            .chNum              = MCSPI_CHANNEL_0,
            .frameFormat        = MCSPI_FF_POL0_PHA1,
            .bitRate            = 50000000,
            .csPolarity         = MCSPI_CS_POL_LOW,
            .trMode             = MCSPI_TR_MODE_TX_RX,
            .inputSelect        = MCSPI_IS_D1,
            .dpe0               = MCSPI_DPE_ENABLE,
            .dpe1               = MCSPI_DPE_DISABLE,
            .slvCsSelect        = MCSPI_SLV_CS_SELECT_0,
            .startBitEnable     = FALSE,
            .startBitPolarity   = MCSPI_SB_POL_LOW,
            .csIdleTime         = MCSPI_TCS0_0_CLK,
            .turboEnable        = FALSE,
            .defaultTxData      = 0x0U,
            .txFifoTrigLvl      = 16U,
            .rxFifoTrigLvl      = 16U,
        },
    };
    
    MCSPI_ChConfig *gConfigMcspiChCfg[1] =
    {
        gConfigMcspi0ChCfg,
    };
    
    
    MCSPI_DmaChConfig gMcspiDmaChConfig[1] =
    {
        NULL,
    };
    
    void Drivers_mcspiOpen(void)
    {
        uint32_t instCnt;
        int32_t  status = SystemP_SUCCESS;
    
        for(instCnt = 0U; instCnt < CONFIG_MCSPI_NUM_INSTANCES; instCnt++)
        {
            gMcspiHandle[instCnt] = NULL;   /* Init to NULL so that we can exit gracefully */
        }
    
        /* Open all instances */
        for(instCnt = 0U; instCnt < CONFIG_MCSPI_NUM_INSTANCES; instCnt++)
        {
            gMcspiHandle[instCnt] = MCSPI_open(instCnt, &gMcspiOpenParams[instCnt]);
            if(NULL == gMcspiHandle[instCnt])
            {
                DebugP_logError("MCSPI open failed for instance %d !!!\r\n", instCnt);
                status = SystemP_FAILURE;
                break;
            }
        }
    
        if(SystemP_FAILURE == status)
        {
            Drivers_mcspiClose();   /* Exit gracefully */
        }
    
        return;
    }
    
    void Drivers_mcspiClose(void)
    {
        uint32_t instCnt;
    
        /* Close all instances that are open */
        for(instCnt = 0U; instCnt < CONFIG_MCSPI_NUM_INSTANCES; instCnt++)
        {
            if(gMcspiHandle[instCnt] != NULL)
            {
                MCSPI_close(gMcspiHandle[instCnt]);
                gMcspiHandle[instCnt] = NULL;
            }
        }
    
        return;
    }

  • Hello Tobias,

    Allow me sometime to comment on the same.

    Regards,

    Vaibhav

  • Hi,

    I am looking at an application configured in Peripheral Mode. I am debugging through each of the APIs to understand how Chip Select is controlled.

    Allow me sometime to get back to you with the behaviour of the chip select in peripheral mode.

    Regards,

    Vaibhav

  • Hi Tobias,

    After studying the drivers, my understanding is as follows.

    If the MCSPI is in MCSPI_MS_MODE_PERIPHERAL mode, it prepares the driver for a transaction with a MCSPI controller device. The device will then wait until the controller begins the transfer. -> This can be found under one of the header files description.
    Apart from this, I have seen, that for Controller mode, we are the one who controls the chip select and thats how the protocol is also meant to be.
    There are two things to be aware of.
    • First being the FORCE bit, which is responsible for asserting and de-asserting the chip select line.
    • But then we also need to look at the channel enable bit, which makes sure that the specific CS line channel is enabled and then the transaction happens.

    So different combinations means different things:

    • FORCE bit is 0, channel enable is 0: Means nothing on the wire as of now.
    • FORCE bit is 1, channel enable is 0: Means chip select is asserted but no transaction can take place as channel enable is not set.
    • FORCE bit is 0, channel enable is 1: Peripheral Mode: Basically, in this scenario, channel will be enabled and then transaction will take place, but the FORCE bit will be controlled by the External Controller. Basically, External Controller will say if the CS will be asserted or de-asserted. Hence, no action of the CS line being asserted or de-asserted from our end when we configure MCSPI as a PERIPHERAL on Sitara Processors. So, basically, when the channel is enabled, it is at this point that we expect the external controller to initiate the transaction, and this is what happens in the Peripheral side of the driver.
    • FORCE bit is 1, channel enable is 1: Means, transaction can take place as channel is enabled and the CS will be asserted as FORCE is 1.

    To summarize, I believe you should require the Chip Select line for the external Controller to control the MCSPI configured as a Peripheral.

    Please tell me more about your Controller and please check the lines configured along with the power supply as well.

    Looking forward to your response.

    Regards,
    Vaibhav